What 'deterministic' actually means for PDF rendering

Most PDF generation tools will tell you they’re reliable. Few will tell you what that actually requires, because the honest answer is a list of things that are individually unglamorous and collectively the whole job.

The Chromium version problem

Headless Chromium is the de facto standard for HTML-to-PDF rendering, and for good reason — it’s the only engine that reliably handles modern CSS, web fonts and print stylesheets the way a browser actually renders them. The catch: Chromium updates constantly, and a new version can shift sub-pixel line heights, change how flexbox resolves an edge case, or alter font hinting just enough that a document rendered today doesn’t pixel-match the same document rendered six months ago.

The fix isn’t complicated, just disciplined: pin the Chromium build per template version, and never silently roll it forward. A template that has been in production for a year should render exactly as it did on day one, unless someone explicitly asks for the newer engine.

Fonts are the second-most common source of drift

A render that depends on a system font, or a font fetched from a CDN at render time, inherits whatever that font looked like at that moment — which is not guaranteed to be the same font tomorrow. Bundling fonts per template, rather than linking to them, removes an entire category of “it looked different in production” reports.

What “identical” actually gets measured against

We check every render against a stored checksum of a known-good output for that template version. If a change anywhere in the pipeline — Chromium, fonts, the merge engine itself — produces a different checksum for the same input, that’s a regression, not a rounding error to shrug off.

None of this is exotic. It’s the difference between a rendering pipeline that happens to work most of the time, and one you can put in a compliance report.