QuestPDF vs IronPDF: The Revenue Line the License Now Draws

QuestPDF earned its reputation honestly. It arrived when most .NET PDF libraries still made a team think in coordinates and canvases, and offered a fluent, code-first way to compose documents instead, containers and spacing expressed as C# and checked by the compiler. For a document generated straight from data that is often the whole job, and it stays the whole job until the revenue line in the new license moves, the document has to start as HTML, or a signature is required. The question an architecture review should ask is who absorbs those three gaps once the app ships, which is where a side-by-side read starts to price the choice.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where QuestPDF is strong and where its limits show for a .NET team.

A C# Document Tree

QuestPDF's model is a document tree built entirely in C#. A page is described as nested containers, and the layout engine handles pagination, spacing, and overflow, so the same tree behaves consistently whether the invoice is one page or twenty, a pattern a code-first generation path recognizes.

using QuestPDF.Fluent;
using QuestPDF.Helpers;

// compose a page as a container tree, no coordinate math
Document.Create(container =>
{
    container.Page(page =>
    {
        page.Size(PageSizes.A4);
        page.Margin(2, Unit.Centimetre);
        page.Header().Text("Invoice #1042").SemiBold().FontSize(20);
        page.Content().Text("Total due: $250.00");
    });
})
.GeneratePdf("invoice.pdf");

Its standards coverage reaches further than most code-first libraries, with PDF/A archival output, PDF/UA-1 accessibility tagging, and EN 16931 e-invoicing in the box, and the Companion app gives a live preview that refreshes on every save, which is where a repeatable document workflow benefits. That composition model is the strength to weigh against the licensing and capability limits the next sections walk through, the gaps a single rendering package is built to absorb.

The Revenue Line the License Now Draws

The limit that decides most QuestPDF evaluations is not a feature, it is the license, and it changed on 6 July 2026. Community License v3.0 stops applying once a company crosses $1M in annual gross revenue, and publicly traded companies and public-sector bodies are excluded regardless of what they earn, so a team that goes public or crosses that threshold gets a 90-day window to buy a commercial license before continued use is a breach, a compliance deadline landing on legal's desk rather than the deployment-based terms a commercially licensed renderer sets out up front.

The category of the license adds its own review. Community License v3.0 is source-available rather than an OSI-approved open-source license, so a procurement or open-source-compliance team signs off on a different class of terms than a permissive license would ask for, and eligibility runs on good-faith self-certification, which means the burden of tracking whether a company still qualifies sits with the company rather than any tooling that would catch a missed threshold, unlike the flat, deployment-scoped terms a published pricing page states outright.

What Ships, and Under Which License

What separates the two for a .NET project is the license terms and the layers QuestPDF does not ship, not the composition model it does, and the table draws from QuestPDF's own license guide and Document Operations documentation rather than an older post, read against what a single renderer covers.

Capability	QuestPDF	IronPDF
License	Community License v3.0, source-available	Commercial, with support and updates
Revenue eligibility	Community tier stops at $1M annual revenue	No revenue-based restriction
Public or public-sector use	Excluded from the community tier	No such exclusion
Generation model	Code-first fluent composition	Chromium ChromePdfRenderer, plus a direct API
HTML and CSS to PDF	Not supported	Chromium ChromePdfRenderer
Load, merge, encrypt existing PDFs	Supported	Supported
Text extraction	Not supported	ExtractAllText at word level
Digital signatures	Not supported natively	PdfSignature with X.509 and timestamps
Fillable AcroForms	Not supported	Supported
PDF/A and PDF/UA	Supported	Supported and validated
Release cadence	Four releases, June to July 2026	2026.7.2, shipped June 2026

Table 1. QuestPDF and IronPDF across the licensing and capability questions a .NET review tends to price.

Where the Document Has to Start as Code

QuestPDF was built for code-composed documents, so the first gap is HTML, in both directions. There is no HTML or CSS engine, so an existing web page, email template, or Razor view has to be re-implemented inside the container model by hand, field by field, rather than pointing a renderer at markup that already exists, which is the whole job a Chromium renderer is built to do.

Signing and form-filling close the set. Digital signatures and fillable AcroForms are not part of QuestPDF, so signing a generated PDF means handing it to a second library like BouncyCastle for the certificate work and interactive forms are not supported at all, an extra dependency and extra certificate-handling code to keep patched next to a built-in signing call. Text extraction sits in the same place, since the Document Operations API can load, merge, and encrypt an existing PDF as a whole document but has no facility for reading text back out of one, so QuestPDF stays a generation library rather than the reading layer a word-level extraction call provides.

What Happens If the Maintainer Steps Away?

QuestPDF has no CVEs of its own on record in the GitHub Advisory Database, NVD, or Snyk, the same clean read a maintained release line would give it. The read that matters for a long-run dependency is concentration, since QuestPDF is maintained by one developer operating as a sole proprietorship rather than a company with a bench of engineers, a single point of continuity for a library a production system depends on.

The release record runs the other way, with four releases in the two months before this was written and features like the ARM64 port and encryption support landing on a real schedule, so this is an active project rather than a stale one, the difference a team weighs against a vendor-backed line that carries a support channel behind it. The open feature requests for signing and AcroForm support have sat in the tracker for years apiece, so a team blocked on either should not plan around it landing on a predictable date.

Rendering HTML and Signing in One Package

The seam that sends QuestPDF teams looking is usually a signature on a document already generated, or an existing web page that has to become a PDF, with no second library bolted on for either. IronPDF renders the markup through Chromium and signs in the same package, in one call each.

using IronPdf;
using IronPdf.Signing;
using System.Security.Cryptography.X509Certificates;

// render existing HTML through the bundled Chromium engine
var renderer = new ChromePdfRenderer();
using var pdf = renderer.RenderHtmlAsPdf("<h1>Invoice #1042</h1><p>Total due: $250.00</p>");

// sign it in the same library, no BouncyCastle plumbing
var signature = new PdfSignature(new X509Certificate2("cert.pfx", "password"));
pdf.Sign(signature);
pdf.SaveAs("invoice.pdf");

The renderer is a full Chromium build, so an existing web page or Razor view becomes a PDF without its layout rebuilt by hand, and the signing, AcroForm, merge, and word-level-extraction work QuestPDF sends to second libraries all sits in this one package, which is where a Razor-to-PDF path and a merge call stay under a single license. Those are the gaps QuestPDF leaves to the team, and a project crossing the revenue line meets the license bill and the missing layers at the same moment, both resolved inside one deployment-priced dependency.

What Flips the Decision to IronPDF

A small team composing invoices from C# data, comfortably under the revenue line with no signing or HTML need, is the one case QuestPDF answers cleanly. Every other direction a review runs, once the company crosses $1M or goes public, the document starts as HTML, or a signature or readable text is needed, a single-package renderer with deployment-based pricing closes those gaps in one dependency rather than a revenue clock, a hand-ported layout, and a second signing library, which IronPDF's documentation lays out. So where does your project actually sit, comfortably under QuestPDF's revenue line, or already into one of the gaps above? Tell us in the comments.

QuestPDF belongs to its maintainer, and Iron Software is not affiliated with the project. Everything above comes from QuestPDF's own license pages, documentation, and release notes, alongside the public CVE record, accurate at the time of writing. Spot a figure that has changed since? Flag it in the comments.