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

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:

*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.

The Free plan needs no credit card. Sign up, create a key, and render 100 PDFs and 0.5 GB of output a month on the same engine and the same signed webhooks as every paid plan — and test mode exercises the whole pipeline for free without touching that quota.

Migration guide: flags → options

Before — a cron job shelling out to a binary:

wkhtmltopdf -s A4 -O Landscape -B 10mm -T 10mm \
  https://example.com invoice-42.pdf

After — 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",
    "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.

Keep your command lines: pdfik wkhtmltopdf

Often the blocker is not the engine but the interface — cron jobs, deploy scripts and wrappers (pdfkit, wicked_pdf, snappy) that all speak wkhtmltopdf's flags, and nobody wants to rewrite them just to retire a binary. The PDFik CLI (one static binary, MIT-licensed, open source) ships a compatibility mode that takes wkhtmltopdf's own command line, so for most scripts the migration is a single alias:

export PDFIK_API_KEY=sk_live_YOUR_API_KEY
alias wkhtmltopdf='pdfik wkhtmltopdf'

# your existing command lines keep working, unchanged:
wkhtmltopdf -s A4 -O Landscape --footer-center 'Page [page] of [topage]' \
  https://example.com invoice-42.pdf

Every wkhtmltopdf flag falls into one of three classes: mapped to an API option with the same meaning, accepted with a warning because it has no effect in this pipeline, or refused with a reason because it would change your output. Nothing is quietly ignored, and an unknown flag stops the run before anything is submitted — a bad invocation never costs a render. --version and -h are answered anywhere in the argument list, which is exactly what the wrappers probe for, so pdfkit and wicked_pdf keep calling it the way they always did. The full lists live in COMPATIBILITY.md.

There is a container image too — a few megabytes, with no browser inside:

docker run --rm -e PDFIK_API_KEY --user "$(id -u):$(id -g)" \
  -v "$PWD:/work" -w /work ghcr.io/pdfik/cli \
  wkhtmltopdf -s A4 https://example.com invoice-42.pdf

Be clear about what this is: rendering happens in PDFik's cloud, so it is a hosted API wearing a familiar face. It needs network access and an API key, and it is the wrong answer for air-gapped environments for all the reasons above. The engine is sandboxed Chromium rather than Qt WebKit, so your golden files still need re-approval, and toc / --outline are refused rather than emulated. Exit codes are the CLI's own, not wkhtmltopdf's — see the FAQ below if a script branches on them. You do need a key: the Free plan issues one with no credit card, and --test runs are free on every plan.

FAQ

Further reading

• wkhtmltopdf is archived with an open CVE — a field guide to moving off it — the full decision tree across WeasyPrint, Playwright/Puppeteer, Gotenberg and hosted APIs, including where each of them beats PDFik, plus an eight-step migration checklist.
• wkhtmltopdf in Docker in 2026: musl, libssl1.1, and the ways out — the three container errors in detail, the Dockerfile that still works on amd64 and arm64, fonts, and the exits.

Competitor facts last verified: CVE status 2026-08-07, archive and packaging status 2026-09-07. Found something outdated? Tell us and we'll fix it.