The question underneath "which PDF tool should I use" is usually "how much of a real browser do I actually need", and the honest answer decides more than a feature comparison table does.
## wkhtmltopdf: still deployed, not a good starting point today
It renders HTML through a patched, years-old WebKit build, self-hosted, no API key, works fully offline. That last point is genuinely why it is still running in a lot of places, air-gapped systems and legacy pipelines where an external service is not an option.
The cost is that the WebKit build underneath it stopped tracking modern CSS a long time ago, the project's own maintainers have pointed people toward alternatives, and non-Latin scripts need font installation you manage yourself, on your own server, with your own patching burden. If you are starting something new and nothing forces you offline, this is a tool to migrate away from rather than adopt.
## Puppeteer: correct when the input is a real web page
Puppeteer drives an actual headless Chrome instance, so it renders whatever a real browser would, including JavaScript-heavy pages, arbitrary CSS, web fonts. If the thing you need in a PDF is an existing web page rather than data you control, this is usually the right layer, because nothing else on this list can genuinely reproduce a rendered browser page.
The cost is operational: a Chrome install well over 200MB, a browser process to manage and eventually crash-recover, and non-trivial memory per running instance. That is a fair price for pixel-perfect rendering of a page you did not build for PDF output. It is a heavy price for an invoice.
## Where PDFly's API fits
We built ours for the case in between: you have data, not an existing web page, and you want a document out without owning rendering infrastructure. Call the endpoint, you get a PDF back. 15 templates, 11 page sizes, batch generation up to 5 documents per call, and the free tier needs no card. As of this year it also embeds Devanagari and Arabic script fonts automatically when your content needs them; Chinese, Japanese, Korean, Hebrew and Thai still are not supported on either the API or the browser tool, and an unsupported script comes back as a warning in the response rather than silent breakage.
What it will not do is render arbitrary CSS the way a real browser would, or take a URL and screenshot it. If that is the job, it is the wrong tool and Puppeteer is the right one.
## What we are not going to claim
An earlier version of this comparison had specific millisecond ranges for generation time and memory usage across all three options. We never measured those under real production load and cannot stand behind the numbers, so they are gone rather than repeated with more confidence than they deserve. If throughput matters for your decision, benchmark your own actual documents against your own actual traffic pattern; a table in a blog post from any of these vendors is not a substitute for that.
## The actual decision rule
If you are converting a page that already exists as a web page, use Puppeteer. If you are self-hosting for offline or legacy reasons and cannot change that constraint, wkhtmltopdf still runs, with the caveats above. If you are generating documents from your own data and want to avoid owning a browser process, that is what our API is for, and the [reference](/docs) has the full field list rather than a sales pitch.