Generate Slides From Markdown: a CLI Comparison

Five command-line tools turn Markdown into slides, and they do not work the same way. Some take one file and hand back one file. Some scaffold a whole project. One of them does not produce a local file at all. Here is what each command actually looks like, with real flags, so you can pick based on the workflow rather than the pitch.

Slaide

Install the CLI, or skip installing and run it through npx:

npm install -g @aivorynet/slaide
npx playwright install chromium   # only needed for PDF, PPTX, and image export

Scaffold, check, preview, and build one .slaide file:

slaide new talk.slaide --title "My Talk"          # scaffold a starter deck
slaide validate talk.slaide --strict               # catch layout, slot, and contrast issues
slaide dev talk.slaide                              # live preview at http://localhost:4321
slaide build talk.slaide --out out                  # self-contained out/index.html

Export to PDF and to an editable PowerPoint from the same source file:

slaide export talk.slaide --pdf out/talk.pdf
slaide export talk.slaide --pptx out/talk.pptx      # real text boxes, shapes, images

Slaide also runs as an MCP server (slaide mcp) so an agent can scaffold, validate, and render without shelling out to the CLI directly. See the CLI reference for the full command list, including import, compare, and pack.

Marp

Install Marp CLI, then convert a single Markdown file directly to whatever output you need:

npm install -g @marp-team/marp-cli

marp deck.md -o deck.html
marp deck.md -o deck.pdf
marp deck.md -o deck.pptx
marp deck.md -o deck.pptx --pptx-editable   # experimental, lower fidelity per Marp's own docs

Watch mode re-converts on save, and server mode serves a folder of decks over HTTP:

marp -w deck.md          # re-convert on every save
marp -s .                # serve every deck in this folder, convert on request

Marp is a single conversion step: one Markdown file plus Marpit directives (theme, size, per-slide classes in HTML comments) in, one output file out. That is its whole appeal.

Slidev

Slidev is not a single-file converter, it scaffolds a project:

npm init slidev@latest    # creates a project with slides.md inside

Run the dev server from inside that project, then build or export:

slidev                              # dev server, instant hot-reload
slidev build                        # hostable SPA, animations intact
slidev export                       # PDF (default)
slidev export --format pptx         # PPTX - slides as images, not editable text
slidev export --format png          # one PNG per slide

If you want a single Markdown file converted the way Marp does it, Slidev is the wrong shape of tool. If the deck has embedded components, code that runs, or click-through animations, the project structure earns its keep.

md2googleslides

Google’s own tool does not produce a local file at all. It writes directly into a real, editable Google Slides deck in your Drive:

npm install -g md2gslides
md2gslides slides.md --title "Talk Title"

The first run prompts for OAuth against your Google account; credentials are cached locally after that. To update an existing deck instead of creating a new one:

md2gslides slides.md --title "Talk Title" --append <deck-id> --erase

Local images are not embedded by default, --use-fileio opts into uploading them through a third-party service first. It is Apache-2.0 licensed and, per its own README, meant for “quickly prototyping presentations,” not final design output.

mdSlides

A Python tool (maintained by CD Clark III) that wraps Pandoc rather than shipping its own renderer:

pip install mdslides
mdSlides simple.md              # writes a self-contained HTML slideshow directory
mdSlides --list-engines         # see what else it can target besides the default

By default it drives Pandoc’s Slidy output: one self-contained folder with index.html, local CSS, and any images or media it needs, portable enough to email or copy to a USB stick. It needs Pandoc installed and on your PATH - it is a wrapper, not a standalone engine.

Which of these actually script well in CI

Not every tool here is happy running unattended inside a build pipeline. md2googleslides needs an interactive OAuth grant the first time it runs, and after that it is still writing into a specific Google account’s Drive, which is awkward for a CI runner with no human to authorize it. mdSlides needs Pandoc pre-installed on whatever machine runs it, which is one more thing to bake into a container image. Marp, Slidev, and Slaide all run headless with no account: install the CLI, point it at a file (or a project, for Slidev), and it produces output on disk. The difference between those three in a script is what they need for export. Marp only needs its own bundled Chromium. Slidev and Slaide both drive a real Chromium through Playwright for PDF, PPTX, or image export (npx playwright install chromium for Slaide), so budget the extra install step in the pipeline image.

If the deck is generated from data, a templated .slaide file, a templated slides.md for Marp, or a Slidev project with variables injected at build time are all reasonable starting points. What differs downstream is whether the output someone opens afterward is a picture of the deck or an editable one: only slaide export --pptx guarantees the second, unattended, every run.

The shape of the command tells you the shape of the tool

If the deck needs to end up as a file someone opens in PowerPoint with real editable text, that narrows the list fast: Marp’s editable export is explicitly experimental, Slidev’s is images, and md2googleslides and mdSlides do not target PPTX at all. slaide export --pptx is the one built to hand back a file a PowerPoint user can actually edit, and it is the same command whether a person or an agent runs it. For the full picture beyond the CLI, see how Slaide compares to Marp, Slidev, and reveal.js.