← All guides

Markdown to PDF: Pandoc vs an online converter (honest comparison)

Short version: if you already have Pandoc plus a LaTeX engine installed, or you need a scripted/CI build with precise typographic control, use Pandoc, it is the more powerful tool and this guide will not pretend otherwise. If you just want a good-looking PDF from a Markdown file without installing a multi-gigabyte TeX distribution, or you want GFM tables, KaTeX math, and mermaid diagrams to render without wiring up filters, a browser converter like PDFMoka's markdown to PDF tool gets you there faster. The real decision is about install footprint and how much rendering you want to configure yourself, not about which tool is "better." Here is the honest breakdown.

The thing most guides skip: Pandoc's default PDF path also needs LaTeX

A common misconception is that Pandoc converts Markdown straight to PDF. It does not. By default Pandoc produces PDF by way of LaTeX, which means a LaTeX engine has to be installed (TeX Live, MacTeX, or MiKTeX). Its default engine is pdflatex.

pandoc input.md -o output.pdf

That single line only works if a TeX distribution is present. On a fresh machine it fails for the same underlying reason jupyter nbconvert --to pdf fails, no LaTeX engine on PATH.

There is a second wrinkle worth knowing: the default pdflatex engine handles Unicode poorly. If your Markdown has non-ASCII characters (accents, CJK, many symbols) you generally have to switch engines:

pandoc input.md -o output.pdf --pdf-engine=xelatex

And for CJK text you additionally need to name a font that has the glyphs:

pandoc input.md -o output.pdf --pdf-engine=xelatex -V mainfont="Your CJK Font"

None of this is a knock on Pandoc, it is doing serious typesetting. It is just the setup reality that a lot of "just run Pandoc" advice glosses over.

verify against current docs: --pdf-engine is the current option name (it replaced the older --latex-engine around Pandoc 2.0). If you are on a very old Pandoc, the flag differs. Confirm with pandoc --version and pandoc --help before publishing any of these commands.

Can Pandoc skip LaTeX? Yes, with a different engine

Pandoc is not locked to LaTeX. You can route through an HTML/CSS engine instead, which avoids TeX entirely:

pandoc input.md -o output.pdf --pdf-engine=weasyprint

Pandoc's supported PDF engines include pdflatex, xelatex, lualatex, latexmk, tectonic, wkhtmltopdf, weasyprint, pagedjs-cli, prince, context, and typst. The HTML-based ones (weasyprint, prince, pagedjs-cli) give you smaller installs and let you style with CSS, at some cost to math typesetting quality compared to native LaTeX.

verify against current docs: that engine list is from the current Pandoc manual and is long, but which engines you actually have depends on what you install (weasyprint is a separate Python package, prince is commercial, etc.). Only promise the reader an engine you have installed and tested.

So "Pandoc vs no-LaTeX" is a false choice. The honest framing is: Pandoc can do this, but you are still installing and configuring something (TeX, or weasyprint, or a headless browser), and for features like mermaid you are wiring up filters.

What Pandoc makes you configure that a browser tool does by default

For a Markdown file that uses the modern feature set, here is what each side asks of you:

Feature Pandoc Browser converter
GFM tables, task lists add --from gfm on by default
Math (......, ......) LaTeX-based engine renders it natively; HTML engines need KaTeX/MathJax KaTeX by default
Mermaid diagrams not built in; add a filter like pandoc-mermaid (needs mermaid-cli) rendered by default
Syntax highlighting built in (--highlight-style) built in
Long code lines wrapping may overflow the page; needs a header include with fvextra breaklines handled by print CSS
Page breaks insert raw \newpage (LaTeX) or a raw HTML break print CSS break-before

The code-overflow point is a real, common Pandoc pain: long lines in code blocks run off the page unless you add a header.tex with \usepackage{fvextra} and \fvset{breaklines}. That is exactly the kind of fiddling a browser-based print pipeline handles for you, because it lays out with CSS.

When Pandoc is the right answer (don't fight it)

Reach for Pandoc when:

  • You need CI/automation: a pandoc input.md -o out.pdf step in a build is clean and scriptable. A browser tool cannot live in your pipeline.
  • You want maximum typographic control: LaTeX's line-breaking, hyphenation, and math rendering are best in class, and Pandoc exposes templates, variables, and filters for deep customization.
  • You are already set up: if TeX Live is installed and your commands work, there is no reason to switch.
  • You are converting between many formats, Pandoc's whole point is being a universal document converter, not just Markdown to PDF.

When the browser converter wins

Reach for PDFMoka's markdown to PDF converter when:

  • You do not want to install TeX, weasyprint, or Chromium just to print one document.
  • Your Markdown uses GFM tables, KaTeX math, and mermaid, and you want them to render without configuring filters.
  • The content is sensitive (internal docs, drafts). The conversion runs entirely in your browser, so the file is never uploaded. Pandoc is also fully local, but online converters generally are not, so if you were comparing against a typical web converter, client-side processing is the privacy-preserving one.
  • You want a preview and done, not a config file.

Bottom line

This is not "Pandoc bad, tool good." Pandoc is a more capable and more general instrument, and for automation or fine typographic control it is the correct choice. The browser converter wins on exactly one axis that matters to a lot of people: zero install, sensible defaults for modern Markdown, nothing to configure. Pick by which of those you care about more. If you're leaning toward the no-install route, convert your Markdown here.

References