Moving off PDFMonkey

Why teams move

• The engine underneath is a browser, so the pagination problems of printing a web page come with it — the totals block that splits, the table header that stops repeating on page four.
• Liquid is a text templating language. It fills strings into markup with no notion of what a page is, so anything about layout under pressure has to be solved in print CSS.
• Templates are HTML and CSS in a web editor. That is fine for a developer and a wall for everyone else, which usually means document changes queue behind whoever owns the frontend.
• There is no schema for the data. A renamed field silently produces an empty region rather than a failed request.

The checkable parts

Claims worth verifying rather than taking on trust — each links to its source, checked July 2026.

• Templates are HTML/CSS with Liquid; rendering is Chrome-based.

  PDFMonkey ↗

What is different here

When to stay with PDFMonkey

It is often the right answer. If any of these describe you, this is not a migration worth making.

• Your documents are simple, one or two pages, and reflow has never actually bitten you — in which case the engine underneath does not matter much.
• Your team is comfortable in Liquid and HTML and values holding the template in a format it already knows.
• You are deep into an existing integration and the documents work. Nothing here is worth a migration on its own.

What moving involves

1. 1 Liquid placeholders map closely onto template fields — the substitution model is the same idea, and most templates translate concept for concept.
2. 2 The JSON you already send becomes the render payload, then gets a schema written around it so mismatches surface as errors.
3. 3 The print CSS does not come across, and mostly should not: the reflow behaviour it was fighting for is stated directly in the design.

The API reference covers authentication, the render call and error handling; the template gallery has designs to start from rather than a blank page.

Other migrations