Skip to content

Alternatives

Moving off wkhtmltopdf

A command-line tool that renders HTML to PDF using an embedded Qt WebKit build. For a decade it was the default way to turn a web page into a document, and it is still wired into a great many invoice and report pipelines.

Why teams move

  • It is no longer maintained. The repository was archived in January 2023 and the GitHub organisation followed in July 2024 — there is nobody to file a bug with.
  • The engine is frozen at a Qt WebKit build far behind modern browsers. Flexbox behaves inconsistently, CSS Grid is absent, and custom properties do nothing — so a stylesheet that works in a browser may not survive the render.
  • CVE-2022-35583, a server-side request forgery rated 9.8 critical, is unpatched and will stay that way. Upstream's position was that it is an application-level concern, so no fix is coming.
  • It renders whatever HTML it is handed. Nothing in the tool states what should happen when a table runs to a second page, so pagination is a property of your CSS and your luck.

The checkable parts

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

What is different here

Nothing to operate, nothing to patch

Rendering happens behind an HTTPS endpoint. There is no binary pinned to an old system library, no base image to rebuild when an advisory lands, and no engine frozen at 2012.

Pagination is stated, not inferred

Every design declares what repeats, what grows, what holds position and what may break across a page. The behaviour that wkhtmltopdf leaves to your CSS is written down and testable here.

Data in, document out

You send JSON rather than assembling an HTML string. The template holds the layout, so escaping bugs and string-concatenated markup stop being part of your document pipeline.

When to stay with wkhtmltopdf

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

  • You render trusted, static HTML on an isolated box, the output already looks right, and you can accept an unmaintained dependency.
  • You need a self-hosted binary with no outbound network calls, and an API is disqualified on that basis alone.

What moving involves

  1. 1 The document is redrawn as a template rather than ported. There is no HTML-to-template converter, and a mechanical translation of a 2012-era stylesheet would carry over the problems you are leaving.
  2. 2 The data you already assemble for the HTML becomes the JSON payload, usually with little change — the same fields, without the markup around them.
  3. 3 A .docx of the existing document can be imported as a starting point if one exists.

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

Moving off Puppeteer A real Chrome renders your page — with a real browser's operational cost. Moving off WeasyPrint A genuinely good paged-media engine — until the rendering has to leave Python. Moving off DocRaptor A genuinely good paged-media engine behind an HTML API — the closest thing here to a peer. Moving off PDFMonkey HTML, CSS and Liquid rendered by Chrome, with a dashboard in front of it. Moving off PDFShift A clean HTML-to-PDF conversion API. Conversion is the whole product. Moving off Carbone Templates authored in Word or LibreOffice — a real strength, with a conversion step attached. Moving off APITemplate.io A visual editor covering PDFs and social images, aimed as much at no-code as at developers.

Render one and compare

Free tier includes 2 templates and 50 watermarked PDF renders per month. No credit card required.

Start building free