WkhtmltoPdf C# Alternative: Supportability Concerns in 2026

\ You're reading this because somebody on your team, security, compliance, a sharp-eyed reviewer at code review, pointed at a NuGet package in your .csproj and asked: is this still maintained, and does it matter for what we're doing with it? The package is a wkhtmltopdf wrapper. Maybe DinkToPdf , maybe Wkhtmltopdf.NetCore , maybe a homegrown Process.Start shim around the CLI. The wrapper is incidental. The thing it wraps is the conversation. A note on who's writing this: as a Developer Advocate at Iron Software, I'm clearly biased, we make IronPDF , in the same neighborhood as wkhtmltopdf C# utilities for HTML to PDF conversion. Treat this as one informed perspective, not a neutral report. I'll walk through what the public record says about the wkhtmltopdf library in May 2026 and hand you a conditions-based framework. Two legitimate answers, and which applies depends on facts about your deployment that I don't have. The following code demonstrates the typical wrapper code you probably have somewhere in your project: using DinkToPdf; using DinkToPdf.Contracts; IConverter converter = new SynchronizedConverter(new PdfTools()); byte[] pdf = converter.Convert(new HtmlToPdfDocument { Objects = { new ObjectSettings { HtmlContent = "<h1>Invoice 12345</h1><p>Total: $250.00</p>" } } }); File.WriteAllBytes("invoice.pdf", pdf); WkhtmltoPdf C# Wrapper to Convert HTML to PDF Output Eight lines, one converter, one PDF file. The reason this code is in production at so many Microsoft .NET shops is that it works to convert HTML to PDF instantly. Whether it should keep being the starting point in 2026 for PDF generation is what this article is built around. What WkhtmltoPdf Did Well in Its Prime Before the conditions analysis, I want to spend real time on what the GitHub banner doesn’t tell you, because the banner reduces a decade of legitimate engineering to a single timestamp. Wkhtmltopdf earned its place. It solved a hard problem with an unreasonably small surface area. The core idea was excellent. Take a real browser engine, WebKit, the same family that powered Safari and early Chrome, embed it in a command-line tool, and let it convert html pages, files, strings, and CSS content to PDF while the browser handled the layout work it had already gotten right. CSS, JavaScript, image formats, fonts, page-break behavior, headers and footers: all of it came along because the WebKit engine handled it. The output looked like the browser said it would look, because it was the WebKit rendering engine rendering to a PDF surface instead of a screen. In an era when most HTML to PDF tools were doing string-replacement on a custom subset of HTML, wkhtmltopdf was running the actual page through the actual layout engine. That was a meaningful jump in quality for PDF creation, and downstream PDF generators have been chasing its rendering capabilities ever since. The deployment story was clean for its time. A single static binary, no Java runtime, no Python interpreter, no Node toolchain. You dropped wkhtmltopdf.exe onto a server and called it from whatever language you happened to be using. .NET, Ruby, PHP, Python, Go: every ecosystem grew a wrapper. That portability is the reason you can still find wkhtmltopdf in production code from at least four distinct technology generations. The CLI was thoughtful. Reading the wkhtmltopdf manual today, the flag set still feels considered: page sizes, margins, headers and footers with positional templating, table of contents generation, cover pages, JavaScript delays, custom HTTP headers for authenticated content. Those customization options covered page size, margins, headers, and footers well. The maintainers took the document-generation problem seriously, and it shows in the surface area. The license was straightforward. Wkhtmltopdf is LGPLv3 . For commercial users, that meant you could ship it with proprietary software as long as you respected the linking terms, and for CLI invocation that bar was low. The license did not surprise anyone in a procurement review. The community output was significant. Wkhtmltopdf processed HTML strings, HTML files, and complex HTML pages to generate pdfs for invoices, statements, contracts, receipts, reports, and archiving web content across a real fraction of the SaaS world. If you have ever hit print or chosen to download a PDF receipt from an early-2010s e-commerce site, there is a non-trivial chance it was a file generated by wkhtmltopdf. That is a free tool doing useful work at scale, for years, with an LGPL license and a small enough binary to fit in a Docker image without complaint. But native support did not extend to encryption, digital signatures, redaction, or stamping directly onto pdf pages. The context changed because the world the tool was built for changed, not because the tool was built poorly. Wkhtmltopdf in 2015 was a reasonable, even good, technology choice. In 2026, the answer depends on facts about your specific workload. What "Archived" Means on GitHub, Specifically GitHub’s archive feature is not metaphorical. When a repository is archived, it becomes read-only at the platform level: no new issues, no PRs, no commits, no releases. It is an open source tool and a popular tool whose maintenance state is now frozen. The owner has actively said: this codebase is no longer being maintained by us. For wkhtmltopdf, the archive timestamp is January 2, 2023, 1,225 days ago as of this writing. The whole wkhtmltopdf GitHub organization is similarly closed off. The wkhtmltopdf.org homepage still serves docs and download links, and you can still find how to install it there, but archived upstream is not the same thing as active maintenance. The GitHub side is structurally inert. You can read the code. You cannot get a fix into it. The last upstream release is 0.12.6, dated June 10, 2020 , 2,161 days ago. There is no roadmap and no indication the archive is temporary. The maintainer’s own status page , written before the archive event, is candid in a way I respect. The relevant passage reads, verbatim, about a command-line tool built on the qt webkit rendering engine: “Qt 4 (which wkhtmltopdf uses) hasn’t been supported since 2015, the WebKit in it hasn’t been updated since 2012.” That means wkhtmltopdf supports neither modern CSS3 nor Flexbox or Grid layouts. The same status page recommends alternatives: “If you’re using it for report generation (i.e. with HTML you control), also consider using WeasyPrint or the commercial tool Prince.” And: “If you’re using it to convert a site which uses dynamic JS, consider using puppeteer or one of the many wrappers it has.” It also includes an explicit warning: “Do not use wkhtmltopdf with any untrusted HTML – be sure to sanitize any user-supplied HTML/JS, otherwise it can lead to complete takeover of the server.” The maintainer’s framing is a useful map. The status page does not tell every team to migrate. It tells teams that the input-trust boundary matters, and points readers toward different tools depending on what they’re doing. The Qt WebKit Root Cause In 2015, Qt announced that QtWebKit was deprecated and would be removed from the Qt 5.6 release , in favor of QtWebEngine, built on headless Chromium, rather than the older Qt WebKit rendering engine used by wkhtmltopdf. From 2016 onward, every official Qt release has shipped without QtWebKit. Community efforts to keep QtWebKit alive exist, but they package WebKit versions years behind upstream, not the same as ongoing engine-level maintenance. Wkhtmltopdf is built on a patched fork of Qt 4 , itself archived, embedding the older WebKit. As a command-line tool, it uses an outdated version of the Qt WebKit rendering engine, which lacks support for modern CSS3, Flexbox, and Grid layouts. So when the status page says the WebKit “hasn’t been updated since 2012,” it’s precise: the rendering engine inside the binary is a 2012-vintage WebKit fork inside a 2015-deprecated Qt fork, with neither layer receiving upstream security patches. That’s the reason a community fork picking up engine-level maintenance has never materialized at meaningful scale, leaving the tool lacking full support for modern web standards. It also depends on archived native binaries rather than a fully managed .NET library. The CVE Picture, Stated Plainly The published vulnerabilities are not theoretical. The most cited is CVE-2022-35583 , an SSRF issue in wkhtmltopdf 0.12.6 with a CVSS 3.1 base score of 9.8 , the “critical” tier. The advisory states: “wkhtmlTOpdf 0.12.6 is vulnerable to SSRF which allows an attacker to get initial access into the target’s system by injecting iframe tag with initial asset IP address on its source. This allows the attacker to takeover the whole infrastructure by accessing their internal assets.” There is also CVE-2020-21365 , a directory traversal issue in wkhtmltopdf through 0.12.5. The Snyk advisory for CVE-2022-35583 lists “no fixed version,” and that field will stay empty because the upstream cannot ship one. The honest part. The project’s stated position on CVE-2022-35583 is that the SSRF vector is a property of application input handling rather than an engine defect. That position is contestable, and I’d argue it understates the architectural piece, but it’s part of the public record. Using an unmaintained binary with known CVEs is a gamble in production environments. The mitigation everyone reaches for is the –disable-local-file-access flag, which restricts the renderer’s ability to fetch file:// URLs. That helps with the local-file-disclosure side. It does not, on its own, address the SSRF side, where the iframe payload points at an internal HTTP endpoint or a cloud metadata service like 169.254.169.254. Mitigating the SSRF properly requires explicit network-egress controls, strict input handling, and a documented posture on what your renderer is allowed to reach. The reason is that the wkhtmltopdf executable is still an external executable processing crafted HTML or command arguments. None of that happens automatically. It is real, ongoing work with real security risks. That point is load-bearing: CVE-2022-35583 is not mitigated by routine application practices. Mitigating it is explicit work, and whether your team will commit to that work — visibly, on a recurring basis — is one of the conditions that decides which path applies. The Conditions That Decide Which Path Applies The documentary facts above are the same regardless of who's reading. What changes from team to team is the workload context. Five conditions matter. Who controls the HTML inputs. If the HTML is generated entirely by your own code from your own database, the SSRF surface is structurally narrower: there's no attacker-controlled iframe to inject. If the HTML includes any user-supplied content, even fragments like a free-text description field, the surface widens substantially and the maintainer's warning about untrusted HTML applies. Whether the rendering surface has network egress. If outbound HTTP is restricted to an explicit allowlist (no cloud metadata endpoints, no internal service IPs), the SSRF impact is contained even if the input vector is reachable. If it runs in a default container with default networking, the impact is whatever the network permits, which on many cloud platforms is a lot. Whether the SBOM is audited externally. If your bill of materials is reviewed only by your internal team, you can document the situation, accept the risk, and move on. If it's reviewed by customers' security teams, SOC 2 auditors, or ISO 27001 assessors, an unmaintained renderer with a published critical CVE and no fixed version comes up in every review, and the cost of explaining it compounds. Whether the regulatory environment requires patch traceability. PCI DSS, HIPAA, FedRAMP, and similar regimes ask whether your dependencies are receiving security patches within stated windows. Wkhtmltopdf does not produce patches. Some auditors will accept a documented compensating-control posture; others treat the absence of a patch pipeline as a finding. Your auditor's posture decides this one. Whether your team can carry the compensating-control overhead. Running an archived dependency responsibly means owning the security posture the upstream used to own: monitoring for new CVE disclosures, maintaining the network and input controls, documenting the posture in a way that survives staff turnover. Real work, accruing every quarter. These conditions cluster. An internal reporting tool with database-templated HTML on a locked-down host, internal-only SBOM, no patch-traceability requirement, sits in one cluster. A customer-facing SaaS with user-supplied content, externally-audited SBOM, and SOC 2 reviewers sits in a very different one. Same software. Different conclusions. The Two Paths Two legitimate responses to the wkhtmltopdf situation in 2026, and they are genuinely both legitimate. Path A: Continue with WkhtmltoPdf, deliberately, under compensating controls and install WkhtmltoPdf Appropriate when most of the following hold: HTML inputs fully controlled by your own code, restricted network egress, internal-only SBOM, no regulatory patch-traceability requirement, and team bandwidth for the ongoing work. What "deliberately" means in practice: Explicit mitigation of CVE-2022-35583. The load-bearing piece. At minimum: invoke wkhtmltopdf with --disable-local-file-access, run the renderer in a network sandbox that blocks egress to internal IP ranges and cloud metadata endpoints (169.254.169.254 and equivalents), and ensure the HTML input pipeline does not pass user-supplied content without sanitization. None of these is optional under this path. A documented patch-delivery posture. A written internal acknowledgment that upstream patches are not expected, the codebase is archived, and the team has accepted the resulting risk profile. A planned reevaluation cadence. Twelve months is reasonable. The reevaluation doesn't have to result in migration; it has to be a real check that the conditions still hold. A named owner. Somebody who knows the dependency is archived, knows what the mitigations are, and gets paged if the situation changes. This path costs ongoing attention. In exchange, you keep a tool that works, avoid a migration you don't strictly need, and make the call on your own timeline. For the right workload, it is a defensible choice. A team meeting those conditions is making a risk-adjusted decision, not avoiding one. Path B: Migrate to an alternative for HTML to PDF conversion Appropriate when any of the following hold: HTML inputs include user-supplied content, externally-audited SBOM, regulatory environment requiring patch traceability, team unwilling to carry the compensating-control overhead, or a preference for tooling with an active upstream. The maintainer's status page recommends WeasyPrint , Prince , or Puppeteer depending on use case. On the .NET commercial side, IronPDF is one option I'm naturally going to know best, and there are others. The migration cost is real but bounded: typically a focused day or two for a single template, plus visual-regression testing. You do the work once, and the supportability question stops appearing in your audits. Closing: The Conditions Test The documentary record on wkhtmltopdf is settled, the archive flag, the 2020 last release, the CVE state, the Qt WebKit deprecation timeline, the maintainer's status page. None are editorial, and none will change on a timeline that affects your 2026 planning. What's not settled is which of the two paths fits your workload. Path A — continue with wkhtmltopdf under compensating controls — is for teams with fully controlled HTML inputs, restricted network egress, internal-only SBOMs, no regulatory patch-traceability requirement, and the bandwidth to carry explicit ongoing work: mitigating CVE-2022-35583, documenting the patch-delivery posture, and reevaluating on a planned cadence. Path B — migrate to an alternative — is for teams whose HTML inputs include user-supplied content, whose SBOM is externally audited, whose regulatory environment requires patch traceability, or who prefer tooling with an active upstream. The maintainer's status page recommends WeasyPrint, Prince, or Puppeteer; commercial .NET options including IronPDF are also available. Run the conditions test against your workload. If most Path A conditions hold and your team will do the work, Path A is defensible: make the decision deliberately, write it down, name an owner, put a reevaluation on the calendar. If most Path B conditions hold, plan the migration and treat the visual-regression work as the real cost. Both are legitimate engineering positions for the conditions they apply to. The position that isn't legitimate is the third: running an archived dependency without having made the call, without compensating controls, and without an owner. That's the situation the conditions test exists to retire. Retiring Wkhtmltopdf from Your Software Bill of Materials? If your SOC 2 audit, external security scan, or regulatory compliance posture means you can no longer run an archived 2012-era rendering engine in production, take a look at IronPDF. IronPDF replaces vulnerable wkhtmltopdf wrappers with a fully managed, enterprise-backed .NET library that embeds a modern, actively patched Chromium core. No More Security Debt: Say goodbye to $CVE\text{-}2022\text{-}35583$ SSRF risks with active, vendor-maintained patch cycles. Modern Web Standards: Full out-of-the-box support for CSS3 Flexbox, Grid, custom web fonts, and complex JavaScript rendering. 👉 Get a Fully Functional IronPDF Free Trial and modernize your HTML-to-PDF pipeline in minutes. \ :::info Disclaimer: This article is paid content. HackerNoon’s editorial team has reviewed it for clarity and quality standards, but the views, claims, benchmarks, and comparisons expressed are solely those of the sponsor, and HackerNoon assumes no responsibility for third-party assertions contained in sponsored content. ::: \