Markdown to PDF: every way to do it in 2026 (an honest round-up)
Markdown won. Your notes, your READMEs, your wiki, your AI assistant's output — it's all Markdown. PDFs also won: they remain the only format you can send outside the building and know it will look the same on arrival.
The gap between the two is where this post lives. Here is every serious way to cross it in 2026, what each is genuinely good at, and where each one falls down. We build one of these tools, so discount accordingly — but we'll be straight about when the others are the better choice.
The quick answer
| You are… | Use |
|---|---|
| Converting one file, once | Your editor's extension, or browser print |
| A LaTeX-comfortable academic | Pandoc |
| Converting locally in scripts/CI, defaults are fine | An md-to-pdf CLI tool |
| A team needing full pixel control, with eng time to spend | DIY Puppeteer / an HTML-to-PDF API |
| A team or app that needs designed, consistent output at volume | A Markdown-native service (this is what Inkrun is) |
| Getting PDFs out of an AI agent | An MCP-connected renderer |
Now the details.
1. Editor extensions and browser print
What it is: "Markdown PDF" extensions in VS Code, or rendering the file and hitting Ctrl+P → Save as PDF.
Good: zero setup you don't already have; fine for a one-off.
Falls down: the output looks like a printed web page, because it is one. No control over page breaks, headers/footers, or typography beyond CSS hacking. Not scriptable, not consistent between machines or teammates.
Verdict: the right tool for "I need this file as a PDF in the next ninety seconds," and nothing beyond that.
2. Pandoc (+ LaTeX)
What it is: the universal document converter, usually paired with a LaTeX engine for PDF output.
Good: typographically the ceiling of this entire list — a well-tuned Pandoc/LaTeX setup produces genuinely beautiful documents. Free, offline, scriptable, converts to and from almost anything.
Falls down: the toolchain. A working TeX distribution is gigabytes; template customization means learning LaTeX; the default output without that investment looks like a 1990s preprint. Error messages are famously hostile. No hosted or API story — you own the environment everywhere it runs, including CI.
Verdict: if you (or someone on your team) already speak LaTeX, Pandoc is superb and free. If you don't, the learning curve costs more than any tool on this list. We compare the trade-off in depth in Pandoc vs Inkrun.
3. md-to-pdf CLI tools
What it is: npm/pip tools (md-to-pdf and friends) that wrap Markdown parsing plus a headless browser into one local command.
Good: one install, one command, scriptable. Fine defaults for internal documents.
Falls down: design is on you — you get a stylesheet slot and a browser's print engine, and everything past the defaults (page-break control, running headers, font embedding, brand consistency) is your CSS project. Each machine's environment can render slightly differently. There's no shared design system, so ten teammates produce ten looks.
Verdict: great for local, personal, "good enough" conversion. (Inkrun ships its own CLI in this category — inkrun convert — with the difference that it carries the same embedded-font themes as the hosted service, so local and hosted output match.)
4. DIY: Puppeteer / Playwright / wkhtmltopdf
What it is: you build the pipeline — Markdown → your HTML → your CSS → headless Chromium → PDF.
Good: total control. Any layout you can express in HTML/CSS, you can print. Free at the library level.
Falls down: two separate jobs hide inside "just use Puppeteer." The first is design: print CSS is a specialist skill — page geometry, break rules, running headers, orphan control — and it's why DIY pipelines produce documents that work but don't look designed. The second is operations: Chromium at production volume means a browser pool, crash isolation, zombie-process reaping, memory budgeting, and backpressure. It's a real service you now maintain next to your actual product.
Verdict: the right call when PDFs are your core competency or you need pixel-level control of arbitrary HTML. If your input is Markdown and your goal is "looks professional, works at volume," you're signing up to build a rendering service. We wrote up ours — worker threads, no-orphan guarantees and all — in We ran Chromium in worker_threads so you don't have to.
5. HTML-to-PDF APIs (DocRaptor, PDFShift, api2pdf…)
What it is: mature hosted services: send HTML + CSS, get a PDF. They solve the operations half of #4 well.
Good: reliable, scalable, battle-tested print engines. If you already have HTML templates, they're the pragmatic choice.
Falls down: they solve operations but hand design back to you. The input is HTML — so you're still writing and debugging the CSS, still owning page-break bugs, still the reason documents look the way they do. From Markdown, you also bolt on your own conversion step first. And none of the incumbents speak MCP, which matters more every month as agents become document producers.
Verdict: the better choice for pixel-perfect fidelity to existing HTML. For Markdown-first workflows they leave the hard half of the problem on your desk.
6. Markdown-native hosted rendering (where Inkrun sits)
What it is: the input is Markdown; design comes from professionally built themes and templates, not from you. One POST request — or one MCP tool call from an AI agent — returns a typeset PDF.
Good: the division of labor matches how documents are actually produced now. Humans and LLMs are good at content, which is Markdown. Designers are good at form, which is the theme. Keeping the two strictly separate is what makes output consistent — every render drops into the same shell with the same CSS, fonts embedded, nothing fetched at render time, so the hundredth document matches the first. Templates (theme + your accent + fonts + page size) make "on-brand" a saved setting instead of a per-document effort. And because content can never carry styling, machine-generated input can't inject markup or push the document off-brand — the consistency wall and the security wall are the same wall.
Falls down: it's deliberately not a pixel-perfect layout engine. If you need a regulated form reproduced to the millimeter or full creative control of every page, you want #4 or #5. Constraint is the product: three design knobs, not a stylesheet.
Verdict: for invoices, proposals, reports, release notes, handbooks — recurring documents that must look designed and identical every time — this is the shortest path, whether the caller is your backend, your CI, or your AI assistant.
Choosing in one sentence each
- One file, right now → browser print.
- You speak LaTeX → Pandoc.
- Local scripts, defaults acceptable → an md-to-pdf CLI.
- Pixel control, eng budget → Puppeteer or an HTML-to-PDF API.
- Recurring, branded, at volume, or agent-driven → Markdown-native rendering.
If your case is the last row: the 60-second quickstart goes from curl to PDF before your coffee cools shows the full recurring-documents workflow.