Puppeteer or Playwright (libraries)
Drive headless Chromium from Node (or Python/Java/.NET with Playwright) and call page.pdf(). Rendering quality is the modern-web gold standard.
Choose it when: Choose it when you already run browser automation, volume is modest, and you have engineering time to operate the fleet: Chromium wants 200 to 500 MB per instance, cold launches cost hundreds of milliseconds, and queueing, crash recovery and monitoring are yours to build.
WeasyPrint (Python library)
A free, open-source, print-first engine with excellent CSS paged-media support and no browser involved.
Choose it when: Choose it when your stack is Python, documents are static (it executes no JavaScript, so no canvas charts), and you want a lightweight dependency instead of a service. Complex modern CSS layouts may need testing; it is not a browser engine.
Gotenberg (self-hosted container)
A free Docker service wrapping headless Chromium and LibreOffice behind a stateless HTTP API.
Choose it when: Choose it when you want a free self-hosted endpoint and are comfortable operating containers: you still own scaling, upgrades and hardening, and there is no templating, metering or document post-processing built in.
DocRaptor / Prince (specialist engine)
Prince pioneered CSS paged media; DocRaptor sells it as an API. Footnotes, advanced float rules and print typography beyond what browser engines do.
Choose it when: Choose it when your documents genuinely use Prince-specific capabilities and volume is modest: entry pricing is $15 for 125 documents a month (published, checked 2026-08-06), and the CSS profile differs from the web CSS your team writes.
Hosted rendering APIs (PDFShift, PDFBolt and peers)
Cloud APIs around headless Chromium: send HTML, get a PDF, no infrastructure.
Choose it when: Choose one when documents are not sensitive, volume fits their tiers, and you do not need stored templates or batch tooling. Compare metering models carefully: some count credits by output size rather than documents.
KimiDoc (ours)
A current Chromium-class engine with the product built around it: stored templates with a live editor, 100+ starters, batch jobs to 40,000 documents, encryption and watermarking, and the option wkhtmltopdf users often chose it for in the first place: running entirely on your own server under a per-server licence.
Choose it when: Choose it when documents carry data you would rather not send to a third party, when you want templates and batches without building a harness, or when you want one vendor accountable for the whole path. It is commercial: the hosted free tier renders 100 documents a month, self-hosted is licensed, not free.
Migrating, whichever you choose
Whatever you pick, the migration is similar: your HTML carries over (a modern engine renders it more faithfully, not less), CLI flags become API options, and --header-html / --footer-html become CSS @page margin boxes with counter(page). Our detailed mapping is in the wkhtmltopdf comparison, and it applies to any Chromium-class target.
Evaluating options?
Our side-by-side pages are dated and sourced, and say plainly when the other tool is the right choice.