COMPARISON

The Hidden Costs of Free PDF Libraries in C#

Published:

Developers searching for "free PDF library C#" will find dozens of NuGet packages that appear to solve their problem at zero cost. In practice, every "free" option in the .NET PDF space carries constraints that surface after development has started — AGPL source code disclosure, missing HTML support, abandoned dependencies with unpatched CVEs, or revenue thresholds that trigger mandatory licensing. This article documents those constraints with specific evidence so you can evaluate the real cost before committing.

What "Free" Actually Means Across the .NET PDF Ecosystem

The word "free" maps to five distinct licensing models in this space, and confusing them creates real legal and technical exposure:

MIT/Apache (genuinely permissive): PdfSharp uses the MIT license. No revenue restrictions, no copyleft, no disclosure requirements. You can ship it in commercial software without conditions. The trade-off is capability, not licensing.

AGPL (open source with teeth): iTextSharp (iText Core) uses the AGPL. If your application is accessible over a network — which includes every web app, API, and SaaS product — you must release your entire application's source code under AGPL. Not just the PDF generation code. Your proprietary business logic, your authentication system, everything.

Revenue-gated community license: QuestPDF's Community License covers businesses under $1M annual gross revenue. Cross that threshold and a commercial license becomes mandatory, regardless of how much you actually use QuestPDF.

Abandoned and unmaintained: wkhtmltopdf and its .NET wrappers (DinkToPdf, NReco.PdfGenerator) have no active development. The GitHub organization was archived in July 2024. Known CVEs will never be patched.

Free but operationally expensive: Puppeteer Sharp and Playwright are MIT-licensed, but they require managing external browser processes — downloads, process pooling, memory leak monitoring, crash recovery. The infrastructure cost can exceed a commercial license.

iTextSharp and the AGPL Trap

iTextSharp is one of the most downloaded PDF packages on NuGet, with approximately 30 million downloads. Many developers install it assuming it's free to use commercially. It isn't.

The Licensing Reality

In 2009, iText switched from LGPL to AGPL. Under AGPL, deploying iText in any network-accessible application requires you to release your entire application's source code under AGPL terms. iText's own documentation states: "You may not deploy it on a network without disclosing the full source code of your own applications under the AGPL license."

This isn't theoretical. It applies to your web app, your internal tools exposed over a network, your SaaS product, and your client projects.

Active Enforcement

iText and parent company Apryse pursue license compliance aggressively. A September 2025 analysis from Beeman & Muchmore documented the enforcement pattern, noting the company "went on a hiring blitz in their license compliance department around the time of their February 2023 rebranding." The law firm characterized these practices as similar to patent trolling — companies "snapping up patent portfolios and indiscriminately asserting them for cost of defense/nuisance settlements."

iText itself has acknowledged this posture, stating that legal action is rarely needed because "the people involved understood that it wasn't in their interest getting sued."

The Old Version Loophole Doesn't Work

Some developers try iTextSharp 4.1.6, released under LGPL. iText's FAQ explicitly addresses this: those versions are end-of-life with no security patches, and the API predates modern PDF requirements.

What Commercial Licensing Costs

For companies that cannot comply with AGPL, iText offers commercial licenses. As of 2024, iText transitioned to subscription-based licensing, moving away from perpetual models. Pricing is not published — you contact sales for a quote. Third-party data from Vendr suggests costs range from $15,000 to $210,000 annually depending on usage volume.

Compare that to IronPDF's perpetual license starting at $749, with pricing published on the website and no annual subscription required for continued use.

What iText's HTML Rendering Actually Produces

The pdfHTML add-on does not use a browser engine. Here's what happens when you try modern CSS:

using iText.Html2pdf;
using iText.Kernel.Pdf;

// This HTML uses CSS Flexbox — a standard layout technique since 2015
string html = @"
<html><head><style>
    .container { display: flex; gap: 20px; justify-content: space-between; }
    .card { flex: 1; padding: 15px; border: 1px solid #ccc; border-radius: 8px; }
</style></head>
<body>
    <div class='container'>
        <div class='card'>Revenue: $1.2M</div>
        <div class='card'>Expenses: $890K</div>
        <div class='card'>Profit: $310K</div>
    </div>
</body></html>";

using var writer = new PdfWriter("itext-output.pdf");
using var pdf = new PdfDocument(writer);
// Result: three cards stacked vertically, no flex layout applied
// The gap, border-radius, and justify-content are ignored
HtmlConverter.ConvertToPdf(html, pdf, new ConverterProperties());
using iText.Html2pdf;
using iText.Kernel.Pdf;

// This HTML uses CSS Flexbox — a standard layout technique since 2015
string html = @"
<html><head><style>
    .container { display: flex; gap: 20px; justify-content: space-between; }
    .card { flex: 1; padding: 15px; border: 1px solid #ccc; border-radius: 8px; }
</style></head>
<body>
    <div class='container'>
        <div class='card'>Revenue: $1.2M</div>
        <div class='card'>Expenses: $890K</div>
        <div class='card'>Profit: $310K</div>
    </div>
</body></html>";

using var writer = new PdfWriter("itext-output.pdf");
using var pdf = new PdfDocument(writer);
// Result: three cards stacked vertically, no flex layout applied
// The gap, border-radius, and justify-content are ignored
HtmlConverter.ConvertToPdf(html, pdf, new ConverterProperties());
Imports iText.Html2pdf
Imports iText.Kernel.Pdf

' This HTML uses CSS Flexbox — a standard layout technique since 2015
Dim html As String = "
<html><head><style>
    .container { display: flex; gap: 20px; justify-content: space-between; }
    .card { flex: 1; padding: 15px; border: 1px solid #ccc; border-radius: 8px; }
</style></head>
<body>
    <div class='container'>
        <div class='card'>Revenue: $1.2M</div>
        <div class='card'>Expenses: $890K</div>
        <div class='card'>Profit: $310K</div>
    </div>
</body></html>"

Using writer As New PdfWriter("itext-output.pdf")
    Using pdf As New PdfDocument(writer)
        ' Result: three cards stacked vertically, no flex layout applied
        ' The gap, border-radius, and justify-content are ignored
        HtmlConverter.ConvertToPdf(html, pdf, New ConverterProperties())
    End Using
End Using
$vbLabelText   $csharpLabel

The output stacks the cards vertically with no flex layout. The gap, border-radius, and justify-content properties are ignored. This is the state of iText's HTML rendering — it approximates CSS 2.1 but does not execute Flexbox, Grid, or JavaScript.

IronPDF renders this correctly because it uses embedded Chromium — the same engine as Chrome. The output matches what you see in the browser:

using IronPdf;

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf(html); // Same HTML as above
pdf.SaveAs("ironpdf-output.pdf");
// Result: three cards in a horizontal row with proper spacing and rounded corners
using IronPdf;

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf(html); // Same HTML as above
pdf.SaveAs("ironpdf-output.pdf");
// Result: three cards in a horizontal row with proper spacing and rounded corners
Imports IronPdf

Dim renderer As New ChromePdfRenderer()
Dim pdf = renderer.RenderHtmlAsPdf(html) ' Same HTML as above
pdf.SaveAs("ironpdf-output.pdf")
' Result: three cards in a horizontal row with proper spacing and rounded corners
$vbLabelText   $csharpLabel

PdfSharp: Genuinely Free, Genuinely Limited

PdfSharp is MIT-licensed with no restrictions. Over 34.9 million NuGet downloads. For commercial use, it's free without conditions. The trade-off is what it can do.

No HTML Rendering — At All

PdfSharp provides a drawing API. You call DrawString(), DrawRectangle(), and DrawImage() with explicit coordinates. There is no HTML parser, no CSS engine, no template system. If your application generates PDFs from HTML templates — invoices from Razor views, reports from dashboard HTML, email-to-PDF archiving — PdfSharp cannot do this.

The commonly suggested workaround, HtmlRenderer.PdfSharp, supports HTML 4.01 and CSS Level 2 only. No Flexbox. No Grid. No JavaScript. No web fonts. If your HTML uses any CSS feature from the last decade, it won't render.

Where PdfSharp Works

PdfSharp works well for generating structured documents from data — invoices with programmatic layouts, simple reports, PDF merging and splitting, watermarks and annotations. If you don't need HTML rendering and your target is Windows, it remains a legitimate option.

QuestPDF: Free Until Your Company Grows

QuestPDF offers an elegant fluent C# API for building documents programmatically. The API design is genuinely good. The licensing model creates a cliff.

The Revenue Threshold

QuestPDF's Community License covers individuals, businesses under $1M annual gross revenue, non-profits, and open source projects. Once your company crosses $1M revenue, a commercial license is mandatory regardless of how extensively you use QuestPDF.

Here's what that looks like as a growth scenario: A startup generating $900K annually uses QuestPDF freely. At $1,000,001, they need a commercial license. If they didn't budget for it, they're choosing between paying for the license or migrating to another library under time pressure. Neither option is free.

Companies approaching the threshold need to account for this in their planning. It's not a surprise if you read the license terms, but many teams discover it after the library is embedded in their codebase.

No HTML Support — By Design

QuestPDF does not render HTML. This is a deliberate design choice, not a missing feature. The library's positioning is "stop fighting with HTML-to-PDF conversion" — it replaces HTML approaches with programmatic C# code.

Despite this clear positioning, developers regularly assume QuestPDF handles HTML because it appears in "C# PDF library" search results alongside HTML-capable libraries. GitHub discussions from 2022 through 2024 show developers discovering this limitation after beginning implementation. The maintainers consistently confirm HTML support is not planned.

wkhtmltopdf Wrappers: Abandoned With Unpatched CVEs

wkhtmltopdf was a popular command-line tool for HTML-to-PDF. Several C# wrappers exist: DinkToPdf, NReco.PdfGenerator, WkHtmlToXSharp. All of them wrap the same abandoned binary.

The Status

The GitHub organization was archived on July 10, 2024. The wkhtmltopdf status page marks the project as deprecated. Homebrew disabled the cask on December 16, 2024. The underlying QtWebKit engine was deprecated by Qt in 2015 and removed in 2016.

Critical Vulnerabilities — Unpatched Forever

CVE-2022-35583 (CVSS 9.8 Critical): Server-Side Request Forgery. An attacker injects an iframe tag into HTML content processed by wkhtmltopdf. The iframe targets http://169.254.169.254/latest/meta-data/ — the AWS EC2 metadata endpoint. The rendered PDF contains the response, which includes IAM credentials.


<iframe src="http://169.254.169.254/latest/meta-data/iam/security-credentials/"
        style="width:100%;height:500px;"></iframe>

<iframe src="http://169.254.169.254/latest/meta-data/iam/security-credentials/"
        style="width:100%;height:500px;"></iframe>
HTML

CVE-2020-21365 (CVSS 7.5 High): Directory traversal allowing remote attackers to read local files through crafted HTML.

These vulnerabilities are documented, publicly exploitable, and will never be patched. Running wkhtmltopdf in production — especially processing user-submitted HTML — creates concrete, exploitable attack surface.

Rendering Quality

Beyond security, wkhtmltopdf's QtWebKit engine is frozen at approximately Safari 2011 capability. No CSS Flexbox, no CSS Grid, limited CSS3 support, unreliable JavaScript execution. Content that displays correctly in any modern browser will render incorrectly through wkhtmltopdf.

The Real Cost of "Free"

Developer Time Is the Largest Cost

A team working around PdfSharp's lack of HTML support — manually positioning every element with coordinate-based drawing commands for layouts that could be expressed in 20 lines of HTML/CSS — burns developer time that has a measurable cost.

A conservative estimate: 2 developer-days per month maintaining workarounds and manual layouts at $150/hour costs $28,800 per year. IronPDF's enterprise license costs less than that. The "free" library costs more in developer productivity than the commercial alternative costs in licensing.

This isn't unique to PdfSharp. Teams managing Puppeteer Sharp's browser processes — writing pooling logic, monitoring for memory leaks, handling crash recovery — are paying in engineering time what they saved in licensing.

Technical Debt Compounds

A December 2025 analysis from Quandary Peak Research put it directly: "The 'free' price tag of open source is a misnomer, obscuring significant hidden costs and potential liabilities."

Every workaround for a missing feature adds code that must be maintained, tested, and migrated when requirements change. The 2022 CISQ report found accumulated software technical debt in the US reached $1.52 trillion. PDF library workarounds contribute to that number every time a team writes coordinate-based layout code instead of using an HTML template.

Security Exposure Has a Dollar Cost

Industry data shows that 82% of open source components are out of date, 75% of codebases contain vulnerabilities, and 49% contain high-risk vulnerabilities. PDF libraries specifically carry elevated risk because they process user-provided content and run with server privileges.

The Equifax breach — 147 million records exposed — resulted from an unpatched vulnerability in an open source component. The financial impact was over $1.4 billion. The attack vector was the same class of vulnerability (processing untrusted input through an unmaintained library) that wkhtmltopdf's CVEs represent.

Migration Is More Expensive Than Getting It Right Initially

Starting with a limited free library and migrating later costs more than selecting an appropriate library initially. Migration involves learning new APIs, rewriting PDF generation code, recreating templates in different formats, regression testing every document type, and validating output across downstream systems. Teams that budget $0 for PDF tooling in year one often spend $50,000+ on migration in year two.

How IronPDF Addresses These Limitations

When I designed IronPDF's architecture, the decision to embed Chromium wasn't about having the latest technology — it was about giving developers results that match what they see in their browser. CSS Flexbox works. CSS Grid works. JavaScript executes. Web fonts render. You write HTML and CSS, and the PDF output matches Chrome.

using IronPdf;

var renderer = new ChromePdfRenderer();

var pdf = renderer.RenderHtmlAsPdf(@"
    <html>
    <head>
        <style>
            .dashboard { display: grid; grid-template-columns: repeat(3, 1fr); gap: 20px; }
            .metric { padding: 20px; background: #f8f9fa; border-radius: 8px; text-align: center; }
            .metric h3 { margin: 0; color: #6c757d; font-size: 0.85rem; }
            .metric .value { font-size: 2rem; font-weight: bold; color: #212529; }
        </style>
    </head>
    <body>
        <div class='dashboard'>
            <div class='metric'><h3>Revenue</h3><div class='value'>$1.2M</div></div>
            <div class='metric'><h3>Users</h3><div class='value'>45,230</div></div>
            <div class='metric'><h3>Uptime</h3><div class='value'>99.97%</div></div>
        </div>
    </body>
    </html>");

pdf.SaveAs("dashboard.pdf");
using IronPdf;

var renderer = new ChromePdfRenderer();

var pdf = renderer.RenderHtmlAsPdf(@"
    <html>
    <head>
        <style>
            .dashboard { display: grid; grid-template-columns: repeat(3, 1fr); gap: 20px; }
            .metric { padding: 20px; background: #f8f9fa; border-radius: 8px; text-align: center; }
            .metric h3 { margin: 0; color: #6c757d; font-size: 0.85rem; }
            .metric .value { font-size: 2rem; font-weight: bold; color: #212529; }
        </style>
    </head>
    <body>
        <div class='dashboard'>
            <div class='metric'><h3>Revenue</h3><div class='value'>$1.2M</div></div>
            <div class='metric'><h3>Users</h3><div class='value'>45,230</div></div>
            <div class='metric'><h3>Uptime</h3><div class='value'>99.97%</div></div>
        </div>
    </body>
    </html>");

pdf.SaveAs("dashboard.pdf");
Imports IronPdf

Dim renderer As New ChromePdfRenderer()

Dim pdf = renderer.RenderHtmlAsPdf("
    <html>
    <head>
        <style>
            .dashboard { display: grid; grid-template-columns: repeat(3, 1fr); gap: 20px; }
            .metric { padding: 20px; background: #f8f9fa; border-radius: 8px; text-align: center; }
            .metric h3 { margin: 0; color: #6c757d; font-size: 0.85rem; }
            .metric .value { font-size: 2rem; font-weight: bold; color: #212529; }
        </style>
    </head>
    <body>
        <div class='dashboard'>
            <div class='metric'><h3>Revenue</h3><div class='value'>$1.2M</div></div>
            <div class='metric'><h3>Users</h3><div class='value'>45,230</div></div>
            <div class='metric'><h3>Uptime</h3><div class='value'>99.97%</div></div>
        </div>
    </body>
    </html>")

pdf.SaveAs("dashboard.pdf")
$vbLabelText   $csharpLabel

This uses CSS Grid, border-radius, custom font sizing, and semantic HTML. PdfSharp can't parse it. QuestPDF can't parse it. iText's pdfHTML renders it as a vertical stack. wkhtmltopdf ignores the grid entirely. IronPDF produces a three-column dashboard that matches the browser.

Licensing Without Surprises

IronPDF uses perpetual licensing — one purchase, use indefinitely. No AGPL source code disclosure. No revenue thresholds. No mandatory subscriptions. Pricing starts at $749 for a single developer and is published on the website, not behind a "contact sales" wall.

Cross-Platform Without Workarounds

IronPDF runs on Windows, Linux, macOS, and Docker containers without libgdiplus dependencies, System.Drawing.Common issues, or native binary installation. The Docker deployment is a standard .NET base image with no additional configuration.

Making the Decision

RequirementPdfSharpQuestPDFiTextSharpwkhtmltopdfIronPDF
Truly free (MIT/permissive)YesUnder $1M revenueNo (AGPL)AbandonedNo
HTML to PDFNoNoLimitedDeprecatedYes
Modern CSS (Flexbox/Grid)NoNoNoNoYes
JavaScript executionNoNoNoLimitedYes
Active security maintenanceYesYesYesNoYes
Published pricingN/AYesNoN/AYes
No revenue thresholdYesNoN/AYesYes

For applications requiring only programmatic PDF creation from data — no HTML templates, no web content — PdfSharp or QuestPDF may be sufficient depending on company size.

For applications converting HTML to PDF with modern CSS, the options narrow to either paying iText's commercial license ($15K–$210K/year), managing Puppeteer's browser infrastructure, or using a commercial library designed for the task. IronPDF's perpetual license at $749 is the lowest-cost path to production-quality HTML rendering.

The phrase "free PDF library C#" attracts developers to solutions that create larger costs downstream. Evaluate based on total cost of ownership — licensing, developer time, security maintenance, and migration risk — not the initial price tag.