Pandoc alternatives in 2026: making PDFs without the LaTeX install

What "pandoc alternatives" usually means

Pandoc is magnificent and maintained; nobody leaves it because it broke. The friction is concentrated in one place: pandoc report.md -o report.pdf is not really Pandoc rendering a PDF. Pandoc converts your document to LaTeX and shells out to a TeX engine, which means your "Markdown to PDF" pipeline quietly acquired the heaviest toolchain in computing:

• The install. A working TeX distribution runs from hundreds of megabytes (minimal, with package roulette) to several gigabytes (texlive-full). CI images, containers, and teammates' laptops all pay it.
• The errors. pdflatex not found, missing .sty packages, Unicode that needs xelatex, and LaTeX error messages that predate readable error messages.
• The styling. Changing how the PDF looks means LaTeX templates and -V variables, a skill set orthogonal to everything else your team does.

If your documents genuinely benefit from TeX-quality typesetting (academic papers, books, complex math), that cost can be worth paying. The alternatives below are for everyone who only ever wanted a decent-looking PDF out of a Markdown file.

Option zero: keep Pandoc, swap the engine

Pandoc's --pdf-engine flag accepts more than LaTeX. Two swaps remove the TeX toolchain entirely:

# Style with CSS instead of LaTeX templates
pandoc report.md --pdf-engine=weasyprint --css=report.css -o report.pdf

# Or typeset with Typst instead of TeX
pandoc report.md --pdf-engine=typst -o report.pdf

Your input format, filters, citations, and the rest of the Pandoc workflow stay untouched; only the PDF step changes. For scripted document pipelines this is the highest-value, lowest-effort move on this page, which is why it is listed before our own product. One warning: Pandoc also still accepts --pdf-engine=wkhtmltopdf, which you should not use; that engine is archived with unpatched critical CVEs (our wkhtmltopdf alternatives page covers why).

The shortlist at a glance

Typst: the modern typesetting path

Typst is what most frustrated LaTeX users were waiting for: a typesetting system with readable markup, comprehensible error messages, sub-second compiles, and a single-binary install. Math, references, bibliographies, and fine-grained layout are all first-class, which makes it the honest recommendation for academic and technical documents that actually use those features. Pandoc can convert your existing Markdown (and much else) directly into Typst, so the migration path from a Pandoc-plus-LaTeX pipeline is well paved. Its limits: a new (if pleasant) language to learn, and an ecosystem younger than TeX's four decades of packages, so highly specialized LaTeX workflows should check coverage before committing.

Tectonic: keep LaTeX, lose the pain

If your documents are already LaTeX and the toolchain is the problem rather than the language, Tectonic packages a modern TeX engine as a single binary that downloads only the packages a document actually uses, on demand. No multi-gigabyte install, no manual package management, reproducible builds. It is the conservative fix: everything about your documents stays the same, and only the install story improves. It does nothing for the styling-in-LaTeX complaint, because it is LaTeX.

WeasyPrint: style documents with CSS

WeasyPrint renders HTML and CSS to PDF with a paged-media engine that handles the print details (page numbers, running headers, @page rules) unusually well, and as noted above it plugs directly into Pandoc as a PDF engine. Used standalone from Python or the command line, it turns "design the PDF" into a CSS problem: a skill your team has, applied to a stylesheet you can version. No JavaScript and no browser, by design; for a fuller picture of where its own limits sit, see our WeasyPrint alternatives page.

The managed option: Transformy

Transformy is the right shape when PDFs are generated inside an application rather than from a terminal. Markdown converts to HTML in one line in every ecosystem (marked, markdown-it, python-markdown, goldmark, commonmark-php); rendering that HTML well is the part worth outsourcing. One authenticated POST returns a PDF rendered by real headless Chromium, styled by your CSS, with the document plumbing an app needs in production: page headers and footers with {{page}}/{{pages}} tokens, PDF bookmarks generated from headings ("outline": true, the API cousin of Pandoc's --toc), async jobs with signed webhooks, delivery straight to your own cloud storage, and idempotency keys for safe retries.

# Markdown → HTML (any library) → PDF, no LaTeX anywhere
curl -X POST https://api.transformy.io/v1/pdf/chrome \
  -H "Authorization: Bearer tfy_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "html": "<html>…converted markdown + your stylesheet…</html>",
    "page_size": "a4",
    "outline": true,
    "footer": { "html": "<span style=\"font-size:10px\">Page {{page}} of {{pages}}</span>" }
  }' \
  --output handbook.pdf

Pricing starts free (100 documents a month, no credit card); the Pro plan is $99/month for 10,000 documents, then $0.01 per additional document. The honest scope, restated: Transformy renders HTML only. It does not convert docx, epub, or LaTeX, so it replaces Pandoc's PDF step, not Pandoc. Plenty of pipelines pair them: Pandoc for the format conversion it is unbeatable at, the API for the rendering. And for terminal-first workflows where a free local tool suffices, the options above are the better fit; the API earns its keep when PDFs ship from your product.

Migrating: mapping a Pandoc-PDF workflow

For the common case (Markdown in, styled PDF out, moving to CSS-based rendering):

- pandoc report.md -o report.pdf   # via pdflatex
+ markdown → HTML in your app; render the HTML

- --template=custom.tex
+ a CSS stylesheet

- -V geometry:margin=2cm
+ "margin": "2cm"   # or @page CSS

- -V papersize:a4
+ "page_size": "a4"

- --toc
+ "outline": true   # PDF bookmarks from headings

- \fancyhdr page headers
+ "header"/"footer" HTML with {{page}}, {{pages}} tokens

- TeX install in every CI image
+ nothing to install (API) or one binary (Typst, Tectonic)

What does not carry over: LaTeX-grade math typesetting and citation processing. If your documents lean on those, Typst and Tectonic are your lane; CSS rendering is for documents whose complexity is layout and branding, not equations.

Frequently asked questions

The bottom line

Sort yourself by document type and the answer falls out. Existing Pandoc pipeline, wants less toolchain: swap --pdf-engine to WeasyPrint or Typst and go home early. Typeset technical documents: Typst for new work, Tectonic if the LaTeX must stay. Styled business documents from a script: WeasyPrint. PDFs shipped from inside your product: convert Markdown to HTML and let Transformy render it, starting on the free tier (100 documents a month, no credit card), which is enough to see your stylesheet replace a LaTeX template you never liked maintaining.

Pandoc made every document format reachable from every other one. The alternatives above are for the last step, the one Pandoc always delegated anyway: turning the result into a PDF without a toolchain that outweighs your application.