Markdown to PDF without LaTeX: how the browser print pipeline works
Ask how to turn Markdown into a PDF and the canonical answer is Pandoc plus a LaTeX engine — a toolchain that begins with a multi-gigabyte TeX download and often ends with font errors and template debugging. For a resume, a report, or a set of meeting notes, that is a remarkable amount of machinery to stand up.
There is a second route that needs none of it: render the Markdown to HTML, style it with paged CSS, and let the browser's own print engine emit the PDF. This article explains how that pipeline works, why its output is a real document rather than a screenshot, where it beats LaTeX, and where it honestly does not.
The LaTeX tax on a simple job
Pandoc is the right answer for most document conversions, but its PDF writer is an exception: Pandoc does not render PDF itself. It typesets your document as LaTeX source and shells out to an external engine — pdflatex, xelatex, or lualatex — which means a working TeX distribution on your machine. A full TeX Live install runs to several gigabytes; the minimal variants save space until the first missing package error sends you back to the installer.
Cloud converters dodge the install by moving the problem: your file goes to someone's server, waits in a queue, and comes back — if it is under the size limit and you have not hit the daily cap. For confidential drafts, contracts, and unpublished manuscripts, the upload itself is the dealbreaker. The job — turning structured text into a printable page — is not inherently hard. The traditional tooling just makes it look that way.
What the browser print pipeline actually does
The pipeline has three stages, all local. First, the Markdown is converted to HTML — on this site, by the same Pandoc WASM engine that powers every other conversion. Second, that HTML is wrapped in a complete document with a print stylesheet: a fixed page size, real margins, and a typographic hierarchy for headings, lists, code, and tables. Third, the browser's print engine lays out the pages and writes the PDF.
That third stage is doing more than it appears to. Chrome, Edge, Firefox, and Safari all embed a mature pagination engine — the same one that prints receipts and boarding passes — and their "Save as PDF" output is a true PDF: vector glyphs with a text layer. You can select sentences in the result, search it, copy from it, and feed it to a screen reader. It is not a picture of your document; it is your document, paginated.
Paged CSS: the part that makes it look like a document
The difference between a printed web page and a document lives in a handful of CSS rules. The @page rule fixes the sheet — A4 with 16-millimeter margins here — so the layout stops depending on window size. Font sizes step down from the title through the heading levels, and spacing follows print conventions rather than screen conventions.
The subtler rules govern page breaks. Headings carry break-after: avoid, so a section title never sits alone at the bottom of a page while its paragraph starts the next. Tables, code blocks, blockquotes, and images carry break-inside: avoid, so the renderer moves them whole to the next page instead of slicing them in half. These are exactly the rules a word processor applies silently — applying them explicitly is what turns a browser tab into a typesetter.
Where LaTeX still wins
Honesty about the boundary matters. If your document is a thesis with two hundred cross-references, a paper for a journal that demands its exact template, or heavy mathematics, install TeX: nothing else typesets equations the way LaTeX does, and no journal accepts "close enough" on their house style. Bibliography tooling — BibTeX, CSL with precise institutional variants — is also deeper in the TeX world.
That boundary leaves most real documents on the other side. Reports, resumes, documentation, invoices, meeting notes, chapters for review: these need clean typography, sane page breaks, and a table that does not split across pages. For that work the print pipeline is not a compromise — it is the shorter path to the same destination, and the iteration loop is faster because there is nothing to install, compile, or debug.
The privacy and speed dividend
Because every stage runs on your machine, the document never leaves it. There is no upload progress bar because there is no upload; no queue position because there is no queue; no account because there is nothing to meter. The pipeline works on a plane, in a field office, on a machine that has never touched the internet after the page loaded.
Speed follows from the same fact. Conversion and pagination take seconds, and the feedback loop is tight: edit the Markdown, convert again, glance at the preview, print. For anyone iterating on a document — and a PDF is usually the last step of an iteration, not the first — removing the install and the upload removes the friction that makes people avoid producing the PDF at all.
Getting the best result from the print pipeline
A few habits pay off. Start the document with a single level-one heading as its title, and keep the heading hierarchy honest — the page-break rules keep headings attached to their text, but only if the structure is real. Keep tables narrow; a table that fits the printed column survives whole, while an over-wide one wraps its cells. Give images sensible widths, and remember that browsers do not print background colors by default — the stylesheet here deliberately relies on borders and whitespace instead.
Finally, use the print dialog as the last checkpoint. The preview shows the real pagination before anything is saved; it is the moment to switch between A4 and Letter for your audience, and to confirm that no table landed awkwardly. Thirty seconds of preview review is cheaper than a PDF you have to redo after it has been sent.