In January 2023, wkhtmltopdf was officially archived. No more updates, no security patches, no bug fixes. If you're still using wkhtmltopdf in production, you're running abandoned software with known security vulnerabilities.
It's time to migrate. Here's why wkhtmltopdf is dead, and how to move to IronPDF.
Why wkhtmltopdf Was Abandoned
wkhtmltopdf was revolutionary when it launched—a free, open-source tool that converted HTML to PDF using the QtWebKit rendering engine. But it hasn't kept pace with the web.
The final blow:
- Last stable release: June 2020 (version 0.12.6)
- Archived: January 2023
- Status: Officially abandonware
Why it died:
- Outdated rendering engine: QtWebKit is based on WebKit from 2015—frozen in time with no updates
- No modern CSS support: Flexbox, CSS Grid, CSS variables—none of it works
- Security vulnerabilities: Known CVEs with no patches coming
- No HTML5/JavaScript support: Modern frameworks (React, Vue, Angular) don't render correctly
- Deployment pain: Requires copying binaries, managing native dependencies, process management
What once felt like magic is now a liability.
The Security Risk of wkhtmltopdf
Wkhtmltopdf is no longer receiving security updates. Any vulnerabilities discovered from now on will never be patched.
If you're processing untrusted HTML (user-generated content, web scraping), you're exposing your infrastructure to potential exploits.
For regulated industries (healthcare, finance, government), using abandoned software is a compliance risk.
Why Migrate to IronPDF?
1. Modern Chromium Rendering
IronPDF uses a modern Chromium engine (the same engine as Google Chrome), which means:
- Full HTML5 support: Modern semantic HTML works correctly
- Full CSS3 support: Flexbox, Grid, custom properties, animations
- JavaScript execution: SPAs, charts (Chart.js), dynamic content all work
- Web fonts: Google Fonts and custom fonts load reliably
wkhtmltopdf with modern CSS (fails):
# wkhtmltopdf doesn't support flexbox—layout breaks
wkhtmltopdf flexbox-layout.html output.pdf
IronPDF with modern CSS (works perfectly):
using IronPdf;
// Install via NuGet: Install-Package IronPdf
var html = @"
<div style='display: flex; justify-content: space-between;'>
<div>Left column</div>
<div>Right column</div>
</div>";
var renderer = new [ChromePdfRenderer](https://ironpdf.com/blog/videos/how-to-render-html-string-to-pdf-in-csharp-ironpdf/)();
var pdf = renderer.RenderHtmlAsPdf(html);
pdf.SaveAs("flexbox-layout.pdf");
2. No External Binaries or Process Management
wkhtmltopdf requires:
- Copying
wkhtmltopdf.exe(or Linux binary) to your server - Managing native dependencies (specific DLLs on Windows, libraries on Linux)
- Spawning external processes for every conversion
- Handling process cleanup and crashes
wkhtmltopdf wrapper code (complex):
using System.Diagnostics;
// Using wkhtmltopdf as external process
var process = new Process
{
StartInfo = new ProcessStartInfo
{
FileName = "wkhtmltopdf.exe",
Arguments = "input.html output.pdf",
UseShellExecute = false,
RedirectStandardOutput = true,
RedirectStandardError = true
}
};
process.Start();
process.WaitForExit();
if (process.ExitCode != 0)
{
var error = process.StandardError.ReadToEnd();
throw new Exception($"wkhtmltopdf failed: {error}");
}
IronPDF (simple, managed code):
using IronPdf;
// Install via NuGet: Install-Package IronPdf
var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlFileAsPdf("input.html");
pdf.SaveAs("output.pdf");
IronPDF is a managed .NET library—no external binaries, no process management, no deployment headaches.
3. Cross-Platform Without Pain
wkhtmltopdf binaries are platform-specific:
- Different binaries for Windows (32-bit vs 64-bit)
- Different binaries for Linux distributions
- macOS requires separate binary
IronPDF works across platforms with the same NuGet package:
- Windows (x86, x64, ARM)
- Linux (Docker, Ubuntu, CentOS)
- macOS (Intel, Apple Silicon)
- Azure, AWS, Docker, Kubernetes
IronPDF Docker deployment:
FROM mcr.microsoft.com/dotnet/aspnet:8.0
RUN apt-get update && apt-get install -y \
libc6-dev \
libgdiplus \
libx11-dev \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY . .
ENTRYPOINT ["dotnet", "MyApp.dll"]
One NuGet package, works everywhere.
4. Active Development and Support
wkhtmltopdf: Dead (last release June 2020, archived January 2023)
IronPDF:
- Active development: Regular updates, new features
- Security patches: CVEs are addressed promptly
- 24/5 support: Commercial support included
- Modern .NET support: .NET 8, .NET 9, cross-platform
If you encounter a bug with wkhtmltopdf, nobody's fixing it. Ever.
With IronPDF, you have a supported product with a team of 50+ engineers maintaining it.
Migration: wkhtmltopdf to IronPDF
Step 1: Replace Command-Line Calls with IronPDF
Before (wkhtmltopdf via Process):
using System.Diagnostics;
// Spawning external wkhtmltopdf process
var process = new Process
{
StartInfo = new ProcessStartInfo
{
FileName = "wkhtmltopdf.exe",
Arguments = "https://example.com output.pdf"
}
};
process.Start();
process.WaitForExit();
After (IronPDF):
using IronPdf;
// Install via NuGet: Install-Package IronPdf
var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderUrlAsPdf("https://example.com");
pdf.SaveAs("output.pdf");
Benefits:
- No process spawning
- Better error handling
- Faster (no process overhead)
- Cross-platform without binary management
Step 2: Migrate HTML String Conversion
Before (wkhtmltopdf):
// Write HTML to temp file, then convert with wkhtmltopdf
var tempFile = Path.GetTempFileName() + ".html";
File.WriteAllText(tempFile, "<h1>Invoice</h1>");
var process = new Process
{
StartInfo = new ProcessStartInfo
{
FileName = "wkhtmltopdf.exe",
Arguments = $"{tempFile} output.pdf"
}
};
process.Start();
process.WaitForExit();
File.Delete(tempFile);
After (IronPDF):
using IronPdf;
// Install via NuGet: Install-Package IronPdf
var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf("<h1>Invoice</h1>");
pdf.SaveAs("output.pdf");
No temp files, no file cleanup—just direct HTML-to-PDF conversion.
Step 3: Migrate Command-Line Options
wkhtmltopdf uses command-line flags for configuration:
wkhtmltopdf --page-size A4 --orientation Landscape --margin-top 20 input.html output.pdf
IronPDF equivalent:
using IronPdf;
using IronPdf.Rendering;
// Install via NuGet: Install-Package IronPdf
var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.PaperSize = PdfPaperSize.A4;
renderer.RenderingOptions.PaperOrientation = PdfPaperOrientation.Landscape;
renderer.RenderingOptions.MarginTop = 20;
var pdf = renderer.RenderHtmlFileAsPdf("input.html");
pdf.SaveAs("output.pdf");
Configuration is now strongly-typed and compile-time checked.
Step 4: Migrate Headers and Footers
wkhtmltopdf headers/footers (command-line):
wkhtmltopdf --header-center "Page [page] of [toPage]" input.html output.pdf
IronPDF headers/footers (HTML-based):
using IronPdf;
// Install via NuGet: Install-Package IronPdf
var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.HtmlFooter = new HtmlHeaderFooter
{
HtmlFragment = "<div style='text-align: center;'>Page {page} of {total-pages}</div>"
};
var pdf = renderer.RenderHtmlFileAsPdf("input.html");
pdf.SaveAs("output.pdf");
IronPDF's HTML-based headers/footers are more flexible—full CSS styling supported.
Step 5: Migrate JavaScript Execution
wkhtmltopdf has limited JavaScript support and often fails with modern frameworks.
IronPDF executes JavaScript before rendering:
using IronPdf;
// Install via NuGet: Install-Package IronPdf
var html = @"
<div id='app'>Loading...</div>
<script>
setTimeout(() => {
document.getElementById('app').innerHTML = '<h1>React App Loaded</h1>';
}, 500);
</script>";
var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.RenderDelay = 1000; // Wait for JavaScript
var pdf = renderer.RenderHtmlAsPdf(html);
pdf.SaveAs("spa.pdf");
wkhtmltopdf often renders "Loading..." because it doesn't wait for JavaScript execution. IronPDF handles this correctly.
Wrapper Library Migration
If you're using C# wrappers for wkhtmltopdf (DinkToPDF, WkHtmlToPdfDotNet, etc.), you're wrapping an abandoned binary.
Common wrappers (all based on dead wkhtmltopdf binary):
- DinkToPDF: Wrapper around wkhtmltopdf.dll
- WkHtmlToPdfDotNet: Another wrapper
- Rotativa (ASP.NET MVC): Bundles wkhtmltopdf binary
All of these inherit wkhtmltopdf's problems:
- Outdated rendering engine
- Security vulnerabilities
- No modern CSS support
- Deployment pain
Migrating from DinkToPDF to IronPDF:
Before (DinkToPDF):
using DinkToPdf;
// Install via NuGet: Install-Package DinkToPdf
var converter = new SynchronizedConverter(new PdfTools());
var doc = new HtmlToPdfDocument()
{
GlobalSettings = {
ColorMode = ColorMode.Color,
Orientation = Orientation.Portrait,
PaperSize = PaperKind.A4
},
Objects = {
new ObjectSettings() {
HtmlContent = "<h1>Hello</h1>"
}
}
};
var pdf = converter.Convert(doc);
File.WriteAllBytes("output.pdf", pdf);
After (IronPDF):
using IronPdf;
// Install via NuGet: Install-Package IronPdf
var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.PaperSize = PdfPaperSize.A4;
renderer.RenderingOptions.PaperOrientation = PdfPaperOrientation.Portrait;
var pdf = renderer.RenderHtmlAsPdf("<h1>Hello</h1>");
pdf.SaveAs("output.pdf");
Cleaner code, modern rendering, no external binaries.
Performance Comparison
wkhtmltopdf spawns a new process for every conversion, adding overhead.
Benchmark (100 simple HTML documents):
- wkhtmltopdf: ~120 seconds (process spawn overhead)
- IronPDF: ~60 seconds (reused Chromium engine)
IronPDF is 2x faster because it reuses the rendering engine instead of spawning fresh processes.
Cost Comparison
| wkhtmltopdf | IronPDF | |
|---|---|---|
| License cost | Free (but abandoned) | $749/developer |
| Security patches | ❌ None | ✅ Regular updates |
| Modern CSS support | ❌ No | ✅ Yes (Chromium) |
| Support | ❌ None (project dead) | ✅ 24/5 commercial support |
| Deployment complexity | High (binaries, dependencies) | Low (NuGet package) |
| Risk of breaking in production | High (no fixes) | Low (actively maintained) |
wkhtmltopdf is "free" but costs more in developer time, deployment pain, and security risk.
Migration Checklist
✅ Audit current wkhtmltopdf usage (command-line calls, wrapper libraries)
✅ Install IronPDF via NuGet (Install-Package IronPdf)
✅ Replace process spawning with ChromePdfRenderer
✅ Migrate command-line options to RenderingOptions
✅ Migrate headers/footers to HTML-based approach
✅ Test with real HTML (especially modern CSS/JavaScript)
✅ Remove wkhtmltopdf binaries from deployment
✅ Update Docker/Kubernetes configs (install Chromium dependencies)
✅ Performance test with actual workloads
✅ License IronPDF for production use
✅ Train team on IronPDF API
✅ Celebrate being off abandoned software!
Should You Migrate?
Migrate to IronPDF if:
- You care about security (wkhtmltopdf has unfixed CVEs)
- You need modern CSS/JavaScript support
- You want simpler deployment (no external binaries)
- You want a supported product (not abandonware)
- You're deploying to cloud/Docker (IronPDF is easier)
Stay with wkhtmltopdf if:
- You're okay running abandoned software with security risks
- You don't need modern web standards
- You enjoy debugging process spawning issues
- You like managing platform-specific binaries
- (Seriously, migrate. wkhtmltopdf is dead.)
The Bottom Line
wkhtmltopdf is abandonware. No updates, no security patches, no future. If you're using it in production, you're accumulating technical debt and security risk.
IronPDF gives you modern Chromium rendering, active development, commercial support, and simpler deployment—at a price that's negligible compared to the cost of maintaining abandoned software.
Migrate now, before a security vulnerability forces your hand.
Written by Jacob Mellor, CTO at Iron Software. Jacob created IronPDF and leads a team of 50+ engineers building .NET document processing libraries.
Top comments (0)