Markdown से स्लाइड बनाएं

Why Markdown for Slides at All?

PowerPoint and Keynote are excellent at slide design and bad at almost everything else. They're hard to version-control, hard to diff, hard to edit on a phone, hard to keep consistent across a team, and impossible to grep through. Markdown solves the "everything else" without trying to compete on visual design, and for technical content (code samples, terminal output, command-line walkthroughs, lists of bullet points) it's faster to author than any GUI tool.

The format is plain text, so it lives natively in git, opens in any editor, edits in any tool from VS Code to vim to a phone notes app, and survives 30 years of software churn. The trade-off: you give up pixel-perfect design control. For developer all-hands, conference talks, README walkthrough decks, classroom material, and lightning talks, that's a great trade. For sales pitches and marketing decks, PowerPoint or Figma probably still wins.

The --- Convention

Three dashes on their own line is Markdown's existing syntax for a horizontal rule, defined back in CommonMark and reused as the slide separator across the whole Markdown-slides ecosystem, reveal.js, Marp, Slidev, and most of the smaller tools all use it. The convention is unambiguous (a real horizontal rule still works inside a single slide; the --- only splits when it's on its own line) and easy to type. You write the deck as one continuous Markdown document and the tool re-segments it visually.

The Markdown-Slides Ecosystem in 2026

• reveal.js (Hakim El Hattab, since 2011), the pioneering browser-based presentation library. Vertical and horizontal slide grids, transitions, speaker notes (Notes: syntax), Markdown source via the data-markdown attribute. The household name; slides.com hosts it as a SaaS.
• Marp: the most popular dedicated Markdown-to-slides project. CommonMark-based, ships with a CLI, a VS Code extension, and Marp Core. Excellent PDF export. Frontmatter for theme and aspect ratio.
• Slidev (Anthony Fu), newer (2021), Vue-based, modern. Designed for developer talks: built-in code highlighting, in-slide code embedding, presenter view, drawing on slides during the talk.
• remark.js (Ole Petter Bang), minimal, single-file embed. Loved for being unopinionated.
• HackMD: collaborative-editing flavour. Browser-based, account required, syncs across devices.

This tool fills a different niche: no install, no account, no upload. Paste, present, close the tab. It's the right pick when you're prepping a 5-minute lightning talk on a borrowed laptop, finalising slides on a flight, or drafting in a meeting room and don't want to spin up Marp or sign in to slides.com.

Aspect Ratios Explained

Modern slide decks are 16:9 by default, every conference projector built in the last decade is a 16:9 surface, and 16:9 matches every laptop screen and modern TV. The viewport here renders 16:9 to match. Older decks use 4:3 (the original aspect of a CRT projector); older laptops sometimes ship 16:10. PowerPoint's default has been 16:9 since version 2013; Google Slides defaults to 16:9 on creation; Keynote's default is also 16:9.

Common Use Cases

• Developer all-hands and demo days. Walk a team through a code change, a new architecture, or an incident retrospective.
• Conference and meet-up talks. Especially tech-audience talks where the deck needs code samples that diff cleanly in pull requests.
• README walkthroughs. A 6-slide intro to a library, embedded in the project's docs.
• Lightning talks. 5-minute, ~5-slide talks where ceremony is the enemy.
• Classroom material. Live-edit slides as you teach; students can copy the Markdown source for their notes.
• Internal training. Versioned and code-reviewed onboarding decks alongside the codebase they teach.
• Pre-meeting briefs. 3-slide pre-reads sent as Markdown that the recipient can preview in their editor.

Slide-Design Principles That Matter Even in Markdown

• One idea per slide. The classic rule. If a slide has two thoughts, split it.
• Less text, more structure. If a slide reads like a paragraph, the speaker is reading the slide. Reduce to bullet points and let the speaker fill in the prose.
• Bigger fonts than you think. Markdown slides default to body text around 24–32 px equivalent. Anything below ~18 px is unreadable from the back of a conference room.
• One H1 per slide. Multiple top-level headings on the same slide creates visual confusion.
• Keep code blocks short. Six lines is roughly the comfortable maximum on a 16:9 slide. Longer snippets need to be split or shown highlighted in chunks.
• Make every image earn its place. Stock photos as decoration are filler. Diagrams, screenshots, and data visualisations are signal.

Privacy

Slide decks are often confidential, pitch decks, internal strategy, financial figures, pre-launch product demos. This tool runs entirely in your browser: the Markdown stays in the textarea, the rendering happens locally, and the fullscreen presentation reads from the same in-memory state. Nothing is uploaded, no account is required, and closing the tab wipes everything. Server-hosted alternatives (slides.com, HackMD, GitPitch) require trust in the operator's data-handling policies; this one removes the question entirely.

Common Mistakes

1. Pasting whole paragraphs onto one slide. If the audience reads it, they're not listening to the speaker. Split into bullet points.
2. Inconsistent heading levels. One slide titled with H1, the next with H2, looks sloppy. Pick a level for slide titles and stick to it.
3. Code blocks too long for the projector. A 30-line snippet is illegible from the back row. Show only the relevant 5–10 lines, with the rest replaced by // ....
4. No speaker notes. The slides are the audience's memory aid, not yours. Speaker notes (in tools that support them) hold the talking points.
5. Forgetting the projector aspect ratio. If you authored on a 16:10 laptop and the venue uses a 4:3 projector, content gets cropped.
6. Too many slide transitions. Animations between slides feel polished in a demo and tedious during a 30-minute talk. Default to no transitions or a simple fade.
7. Using a clever font that breaks on the venue's machine. Stick to system fonts, sans-serif for body, monospace for code.

More Frequently Asked Questions

Can I export the slides as PDF?

Yes, enter fullscreen mode, then use your browser's Print function (Ctrl/Cmd + P) and choose Save as PDF. Most browsers print the rendered slides one per PDF page. The result is a clean text-PDF (not an image) so it's small and searchable.

What about syntax highlighting for code?

Fenced code blocks render with monospace and a slight dark background, which makes them readable on the dark fullscreen theme. Per-language syntax highlighting (Python keywords in one colour, strings in another) requires a more elaborate slide framework like reveal.js or Slidev. For a quick lightning talk it's rarely missed; for code-heavy long-form talks, those tools are a better fit.

How do I embed an image?

Standard Markdown image syntax: ![alt text](https://your-image-url.png). The image must be reachable from the public web (or from your local machine via a file:// URL, but file URLs may be blocked on some browsers). For sensitive images, use Markdown's link syntax to a local file you serve from a tiny local web server during the talk.

Will this work offline?

Once the page is loaded, yes, the Markdown rendering and slide navigation run locally. External images won't load without a network, so embed images as data URIs or host them locally if you'll be presenting offline.

Can I use the keyboard during the talk?

Yes, arrow keys / spacebar advance, backspace goes back, Escape exits fullscreen, F toggles fullscreen. Most presenter remotes (the standard Logitech wireless presenter, etc.) emulate the same arrow keys, so they work without configuration.

Is anything sent to a server?

No. Markdown rendering, slide segmentation, fullscreen presentation, all happen in your browser. Your deck content isn't uploaded, logged, or stored anywhere on the server side. Closing the tab wipes the textarea contents.