Comparison
wkhtmltopdf alternative that is still maintained
For more than a decade wkhtmltopdf was the default command line tool for turning HTML into PDF. It was simple, free, and shipped a single static binary. The project is now archived and no longer maintained, and it renders with an old QtWebKit engine that predates modern CSS. PDFPipe is a hosted alternative that renders pages with a current browser engine, so the CSS you write today, including Tailwind, Bootstrap, flexbox, and grid, actually works.
Why wkhtmltopdf was popular
wkhtmltopdf earned its place. A single binary with no runtime to install made it easy to drop into scripts, cron jobs, and Docker images. It supported headers, footers, page numbers, and table of contents generation out of the box, and the command line was approachable. For straightforward documents built with older, simple CSS it produced acceptable results at zero cost.
Why it is a problem today
The repository is archived, which means no new releases, no security patches, and no bug fixes. More importantly, the bundled QtWebKit engine is a fork of a browser engine that has not tracked the web for years. It does not support CSS Flexbox or Grid, modern color functions, container queries, or current JavaScript. Pages that look perfect in Chrome can break badly in wkhtmltopdf, and there is no longer an upstream team to report it to. Patched system packages exist on some distributions, but you are pinning your output to a frozen, aging renderer.
wkhtmltopdf vs PDFPipe
| Capability | wkhtmltopdf | PDFPipe |
|---|---|---|
| Maintenance status | Archived, unmaintained | Actively maintained |
| Rendering engine | Old QtWebKit | Current browser engine |
| Flexbox and Grid | No | Yes |
| Modern JavaScript | Limited, dated | Full, real browser |
| Install and updates | Self managed binary | None (hosted API) |
| Cost | Free, open source | Usage based pricing |
The CSS gap in practice
Most modern templates lean on Flexbox or Grid for layout. In wkhtmltopdf a display: grid container often collapses or stacks incorrectly, and a display: flex row may not distribute space the way it does in a browser. Web fonts loaded at runtime, CSS variables, and charts drawn with JavaScript can all fail silently. With PDFPipe the same markup is rendered by the same engine your browser uses, so what you preview is what you get.
Replacing the wkhtmltopdf command
A typical wkhtmltopdf call looks like wkhtmltopdf input.html out.pdf. With PDFPipe you POST your HTML to /v1/pdf and receive raw application/pdf bytes back. Here is the equivalent using curl.
curl -X POST https://api.pdfpipe.xyz/v1/pdf \
-H "Authorization: Bearer pp_live_your_key" \
-H "Content-Type: application/json" \
-d '{"html":"<h1>Hello from PDFPipe</h1>","options":{"format":"A4"}}' \
-o out.pdfThe same request from Python is just as short, and there is no binary to install or keep patched.
import requests
resp = requests.post(
"https://api.pdfpipe.xyz/v1/pdf",
headers={"Authorization": "Bearer pp_live_your_key"},
json={
"html": "<div style='display:grid'>Modern CSS works</div>",
"options": {"format": "A4"},
},
)
resp.raise_for_status()
with open("out.pdf", "wb") as f:
f.write(resp.content)How to choose
If you have a legacy pipeline that already works on simple, older CSS and you accept the frozen, unmaintained engine, wkhtmltopdf can keep running. Choose PDFPipe when you want modern CSS to render correctly, when you need JavaScript and web fonts to run before capture, and when you would rather not own a deprecated rendering binary across your servers and containers.
Paste your own HTML into the live playground to see live rendered output instantly, then read the docs for the full options reference.
See pricing →