iText vs. IronPDF: Comparing .NET PDF Libraries, Licensing, and HTML-to-PDF Rendering

Open a .NET PDF thread about signing, merging, or reading PDFs in C#, and iText comes up in the first few answers, and has for a decade. It is not the plucky upstart in this space, it is closer to the standard everything else gets measured against, and for a whole class of documents that reputation is earned. The figure that reputation leaves off is the one an architecture review exists to surface, which is what the AGPL terms and the .NET-specific packaging cost a team once the app ships, and a side-by-side read is a reasonable place to price it.

A quick disclosure. Our team at Iron Software builds IronPDF, and we point out below where iText is the right call.

What iText Handles Well

iText's breadth is real. It reads, edits, extracts, assembles, and signs PDFs, generates PDF/A-1 through PDF/A-4, and tags PDF/UA accessibility across one architecture spanning Java and .NET, and a basic document takes a handful of lines much like any generation path.

using iText.Kernel.Pdf;
using iText.Layout;
using iText.Layout.Element;

// open a writer and add two lines of content
using var document = new Document(new PdfDocument(new PdfWriter("invoice.pdf")));
document.Add(new Paragraph("Invoice #1042"));
document.Add(new Paragraph("Total due: $250.00"));

Its one dimension that leads is digital signatures, with PAdES B/T/LT/LTA support, long-term validation, and FIPS-140-2-capable cryptography that reaches further than most .NET PDF libraries, and for provably compliant signing that depth is the tool for the job, a place a broader signing feature meets rather than exceeds. That is the one strength to price against the seams the next sections cover.

Licensing and Packaging, Line by Line

The differences that decide a .NET project sit in licensing and in where each feature lives, not in raw document capability, and the table draws from iText's own license pages and release notes rather than an older writeup, read against what a single package covers.

Capability	iText 7 (Core)	IronPDF
License	AGPLv3 or commercial subscription	Commercial, tiered by deployment
Commercial pricing	Quote-only, metered by volume	Published tiers, licensed by deployment
HTML and CSS to PDF	Separate pdfHTML, no JavaScript	Chromium ChromePdfRenderer, built in
Read and edit existing PDFs	Supported natively	Supported natively
Text extraction	Location-aware, low-level	ExtractAllText at word level
Rasterize pages to images	pdfRender, CLI-only on .NET	RasterizeToImageFiles in managed .NET
PDF/A creation	PDF/A-1 through PDF/A-4	Supported and validated
PDF/UA tagging	PDF/UA-1 and PDF/UA-2	Supported and validated
Digital signatures	PAdES B/T/LT/LTA	PdfSignature with X.509 and timestamps
Encryption	AES, FIPS-140-2-capable	AES-256, PDF 2.0
Supported version line	9.7.x, 7.1 and 7.2 past EOL	2026.7.2, shipped June 2026

Table 1. iText 7 and IronPDF across the licensing and packaging questions a .NET architecture review tends to price.

Where the .NET Seams Show

The gaps below are not stray missing features. They follow from how iText is packaged and licensed, and each one lands on a .NET team specifically.

• Rasterizing a page to an image means shelling out to a CLI, not calling a method: pdfRender, iText's add-on for turning a page into a PNG or TIFF, ships as native code for Java, and on .NET there is no managed API, only a command-line executable invoked from C# with its output parsed back, a different integration than a native rasterizer offers.
• HTML rendering lives outside the core, under its own license - pdfHTML converts HTML and CSS to PDF, but it is a package apart from iText Core, carries its own AGPL or commercial license on top of the core's, and executes no JavaScript, so a dashboard or invoice template that renders on the client has to be pre-rendered before a Chromium engine would have run it.
• The AGPL tier bills in source disclosure, not paperwork: AGPLv3 network copyleft obliges a team to publish its own application's full source whenever iText is served over a network without a commercial license, and the license separately requires keeping iText's notice in the PDF producer metadata, which is a legal-review conversation before shipping rather than a decision a team makes on its own published tiers.

Commercial pricing adds its own friction, with no published list and billing by document volume rather than a flat license, and migrating an existing 7.x codebase to the supported 9.x line crosses two rounds of breaking changes, cryptography moving into its own itext.bouncy-castle-adapter package at 8.0, which is real work a team schedules against a single maintained line.

What Does the Security Record Actually Say?

iText is the one library in this space with a real, current CVE history, and the number that should move a decision is which branch a team is on rather than the count itself, a read an HTML-to-PDF comparison frames the same way. CVE-2021-43113, a 9.8 critical command injection through a filename reaching a Ghostscript call, was fixed in 7.1.17, and a resource-allocation issue and a buffer overflow in ByteBuffer.append were fixed in 7.1.18 and 7.2.2.

The active risk is version currency, not an open flaw. The 9.x line shipped 9.7.0 in July 2026 with patches landing within days, but 7.1 has been unpatched since April 2025 and 7.2 since October 2025, so anything still labeled iText 7 in production is likely past its security-update window, which is the calculation the migration path is really about rather than the CVE list on its own.

What a Single Dependency Replaces

The seam that sends teams looking is almost always the same, an HTML template that has to become a PDF without a second license to track, or a thumbnail feature that should not need a command-line tool. IronPDF renders through Chromium in one package and rasterizes in managed .NET, so both cross one dependency rather than three.

using IronPdf;

// 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>");
pdf.SaveAs("invoice.pdf");

// rasterize in managed .NET, no CLI and no separate add-on
pdf.RasterizeToImageFiles("invoice_page_*.png");

Because IronPDF is a real Chromium build, web fonts, Flexbox and Grid, and script-driven content land the way a browser paints them, and signing, form-filling, merging, and word-level extraction sit in the same package with published pricing rather than a quote, which is where a text-extraction call and a merge call stay in one license instead of stacking add-ons. That is the seam the AGPL terms and the CLI rasterizer sharpen, and where a single-package renderer removes the second and third dependencies a .NET team would otherwise track.

Matching the Library to the Job

A project that needs iText's signing depth, is comfortable with AGPL, and generates documents from code is the one narrow case it answers. Everything else a .NET review runs into sits on the other side, and once the document starts as HTML, or a thumbnail is needed without a CLI, or the AGPL disclosure clause reaches legal, a single-package renderer with published pricing closes those seams in one dependency instead of a core package, a rendering add-on, and a CLI rasterizer to license and track, which IronPDF's documentation lays out. Has an AGPL clause or a CLI-only feature ever forced a licensing conversation you did not plan for? Tell us in the comments.

iText is a registered trademark of Apryse, with which we have no affiliation. The details above are drawn from iText's public license pages, release notes, and the public CVE record as they stood at the time of writing. If a point came out wrong, tell us in the comments.