Why Migrate from wkhtmltopdf?

wkhtmltopdf was archived in January 2023. Its last release was June 2020. Here's what that means for your project.

🛑

Abandoned & Unsupported

The wkhtmltopdf project was officially archived in January 2023. No security patches, no bug fixes, no updates. Debian 13 has already dropped the package entirely.

🛡️

Security Vulnerabilities

Known CVEs remain unpatched. Running wkhtmltopdf in production means accepting unfixed security risks that will never be addressed by the maintainers.

📦

Outdated Rendering

Built on an ancient Qt WebKit engine that doesn't support modern HTML5, CSS3, Flexbox, Grid, or ES6+ JavaScript. Your PDFs look broken with modern templates.

🔌

Difficult Installation

Requires native system dependencies, X11 libraries, and specific font packages. Docker setups are fragile. Alpine Linux support is unreliable.

wkhtmltopdf vs PDFSpark

A side-by-side comparison of the old guard versus the modern alternative.

wkhtmltopdf

Abandoned since 2023, last release June 2020
Ancient Qt WebKit engine — no CSS3 Grid, Flexbox, or modern JS
Requires native system dependencies and X11 libraries
No web font rendering — custom fonts often break
Unpatched security vulnerabilities (CVEs)
Limited table header repetition across pages
No JavaScript execution for dynamic content
Self-hosted only — you manage the infrastructure

PDFSpark

Actively maintained, regular updates and improvements
Chromium engine — full CSS3, Flexbox, Grid, and ES2024 support
Simple REST API — no dependencies, no installation
Full Google Fonts and custom web font rendering
SSRF protection, Helmet security headers, rate limiting
Pixel-perfect rendering identical to Chrome print
Full JavaScript execution with configurable wait strategies
Hosted API — zero infrastructure to manage

Migrate in 5 Minutes

Replace your wkhtmltopdf calls with a single HTTP request. No signup, no API key.

Remove wkhtmltopdf from your system

Uninstall the wkhtmltopdf binary and its system dependencies. You won't need any native packages — PDFSpark is a pure API call.

before (wkhtmltopdf)
# System dependency you no longer need
apt-get install wkhtmltopdf xvfb libxrender1 libfontconfig1
wkhtmltopdf --page-size A4 input.html output.pdf

Replace with a single API call

Send your HTML to PDFSpark's API and receive a PDF in the response. That's it — one POST request replaces the entire wkhtmltopdf toolchain.

after (PDFSpark)
curl -X POST "https://pdfspark.dev/api/v1/pdf/from-html" \
  -H "Content-Type: application/json" \
  -d '{"html": "<h1>Hello World</h1>", "options": {"format": "A4"}}' \
  -o output.pdf

Map your wkhtmltopdf options

Most wkhtmltopdf command-line flags have direct equivalents in PDFSpark's options object.

option mapping
wkhtmltopdf flag              PDFSpark option
──────────────────────────────────────────────
--page-size A4              "format": "A4"
--orientation Landscape     "landscape": true
--margin-top 10mm           "margin": { "top": "10mm" }
--print-media-type          "emulateMediaType": "print"
--javascript-delay 2000     "delay": 2000
--no-background             "printBackground": false
--header-html <file>        "headerTemplate": "<html>..."
--footer-html <file>        "footerTemplate": "<html>..."
--title "Doc Title"         "metadata": { "title": "Doc Title" }

Update your application code

Replace the subprocess call with an HTTP request in your language of choice.

Node.js migration example
// Before: wkhtmltopdf via child_process
const { execSync } = require('child_process');
execSync('wkhtmltopdf --page-size A4 input.html output.pdf');

// After: PDFSpark API call
const res = await fetch('https://pdfspark.dev/api/v1/pdf/from-html', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    html: htmlContent,
    options: { format: 'A4', printBackground: true }
  })
});
const pdf = Buffer.from(await res.arrayBuffer());
fs.writeFileSync('output.pdf', pdf);

Enjoy modern PDF rendering

Your PDFs now render with the same fidelity as Chrome's print output. CSS Grid, Flexbox, web fonts, and JavaScript all work out of the box.

Migration FAQ

Common questions from teams migrating off wkhtmltopdf.

Is PDFSpark really free?

Yes. PDFSpark is completely free with no API keys, no signup, and no usage limits beyond rate limiting (20 requests/minute per IP). It's part of the SoftVoyagers open ecosystem.

Will my existing HTML templates work?

Almost certainly yes, and they'll look better. PDFSpark uses Chromium, which has far superior CSS support compared to wkhtmltopdf's outdated Qt WebKit. Modern CSS (Flexbox, Grid, custom properties, calc()) that broke in wkhtmltopdf will render correctly.

What about header and footer templates?

PDFSpark supports HTML header and footer templates with special classes for page numbers, total pages, date, title, and URL — the same concepts as wkhtmltopdf but with Chromium rendering fidelity.

Can I convert URLs, not just HTML?

Yes. Use the /api/v1/pdf/from-url endpoint to convert any public webpage to PDF. PDFSpark navigates to the URL with a real Chromium browser, executes JavaScript, waits for content, and captures a pixel-perfect PDF.

What if I need to self-host?

PDFSpark is open source. You can clone the repository and run it in your own Docker environment. The Dockerfile is production-ready and uses the official Microsoft Playwright image with Chromium pre-installed.

How does performance compare?

Chromium-based PDF generation uses more CPU per request than wkhtmltopdf, but PDFSpark handles concurrency management, browser pooling, and resource limits for you. For most workloads, the rendering quality improvement far outweighs the slight performance difference.

Stop Using Abandoned Software

Migrate to PDFSpark today. Free, modern, and secure.

Try PDFSpark Free →
Part of the SoftVoyagers Ecosystem