wkhtmltopdf alternative: PDFik vs wkhtmltopdf
wkhtmltopdf served a generation of invoice generators, but its GitHub repository was archived on January 2, 2023 — no maintainers, no releases, and an unpatched critical vulnerability (CVE-2022-35583, CVSS 9.8) that will never be fixed. Its Qt WebKit engine predates CSS Grid, modern Flexbox and most of ES6. This page is an honest comparison: where the old tool still wins, and how migration actually looks.
Quick verdict
Stay on wkhtmltopdf if:
- your environment is air-gapped or offline — a hosted API cannot help there;
- you render only fully trusted input, your legacy ES5-era templates already look right, and $0 matters more than maintenance;
- documents must never leave your infrastructure for compliance reasons.
Choose PDFik if:
- your templates use modern CSS — Grid, Flexbox, web fonts, variables — which Qt WebKit silently mangles;
- you render user-supplied HTML or URLs and do not want to own an unpatched SSRF CVE: PDFik runs every job in sandboxed Chromium with request-level SSRF filtering;
- you want an async queue, signed webhooks with retries, and a status page instead of babysitting a binary.
Feature matrix
| Capability | wkhtmltopdf | PDFik |
|---|---|---|
| Rendering engine | Qt WebKit (frozen ~2015) | Headless Chromium (current) |
| CSS Grid / modern Flexbox | No | Yes |
| Modern JavaScript (ES6+) | No (ES5 era) | Yes |
| Maintained | No — archived Jan 2023 | Yes |
| Known critical CVE | CVE-2022-35583, unpatched | — |
| Runs offline / air-gapped | Yes | No |
| License cost | Free (LGPL) | Free tier, paid plans from $29/mo |
| Async queue + signed webhooks | No (build your own) | Built in, HMAC-signed, on every plan |
| Sandboxing of untrusted input | Your responsibility | Sandboxed Chromium + SSRF filtering |
| Headers / footers | Yes (flags) | Yes (HTML templates, all plans) |
| Official SDKs | Community wrappers | JavaScript/TypeScript, Python, Java |
| SLA | — | 99.5% on paid plans |
Pricing, honestly
wkhtmltopdf is free software — an API cannot beat $0 on license price. What you pay for is what you stop doing: patching a dead dependency, running render servers, building queues and retry logic, and carrying the security risk of an unfixable CVE. PDFik's pricing is fully published:
| Plan | Monthly | PDFs / month | Generated data | Derived $ per 1,000 PDFs* |
|---|---|---|---|---|
| Free | $0 (card verified, not charged) | 100 | 0.5 GB | — |
| Starter | $29 ($23 annual) | 5,000 | 10 GB | $5.80 |
| Pro | $99 ($79 annual) | 50,000 | 50 GB | $1.98 |
| Business | $449 ($359 annual) | 500,000 | 300 GB (+$0.55/GB add-on) | $0.90 |
*Derived from the monthly price divided by the plan's PDF quota at full utilization. Downloads never debit the data quota. Full details on the pricing page.
Migration guide: flags → options
| wkhtmltopdf flag | PDFik request option |
|---|---|
-s A4 / --page-size | options.format: "A4" |
-O Landscape / --orientation | options.landscape: true |
-T/-B/-L/-R 10mm (margins) | options.margin: { top, bottom, left, right } |
--background / --no-background | options.print_background: true|false |
--header-center / --footer-html … | options.header_template / options.footer_template (HTML, with pageNumber/totalPages classes) |
--javascript-delay | render block: timeouts and wait selectors (Pro+) |
Before — a cron job shelling out to a binary:
wkhtmltopdf -s A4 -O Landscape -B 10mm -T 10mm \
https://example.com/invoice/42 invoice-42.pdfAfter — one HTTP call, then a signed webhook (or polling):
curl -X POST https://api.pdfik.net/url-to-pdf \
-H "X-API-Key: sk_live_YOUR_API_KEY" -H "Content-Type: application/json" \
-d '{
"url": "https://example.com/invoice/42",
"options": { "format": "A4", "landscape": true,
"margin": { "top": "10mm", "bottom": "10mm" } },
"webhook_url": "https://your.app/webhooks/pdf"
}'
# => { "job_id": "…", "status": "queued", "detail": "…" }The quickstart walks through the full submit → webhook → download cycle in about 60 seconds, and test mode exercises the whole pipeline for free — it never debits your quota.
FAQ
Is wkhtmltopdf still maintained?
No. The GitHub repository was archived on January 2, 2023 and is read-only. There have been no releases, bug fixes, or security patches since.
Is CVE-2022-35583 fixed?
No. The SSRF vulnerability CVE-2022-35583 (CVSS 9.8) affecting wkhtmltopdf 0.12.6 has no patched release, because the project was archived. If your wkhtmltopdf instance ever renders user-supplied HTML or URLs, this risk is permanent.
Will my existing templates render identically on PDFik?
Not pixel-for-pixel — and usually that is the point. wkhtmltopdf uses a Qt WebKit engine frozen around 2015; PDFik renders with sandboxed headless Chromium, so modern CSS (Grid, Flexbox, web fonts) works instead of being silently ignored. Test your real templates first: test mode is free on every plan, and the homepage sandbox renders without an account.
Does PDFik have an offline or self-hosted version?
No. PDFik is a hosted API. If your environment is air-gapped or documents may not leave your infrastructure, a hosted API is the wrong tool — that is a legitimate reason to stay on a local renderer.
How do webhooks work compared to running wkhtmltopdf synchronously?
You submit a job and get a job id immediately; rendering happens asynchronously. When the job finishes, PDFik POSTs a signed (HMAC) notification with the download link to your webhook — retried on a 2/5/15/30/60-second ladder (6 attempts) and then parked in a dead-letter queue. Polling endpoints exist too if you prefer.
Competitor facts (archive status, CVE status) last verified 2026-08-07. Found something outdated? Tell us and we'll fix it.