PDFPipe

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

CapabilitywkhtmltopdfPDFPipe
Maintenance statusArchived, unmaintainedActively maintained
Rendering engineOld QtWebKitCurrent browser engine
Flexbox and GridNoYes
Modern JavaScriptLimited, datedFull, real browser
Install and updatesSelf managed binaryNone (hosted API)
CostFree, open sourceUsage 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.

bash
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.pdf

The same request from Python is just as short, and there is no binary to install or keep patched.

python
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 →