Rendering HTML to PDF with a headless-browser pool

The most honest way to turn HTML into a PDF is to let a browser print it. Here's how PDF Server does that at scale.

There are two ways to make a PDF from HTML: reimplement a slice of a browser’s layout engine, or use an actual browser. PDF Server takes the second path — it drives headless Chromium (or Firefox) over the Chrome DevTools Protocol, so the PDF is exactly what the browser would print. Modern CSS, web fonts, SVG, flexbox, grid, and JavaScript all just work.

Templates, not code

You don’t fork the service to add a document — you add a template directory: an HTML template (Mustache, Handlebars, Go, or static), an optional JSON Schema, PDF parameters, assets, partials, and examples. Build your image on top of the base image, and you have a PDF microservice.

The interesting part: managing browsers

Browsers are heavy and, notoriously, leaky — Chromium spawns helper processes (GPU, renderers, a crash handler) that aren’t children of the main process. PDF Server pools browser instances and, on teardown, launches each browser in its own process group and escalates from SIGTERM to SIGKILL across the whole group, polling /proc to confirm every helper is gone. No zombie processes, even under churn.

Rendering is asynchronous: a small futures scheduler runs renders on a worker pool sized to the browser pool, so concurrency and browser count stay in lockstep.

Compositions

Some documents are assembled from parts. A composition produces a data-driven plan — with a jq or JavaScript planner — renders each part, and merges the PDFs into one. Cover page + body + a remotely-fetched appendix, in one request.

Try it

Explore the Gallery to see real PDFs rendered from the examples, or start with the Quickstart.

Want a feature or commercial support? Email me .