markdown to powerpoint · compared

Lutrin vs Marp

Marp turns Markdown plus CSS into slides, then drives a browser to produce PDF, PPTX and images — you keep full control of the look. Lutrin takes the opposite bet: it refuses all positioning, so that the engine can write native PowerPoint shapes the recipient can edit. Neither of those is a better tool. They are different trades, and this page is about which one you want.

What Marp does better

This comes first because it is the part that decides whether the rest of the page is worth reading. If any of these four is what you need, close this tab and use Marp — it is a good tool, and it is free.

Four things Marp does that Lutrin does not, and will not

  • Complete visual control. A Marp theme is ordinary CSS over a <section>, and the Marpit documentation explicitly blesses position: absolute as the way to place something exactly where you want it. Lutrin structurally refuses this: a contribution that let the author position an element "will be refused, however well implemented". If you have a brand deck in CSS and a logo that must sit at a precise spot, Marp does it and Lutrin tells you no.
  • It is free, with nothing withheld. Marp is MIT across the board and stamps no mark on anything. Lutrin is MIT too, but a deck compiled without a paid licence carries Made with Lutrin on every slide. On the plain question "what does it cost to hand a client a clean deck", Marp's answer is nothing and ours is $59 a year.
  • Formats we simply do not have. PDF, PNG, JPEG and a presenter-notes text dump. Its PDF is not a flat print either — --pdf-notes writes the notes as PDF annotations and --pdf-outlines adds real bookmarks. Lutrin produces .pptx and standalone HTML, and nothing else; for a PDF you go through PowerPoint or a browser yourself.
  • Maturity, reach, and a richer web deck. The VS Code extension reported 827,114 installs when this page was checked, and it is a web extension that works on vscode.dev with nothing installed at all. Marp's HTML template has a presenter view, an overview mode, on-screen controls, a progress bar and View Transition slide transitions; there is a large third-party theme ecosystem. Lutrin needs Node ≥ 22 locally before anything happens, its extension is desktop-only, and it is a young single-maintainer project.

Where Lutrin is different

  • The editable .pptx is the default, and needs no second application. This is the honest version of the claim, and the qualification matters: Marp can produce an editable PowerPoint — --pptx-editable has shipped since Marp CLI 4.1.0. Its own documentation calls it experimental, requires LibreOffice Impress installed in addition to a browser, does not carry presenter notes, and warns of "lower slide reproducibility". Marp's default PPTX is one pre-rendered image per slide, by deliberate design — the team's stated requirement is "almost 100% reproducibility to the slide design". Lutrin has one PPTX mode: native shapes, text boxes and tables, notes kept, fonts embedded, no flag and no second program.
  • No browser anywhere in the toolchain. Marp's PDF, PPTX and image conversions all need a compatible browser installed (Chrome, Edge or Firefox — selectable with --browser). Lutrin's two outputs come out of a pure Node pipeline, which is what makes it plausible in a locked-down CI runner or a container with no Chromium.
  • The engine picks the layout, not you. When a slide overflows, Marp's answer is CSS or <!-- fit -->, and Marp Core does shrink headers, code blocks and KaTeX to fit. Lutrin's answer is to infer a different layout and paginate what is left over. Marp shrinks what you wrote; Lutrin re-lays it out. That is the whole trade, and it is what makes a mechanical .pptx possible.
  • Validation that measures instead of parsing. Marp for VS Code has completion, hover help and diagnostics for its directives — it checks what you typed. lutrin validate --json measures what the rendered slide does: real overflow, images under-resolved for the area they land in, a better-suited layout, as positioned JSON for an agent's write → validate → fix loop.
  • A brand that travels as data, never as code. A Marp theme is CSS the renderer executes — which is why the VS Code extension gates custom themes behind Workspace Trust. A Lutrin kit is tokens, fonts, logos and layout JSON; installing one runs nothing, refuses any entry that escapes the kit, and is https-only with a reproducible sha256.
  • Diagrams, charts and status blocks are in the DSL. Marp deliberately has none — its maintainer's position is that "Marp has no built-in integrations for any diagrams like mermaid.js", and recommends pre-rendered SVG instead. Lutrin ships ```chart, Mermaid, LaTeX, Lucide icons and :::metric / :::progress / :::status as first-class blocks. Marp's math, to be clear, is not the gap: it has Pandoc-style math through MathJax or KaTeX, as does Lutrin.
  • Lutrin reads Marp decks. Put marp: true in the frontmatter and the parser switches to the Marp dialect — --- splits, comment notes, ![bg] images, fragmented lists. It preserves content, not appearance: CSS themes, style:, per-slide backgrounds and non-16:9 sizes do not survive, and each one is reported as MARP_DIRECTIVE_IGNORED rather than dropped in silence. The migration runs one way only.

Side by side

 MarpLutrin
Default PPTX One pre-rendered image per slide — contents cannot be modified in PowerPoint. A deliberate choice, for near-exact reproduction of the design. Native shapes, text boxes and tables — real, selectable, editable. Charts, equations and icons are rasterised images, which is the honest limit of it.
Editable PPTX --pptx-editable, since CLI 4.1.0. Experimental; needs LibreOffice Impress and a browser; presenter notes unsupported; lower slide reproducibility. The default. No flag, no second application, notes preserved.
Fonts in the PPTX Not applicable to the image output; the editable path goes through LibreOffice. TTF/OTF embedded into the OOXML, after reading the font's fsType permission — a foundry-restricted font is skipped with a warning rather than shipped.
Who decides the layout You, in CSS. position: absolute is the documented technique; <!-- fit --> and auto-shrink handle overflow. The engine. No coordinate, size, explicit column or colour exists in the DSL.
Export formats HTML, PDF, PPTX, PNG, JPEG, notes as text. .pptx and standalone HTML. No PDF, no image export.
External runtime A browser (Chrome, Edge or Firefox) for every PDF, PPTX and image conversion. LibreOffice Impress on top, for editable PPTX. Node ≥ 22, and nothing else, for both outputs.
Branding CSS. Three built-in themes, arbitrary custom theme CSS, a large third-party ecosystem. A theme is code the renderer runs. Kits — tokens, fonts, logos, layout JSON. Data only; install executes nothing; WCAG contrast checked at build.
Diagrams & charts None built in, by stated policy — use pre-rendered SVG. ```chart, Mermaid, LaTeX, icons and status blocks in the DSL.
Math Yes, MathJax or KaTeX. Not a Lutrin advantage. Yes — and the same syntax is accepted in the Marp dialect.
Web presentation Rich: presenter view, overview, on-screen controls, progress bar, View Transition transitions, watch mode, a server mode and a preview window. One standalone HTML file with presenter mode (P, notes, timer, second window), and lutrin preview with reload on save. No transitions engine, no server mode.
Validation Syntactic: completion, hover help and directive diagnostics in VS Code. Geometric: measured overflow, under-resolved images, layout suggestions, --json. build refuses to write a file while an error remains.
Licence and cost MIT. Free. No watermark, no paid tier. MIT, free to use — but every slide carries Made with Lutrin until a seat is bought.
Maturity Large and active. 827,114 VS Code installs, thousands of GitHub stars, releases within the fortnight before this check. Young, one maintainer, no comparable adoption or third-party ecosystem.

Run the comparison yourself

This is the one comparison where neither tool picks the terrain, because Lutrin reads Marp decks. Take a real Marp deck of your own and produce three files from it:

marp --pptx deck.md -o marp-default.pptx
marp --pptx --pptx-editable deck.md -o marp-editable.pptx
npx lutrin build deck.md -o lutrin.pptx     # add `marp: true` to the frontmatter

Open all three in PowerPoint and click a heading. In the first you select a full-slide picture. In the third you select the heading, retype it, drag a table cell, and the fonts came with the file. Open the second one too, and be fair about it: Marp's editable export does give you selectable text — the difference is what it costs to get there, and how faithfully the design survives.

Then run the test that cuts the other way. The Marp HTML will look exactly like your CSS said it should. The Lutrin output will look like Lutrin: different spacing, and your theme:, style: and per-slide header: directives all reported as MARP_DIRECTIVE_IGNORED. If that is a deal breaker, you have your answer, and it took ten minutes.

Every claim about Marp on this page was checked against Marp's own current documentation and repositories on 2026-07-30, against Marp CLI 4.5.0 (released 2026-07-17), Marp Core 4.4.0 and Marp for VS Code 3.6.0. Marp is actively developed and some of this will age; if you find a statement here that has stopped being true, tell us and it gets fixed. Sources: marp.app, the Marpit theme documentation, the Marp CLI README, the VS Code Marketplace listing.