DEV Community: IronSoftware

QuestPDF vs IronPDF: The Revenue Line the License Now Draws

IronSoftware — Tue, 04 Aug 2026 20:25:51 +0000

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.

PaddleSharp vs IronOCR: The Native-Dependency Tree

IronSoftware — Tue, 04 Aug 2026 16:39:56 +0000

Search for PaddleOCR in C# and PaddleSharp is the first answer, the .NET binding that lets a team call Baidu's PaddleOCR models without leaving the language. The part those recommendations skip is what sits between dotnet add package Sdcb.PaddleOCR and a working OCR call, and it is not recognition accuracy, it is a native-dependency decision tree, operating system, CPU instruction set, and, for GPU work, an exact CUDA version. The question an architecture review should ask is who owns that package and runtime matrix in two years, which is where a side-by-side read starts to price the choice.

One disclosure up front. We are the team behind IronOCR at Iron Software, and this read maps where PaddleSharp holds up and where a .NET pipeline outgrows it.

The Hardware Reach Behind the Binding

Once the packages are in place, the call itself is compact, point at a model set, hand it an image, read the text back, the shape any project already managing native binaries would expect from a first OCR call.

using OpenCvSharp;
using Sdcb.PaddleOCR;
using Sdcb.PaddleOCR.Models.Local;

// build the pipeline with rotation handling in the same call
using PaddleOcrAll ocr = new(LocalFullModels.ChineseV5, PaddleDevice.Mkldnn())
{
    AllowRotateDetection = true,
    Enable180Classification = false
};

using Mat image = Cv2.ImRead("invoice.png");
PaddleOcrResult result = ocr.Run(image);
Console.WriteLine(result.Text);

Its one clear strength is hardware reach, since once the right package is selected PaddleSharp runs across Windows x64, Linux x64 and ARM64, and macOS on Intel and Apple Silicon, with CPU inference through MKL or OpenBLAS and optional GPU inference, a spread a broad language pipeline can draw on. That reach is the strength to weigh against the install matrix the next section walks through, the setup a single-package engine is built to remove.

The Native-Dependency Tree a Team Signs For

Behind that one call sits most of what adopting PaddleSharp actually commits a team to, and the first cost is a package decision tree with no default answer, run before any OCR call. Getting from dotnet add package to a working PaddleOcrAll means choosing a combination of operating system, CPU backend, and, for GPU work, a CUDA-version-matched package out of three separate lines, and the wrong pick surfaces as a DllNotFoundException at first run rather than the compile error a clean install path would raise.

GPU acceleration deepens that ownership rather than adding a package. PaddleSharp's own README says CUDA, cuDNN, and TensorRT have to be installed by hand, with PATH or LD_LIBRARY_PATH set on every machine that runs the app, version-matching infrastructure a team keeps in sync across dev, CI, and every production node for the life of the deployment, not the single reference a managed engine resolves at build time. The failures that hurt land at runtime, since a CPU without AVX needs the separate no-AVX package plus a code change and a missing Visual C++ Redistributable surfaces as a native-loader exception, both on a box nobody thought to check rather than in local testing where a self-contained package never raises the question. The quickstart also adds OpenCvSharp4 purely to decode the image before PaddleSharp sees it, and unless a project switches to the local models package the models download on first run, a non-issue on a workstation and a real one in a locked-down container that expects everything already in the image.

The Install Surface, Row by Row

The rows that decide a C# integration sit next to the rows that decide an engine benchmark, and the table draws from PaddleSharp's own README, NuGet listings, and repository rather than an older post, with release dates checked on NuGet and read against a single-package install.

Requirement	PaddleSharp	IronOCR
License	Apache License 2.0	Commercial, with support and updates
Packages to install	Core, inference, runtime, and models	One `IronOcr` package per OS
CPU instruction set	AVX assumed, no-AVX package separate	No instruction-set choice required
GPU acceleration	Matches one of three CUDA lines	No CUDA path required
Image decoding	Adds `OpenCvSharp4` to load images	Built in via `OcrInput.LoadImage`
Windows runtime	Visual C++ Redistributable required	No redistributable required
Model delivery	Downloads on first run, or bundled	Language packs as NuGet packages
Recent release	`Sdcb.PaddleOCR` 3.3.1, May 2026	`2026.7.2`, shipped June 2026

Table 1. PaddleSharp and IronOCR across the deployment requirements that stand between a package install and a first OCR call.

Whose Bandwidth Backs a Breaking Change?

PaddleSharp, and the Sdcb.PaddleOCR and Sdcb.PaddleInference packages it is built from, carry no CVEs of their own in the GitHub Advisory Database, NVD, or Snyk, the same read an OCR engine survey would give it. The exposure a review should read sits one layer down in PaddlePaddle, the Python training framework whose CVEs live in training and model-loading utilities the native inference path never touches, so attributing them to this binding misreads which layer they belong to.

The read that decides a long-run dependency is concentration. Of roughly 768 commits in the project's history, 752, better than 98%, come from a single contributor, with the next account at seven, so a production pipeline that leans on PaddleSharp leans on one person's bandwidth for a fast response to a breaking issue, the risk a team prices against a vendor-backed release line before it commits.

One Package, Whatever Server It Lands On

Teams tend to hit the deployment-matrix wall first, an OCR feature that has to run on whatever hardware a customer's server happens to have, without a small infrastructure project attached just to get text out of an image. IronOCR installs as one package and reads the same image in one call.

using IronOcr;

// no CPU-backend, CUDA, or redistributable matrix to pick from
var ocr = new IronTesseract();

using var input = new OcrInput();
input.LoadImage("invoice.png");

OcrResult result = ocr.Read(input);
Console.WriteLine(result.Text);

There is no CPU-backend choice, no CUDA line to match, and no separate decoder, since image loading is built into OcrInput and each language ships as its own NuGet package resolved at build time rather than downloaded on first run, which is what makes a locked-down container behave the same as a laptop. The native engine ships bundled inside each OS package, so the same read runs unchanged across a worker pool without the version-matching that shapes how the binding scales in a batch pipeline, and the package matrix PaddleSharp leaves to the team sits closed inside one dependency with published pricing.

Sizing the Binding to the Deployment

Owning the CUDA and native stack pays off in one narrow case, a team already on that tooling and after GPU throughput on models it has benchmarked. Everything else a .NET OCR feature usually is falls outside it, and for Latin-script or well-supported languages read reliably on whatever server it lands on, a single-package library removes the CPU-backend, CUDA, decoder, and redistributable decisions at once and reads an image or PDF in one call, which IronOCR's documentation lays out. So what is running your OCR in production right now, a hand-maintained native stack or a package that just installs? Tell us in the comments.

PaddleSharp and PaddleOCR belong to their respective owners, and Iron Software has no affiliation with either. The specifics above come from the project's own README, NuGet listings, and repository, together with the public CVE record, accurate as of writing. If something reads wrong now, correct us in the comments.

PDFsharp vs IronPDF: The Layer It Was Never Built to Add

IronSoftware — Mon, 03 Aug 2026 23:17:22 +0000

PDFsharp shows up in a lot of .NET codebases quietly, with no sales call and no license negotiation, just a NuGet install and a coordinate system for drawing onto a page. That is often exactly enough for a code-generated invoice, and it stays enough until a project needs something PDFsharp was never built for, an HTML email template turned into a PDF, readable paragraphs pulled back out of a report, or a PDF/A file that holds up for a compliance team. The question an architecture review should ask is who builds and maintains the layer PDFsharp leaves out, which is where a side-by-side read starts to price the choice.

A quick disclosure. Our team at Iron Software develops IronPDF, and we highlight where PDFsharp is better suited.

Where PDFsharp Stops

The constraint that ends most PDFsharp evaluations is rendering. PDFsharp can build a page from scratch, but it cannot open an existing PDF and render it, so there is no preview, no thumbnail, and no page-to-image export, and a document list that needs a thumbnail of page one or a QA step that needs an image diff between two versions requires a second library bolted on for that step alone, the step a native rasterizer covers in one call.

Text extraction stops at raw characters in the same way. PDFsharp hands back character positions in drawing order and nothing else, with no word, line, or paragraph reconstruction, so a project that needs readable text out of a PDF is writing that reconstruction logic itself rather than reaching for a word-level extraction call that returns the paragraphs already assembled.

The largest gap is HTML, in both directions. There is no HTML or CSS engine anywhere in PDFsharp, so an existing template, email design, or web page has to be hand-ported into XGraphics and MigraDoc calls line by line, and the maintainers have said outright they do not intend to build a PDF-to-Word or PDF-to-HTML converter, so the reverse is closed too, which is the whole job a Chromium renderer is built to do. Font coverage is narrower as well, limited to TrueType and OpenType-with-TrueType-outlines, and PDF/A creation shipped early with no way yet to target a specific conformance level, so a compliance requirement that needs a defined level today runs straight into that gap where a validated PDF/A path would meet it.

Drawing by Coordinate

Set against those gaps, PDFsharp keeps one strength. Its model is a blank page and a coordinate system, a different design point than a browser engine, and for a fixed-layout invoice that never touches HTML, that can mean less code than rendering a template, a pattern a code-first generation path recognizes.

using PdfSharp.Drawing;
using PdfSharp.Pdf;

// draw text at a fixed position on a blank page
var document = new PdfDocument();
var page = document.AddPage();
var gfx = XGraphics.FromPdfPage(page);
var font = new XFont("Verdana", 20);
gfx.DrawString("Invoice #1042", font, XBrushes.Black,
    new XRect(0, 0, page.Width, 50), XStringFormats.Center);

document.Save("invoice.pdf");

The MIT terms are the other point in its favor, unrestricted by empira with no seat or revenue threshold, which stands out next to source-available licenses that stop applying past a revenue line, and the project is not stagnant either, with 6.2.4 in January 2026 adding digital signatures, AES-256 encryption, and PDF/UA output on a real cadence that an actively released library can be weighed against.

The Capability and License Split

The differences that decide a .NET project sit in the layers PDFsharp does not ship, not in the drawing model it does, and the table draws from PDFsharp's own release notes and FAQ rather than an older post, read against what a single renderer covers.

Capability	PDFsharp	IronPDF
License	MIT	Commercial, with support and updates
Cost at scale	Engineering time for the missing layers	One license, those layers built in
HTML and CSS to PDF	Not supported	Chromium `ChromePdfRenderer`
Coordinate-based drawing	`XGraphics` canvas	Available, alongside HTML
Higher-level assembly	Through MigraDoc	Built in, plus HTML and CSS
Read and modify existing PDFs	Supported	Supported
Text extraction	Raw character positions	`ExtractAllText` at word level
Rasterize pages to images	No native support	`RasterizeToImageFiles`, built in
PDF/A creation	Early-stage, no level target	Supported and validated
PDF/UA tagging	Supported since `6.2.x`	Supported and validated
Digital signatures	Supported since `6.2.0`	`PdfSignature` with timestamps
Encryption	AES-256, PDF 2.0	AES-256, PDF 2.0
Release cadence	`6.2.4`, January 2026	`2026.7.2`, shipped June 2026

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

Reading the Maintenance Record

PDFsharp's security record is clean, with no CVEs of its own in the GitHub Advisory Database, NVD, or Snyk, and the one item a search surfaces is a NuGet restore warning for System.Formats.Asn1, which is CVE-2024-38095 in the .NET runtime's X.509 parsing rather than in PDFsharp's own code, resolved by bumping the dependency in a 6.2.0 preview, the same read a maintained release line would give it.

That pattern holds for the project. Each release corresponds to a commit on the master branch, 6.2.4 landed in January 2026 keeping pace with .NET 8, 9, and 10, and the open question for a review is scope, the rendering and extraction layers PDFsharp does not intend to add and a team therefore builds and carries itself against a single package that ships them.

Closing the Gaps in One Library

Teams tend to hit the same wall, an existing web page or Razor view that has to become a PDF without re-implementing the layout by hand. IronPDF renders that markup through Chromium in one call.

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");

Because the engine is a real Chromium build, HTML, CSS, and script-driven content come out the way a browser shows them, and PDF/A, word-level extraction, and page-to-image rasterization are built in rather than gaps to design around, which is where a Razor-to-PDF path and a rasterizer call stay inside one package. That is the layer PDFsharp leaves to the team, closed inside a single commercial package with published pricing rather than a set of second dependencies to bolt on and maintain.

Choosing by Where the Document Starts

A fixed-layout invoice that never touches HTML is the one case PDFsharp plus MigraDoc answers. Every other direction a review runs, once the document starts as HTML, or the project needs level-specific PDF/A, readable text back out, or a page rendered to an image, a Chromium-based renderer closes those gaps inside one package rather than turning each into a second dependency to bolt on and maintain, which IronPDF's documentation walks through. Which of PDFsharp's gaps hit your project first, the missing rasterizer, the raw-character extraction, or the absent HTML engine? Tell us in the comments.

PDFsharp is MIT-licensed by empira Software GmbH, and the PDFsharp name is the property of its owner, with which we have no affiliation. The details above are drawn from its public documentation, 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.

PaddleOCR vs IronOCR: The Python Runtime a .NET Team Owns

IronSoftware — Mon, 03 Aug 2026 23:09:37 +0000

The confusion most .NET teams hit with PaddleOCR is not the engine, it is what installing it turns into once C# has to reach it. PaddleOCR is a Python-first project, so adding the package becomes standing up a Python runtime, pulling model weights from a hub on first run, and carrying a stack of platform-specific computer-vision dependencies a .NET build server never expected to host. The question an architecture review should ask is who owns that runtime and model plumbing in two years, which is where a side-by-side read starts to price the choice.

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

What PaddleOCR Gets Right

PaddleOCR documents its accuracy with benchmarks PaddlePaddle publishes itself rather than numbers taken on faith, and its one clear strength is recognition on messy input, with PP-OCRv6 improving detection and recognition over the prior generation and scaling across tiny, small, and medium tiers so a team can trade accuracy against speed, the kind of result a demanding OCR pipeline is built around.

from paddleocr import PaddleOCR

ocr = PaddleOCR(lang="en")   # detection, recognition, orientation in one call
result = ocr.predict("invoice.png")
for res in result:
    res.print()

Language coverage runs to 50 languages in a unified PP-OCRv6 checkpoint and 109 in the newer PaddleOCR-VL pipeline, which reads mixed-script documents without swapping a language pack per file, a range wide language support also has to answer. That accuracy and coverage is the strength here, and what the Apache License asks of a .NET team in return is the runtime and model work the next section walks through.

Where the .NET Path Gets Expensive

The single-image demo hides most of what adopting PaddleOCR commits a .NET team to. The gaps below are not edge cases, they are the reason a proof of concept that ran in an afternoon becomes a subsystem someone maintains for years.

No first-party path into .NET- PaddleOCR's own release notes list official SDKs for Python, Go, and TypeScript, and C# is not among them, so a .NET team calling this engine directly is working through the underlying Paddle inference library or a community binding, not anything PaddlePaddle ships or supports, unlike a first-party C# API.
Model management becomes the team's job- nothing about the package arrives as a self-contained .NET artifact, models live on Hugging Face and ModelScope and resolve through Python tooling on first run, so a C# pipeline builds and maintains its own download, caching, and versioning step before a single image is processed, work a package with bundled models does not ask for.
Footprint depends on the pipeline- the classic detection-and-recognition pair is a few megabytes, but the newer PaddleOCR-VL pipeline is a 0.9-billion-parameter vision-language model needing on the order of 1 to 1.5 GB of weights and considerably more memory at inference, so two teams that both claim to run PaddleOCR can mean very different deployment footprints, a variance a fixed-footprint engine does not carry.

There is a version-to-version cost on top of that, because the long-standing ocr() method no longer accepts the det and rec parameters older tutorials rely on, replaced in the 3.x line by a predict() interface, so code written against a 2.x guide needs real rework. The dependency stack adds its own friction before any of that, since installing the package pulls in the PaddlePaddle inference engine plus OpenCV, shapely, scikit-image, and others, and needs Python 3.8 or newer, a meaningfully different install surface than the single reference a managed .NET library resolves at build time.

Integration and Deployment at a Glance

The rows that decide a C# integration sit next to the rows that decide an engine benchmark, and the table draws from PaddleOCR's own release notes and installation docs rather than an older post, read against a single-package install.

Capability	PaddleOCR	IronOCR
License	Apache License 2.0	Commercial, with support and updates
Language runtime	Python-native, Paddle or ONNX	Native .NET, one `IronOcr` package
First-party bindings	Python, Go, TypeScript SDKs	C# and .NET, shipped in `2026.7.2`
Model distribution	Downloaded from Hugging Face	Bundled inside the package
Multilingual OCR	50 to 109 languages	125+ languages in one package
Input types	Images, PDF via a separate step	Images and PDFs through `OcrInput`
Structured table extraction	The separate PaddleOCR-VL pipeline	Structured table and form output
On-premises inference	Supported	Supported
Release cadence	Four releases, April to June 2026	`2026.7.2`, shipped June 2026

Table 1. PaddleOCR and IronOCR across the integration questions a .NET review tends to price.

Does the Security Risk Sit One Layer Down?

The PaddleOCR toolkit itself has no advisories on record in GitHub's database, NVD, or Snyk, and the exposure a .NET team should read sits one layer down in PaddlePaddle, the deep-learning framework an install pulls in, which carries a real CVE history the same read an OCR engine survey would flag. It includes a critical command-injection flaw rated 9.6 (CVE-2023-52314), a 9.8 remote-code-execution issue in the 2.6.0 line (CVE-2024-0917), a code-injection flaw calling eval() on user input (CVE-2022-46742), and a path-traversal issue enabling arbitrary file overwrite (CVE-2024-0818).

Each of those sits in training-time, debugging, or data-conversion code, so a deployment that also trains or fine-tunes models on the same PaddlePaddle installation inherits that exposure directly, and the framework's own advisories are worth reading before a deployment decision, a review a bundled-engine path avoids because there is no framework underneath to audit against a maintained release line.

The Single-Package Path

For a .NET team, the practical question is not the engine's recognition quality but whether a Python toolchain, a separate model step, and a community binding are worth carrying to reach it from C#. IronOCR installs as one package and reads an image or PDF in one call.

using IronOcr;

// create the engine, no Python runtime anywhere in the build
var ocr = new IronTesseract();

// one input object takes both an image and a PDF
using var input = new OcrInput();
input.LoadImage("invoice.png");
input.LoadPdf("report.pdf");

OcrResult result = ocr.Read(input);
Console.WriteLine(result.Text);

IronOCR ships its models inside the package rather than as a separate download, exposes OCR through a plain C# API rather than a bridge into a Python process, and reads PDFs alongside images through the same OcrInput, so the whole category of runtime and model setup never comes up, which is where native PDF OCR and a built-in filter pipeline stay inside one dependency. That is the plumbing PaddleOCR leaves to the team, closed inside a single package with published pricing rather than a Python stack to assemble and maintain.

Which Stack Is Yours?

PaddleOCR answers one narrow case, a team already on Python tooling and willing to own the runtime and model management. For the pipeline that lives in .NET and mostly needs Latin-script or well-supported languages read reliably on whatever server it lands on, a single-package library removes the Python runtime, the model step, and the framework audit at once and reads an image or PDF in one call, which IronOCR's documentation lays out. So what is reading your documents in production right now, a Python stack you maintain or a package that just installs? Tell us in the comments.

PaddleOCR and PaddlePaddle are trademarks of Baidu, with which we have no affiliation. The details above are drawn from their public documentation and the public CVE record as they stood at the time of writing. If a point came out wrong, tell us in the comments.

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

IronSoftware — Mon, 03 Aug 2026 23:04:45 +0000

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.

wkhtmltopdf Is Archived: A .NET Migration Decision

IronSoftware — Sun, 02 Aug 2026 16:34:06 +0000

A dependency that stopped shipping releases in 2020 and had its repository archived in 2023 is still parsing HTML in a lot of .NET stacks. It usually shows up as wkhtmltopdf, or through DinkToPdf, the C# wrapper built around it, and we still meet it in migration reviews more often than you would expect. It was useful and simple in its day, which is why so much of it is still deployed. What changed is the calendar, not that early usefulness, and an archived wkhtmltopdf binary carrying open CVEs is a risk the person who owns the deployment now has to accept on purpose rather than inherit by default.

This is a decision-layer question more than a code question. A clean demo on a developer laptop is what keeps wkhtmltopdf in place, and it hides the one thing that matters, which is who patches the engine when the next HTML parser bug lands. For an archived project, the answer is nobody, and that gap does not show up until something in production depends on it being closed.

A quick disclosure. Our team at Iron Software builds IronPDF, and we point out below where the open-source alternatives are the better call.

What Actually Happened to the Project

The timeline sits in the project's own history, and none of it is in dispute. The last stable release was 0.12.6, back in June 2020. The last commit to the main branch landed in June 2022. In January 2023, the maintainer archived the repository himself. In July 2024, GitHub archived the entire wkhtmltopdf organization, all four repositories, read-only, including one named obsolete-downloads.

The maintainer's own status page does not soften it. The project runs on Qt 4, unsupported since 2015, on top of a WebKit engine frozen since 2012. That is the code parsing production HTML and CSS today, whether the team that shipped it knew that or not. The maintainer points anyone starting fresh at WeasyPrint or Prince for static documents, and Puppeteer where JavaScript rendering is needed. When the author of a tool is directing new users elsewhere, that is the clearest signal an architect gets about where the project is going.

The frozen wkhtmltopdf engine is a rendering problem as much as a security one. WebKit from 2012 predates most of the CSS a current template takes for granted, so grid layouts, flexbox behavior, and newer font handling drift or fail outright, and there is no wkhtmltopdf release coming to close the gap. Every rendering bug found from 2020 onward is permanent by definition. For a team maintaining document output over several years, that is a component whose behavior can only diverge further from the HTML the rest of the stack is written against, and the divergence is one-directional because only the frozen side has stopped moving.

The CVEs Still on the Record

Two vulnerabilities are logged against the binary, and neither has a fix on the way, because there is no longer anyone to ship one.

CVE-2020-21365- directory traversal, where crafted HTML can read local files under the default configuration in versions through 0.12.5, rated High at CVSS 7.5 in the GitHub Advisory Database.
CVE-2022-35583- server-side request forgery through an injected iframe pointed at internal addresses, present in 0.12.6, rated Critical at CVSS 9.8 in the GitHub Advisory Database.

Both are wkhtmltopdf-specific, and both stay open. The moment any part of the HTML being rendered originates from a user, a customer-supplied field on an invoice template, a print-this-ticket button, a comment embedded in a generated report, these stop being historical footnotes and become live attack surface on an engine that will never be patched again.

Where DinkToPdf Inherits the Same Risk

DinkToPdf, the most common .NET wrapper, does not reimplement HTML rendering. It marshals into the same wkhtmltopdf binary underneath and layers a C# API on top. Same engine, same frozen WebKit, same two CVEs, same warning from the maintainer about untrusted HTML. A project that references DinkToPdf carries everything above even if its own code never names wkhtmltopdf once, which is exactly what makes this easy to miss in a dependency audit.

There is a deployment cost hiding in that arrangement as well. The native wkhtmltopdf library has to be present and correct on every target, which means the archived binary gets baked into container images and build artifacts and then travels with the application for as long as it lives. An unmaintained native dependency is not a line in a lockfile that quietly resolves itself. It is a payload someone has to keep shipping on purpose, and each new deployment surface, a fresh base image or a different Linux distribution, is another place it has to be reconciled by hand.

It is worth being precise about the shape of the problem, because rendering untrusted HTML into a PDF is a category-wide attack surface rather than a single-tool defect. Feed almost any HTML-to-PDF renderer a reference to an internal address or a local file and the question is what comes back embedded in the output. The wkhtmltopdf binary is the renderer most exposed to it right now, because it is the one that stopped getting patched and cannot receive a fix. Whatever a team lands on next, the same question about untrusted input has to be asked of it.

Where IronPDF Fits

The migration target that removes the frozen-engine problem is a renderer that still ships. Here is the same task, rendering HTML to a PDF, on a Chromium engine instead.

using IronPdf;

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

// write the finished PDF to disk
pdf.SaveAs("invoice.pdf");

That writes invoice.pdf to disk through the same Chromium engine that ships in Chrome, and the engine is patched on Chromium's release cadence instead of sitting at 2012-era WebKit. IronPDF ships that engine inside a single IronPdf package that handles its own native binaries per platform, and it targets .NET 10 down through .NET Framework 4.6.2, so moving onto it rarely means touching the target framework first.

The choice comes down to who patches the engine, and the difference reads clearly side by side.

Concern	`wkhtmltopdf` and `DinkToPdf`	IronPDF
Rendering engine	Qt WebKit frozen since 2012, last release `0.12.6` in June 2020	Chromium through `ChromePdfRenderer`, `IronPdf` `2026.7.2` shipped June 2026
Maintenance status	Repository archived January 2023, GitHub organization archived July 2024, no patches	Actively released on one line, `2026.7.2` shipped June 2026
Untrusted HTML	`CVE-2020-21365` and `CVE-2022-35583` open with no fix coming	Chromium sandbox patched on Chromium's cadence, one `IronPdf` package on `2026.7.2`

There is an honest counterweight worth stating. When budget is the hard constraint and commercial support is not required, the maintainer's own suggestions, WeasyPrint for static documents and Puppeteer where JavaScript matters, are worth evaluating before landing on any paid renderer. The decision that needs making is not open-source versus paid. It is a frozen, unpatched engine versus one that still receives security fixes, and there is more than one supported way off the first.

What the Migration Actually Costs

The reason this decision gets deferred is that nothing is on fire today yet, and a working PDF path is easy to leave alone. The cost of leaving it alone stays invisible until an auditor flags the CVEs, or a customer sends HTML the frozen engine mishandles, or the one person who understood the DinkToPdf setup moves on and takes the tribal knowledge with them. Priced over a few years, an unmaintained renderer is technical debt that accrues quietly and then comes due all at once, usually on someone else's schedule.

The migration itself is bounded work rather than a rewrite. Both tools take an HTML string and hand back a PDF, so the surface that changes is the call site, not the document templates, which is where most of the real effort in any PDF pipeline lives. The templates carry over, the rendering call swaps, and the engine underneath moves from frozen to maintained. That is a small, testable change with a clear before and after, which is exactly the kind of migration worth doing while it is a planned line item rather than after an incident makes it urgent.

Wrapping Up

The short version for a review meeting looks like this.

wkhtmltopdf is archived, with its last release 0.12.6 in June 2020 and its GitHub organization archived in July 2024.
Two wkhtmltopdf-specific CVEs stay open with no patch coming, CVE-2020-21365 and CVE-2022-35583.
DinkToPdf wraps the same binary, so it inherits the same engine and the same CVEs.
Rendering untrusted HTML is a category-wide attack surface, and an unpatched engine is the worst place to meet it.
Moving to a Chromium renderer like IronPDF puts the render on a codebase that still ships patches, and open-source alternatives fit where budget is the constraint.

So what is keeping wkhtmltopdf or DinkToPdf in your stack right now, the migration effort, the license cost of a supported renderer, or the fact that nothing has visibly broken yet? That last one is the hardest to argue with a manager, and we are genuinely curious which of the three carries the most weight for your team.

If you want to map the API before committing to anything, the migration guide covers the move from wkhtmltopdf and DinkToPdf, and the status page and both advisories above are public if you would rather verify the risk for yourself first. Has an archived renderer with open CVEs already come up in one of your reviews, and did it change the plan or get waved through? Tell us how that went in the comments.

wkhtmltopdf, DinkToPdf, WeasyPrint, and Puppeteer are the property of their respective owners, and we have no affiliation with any of them. The dates and CVE details above are drawn from the projects' own archives and the GitHub Advisory Database, and if one has moved since, correct us in the responses.

Tesseract C# Wrapper vs IronOCR: The Deployment Cost

IronSoftware — Sat, 01 Aug 2026 06:21:58 +0000

Every OCR decision in a .NET shop reaches the same crossroads. There is an open-source engine everyone already knows, reached through a NuGet wrapper, and there is a managed .NET library that ships the engine in one package. On paper the open-source path wins before anyone opens an editor. Search for a Tesseract 5 C# wrapper and the recommendation comes back the same way every time, install the Tesseract package, point it at a folder of .traineddata files, and get offline OCR backed by an engine with nearly ten million downloads behind it. When our team weighs that against the engine documented in the IronOCR reference docs, the deciding factor is rarely the license line. It is what that wrapper quietly asks of your deployment for the next several years.

A quick disclosure. Our team at Iron Software builds IronOCR. We point out where the charlesw/tesseract wrapper is the right call.

What This Approach Does Well

The wrapper's own usage pattern is the place to start, because it states outright what the engine expects, an image, a language, and a couple of using blocks.

// load the engine, pointing at a folder of tessdata files
using (var engine = new TesseractEngine(@"./tessdata", "eng", EngineMode.Default))
{
    // load an image, run OCR, and read the text and confidence
    using (var img = Pix.LoadFromFile(@"./images/invoice.png"))
    {
        using (var page = engine.Process(img))
        {
            string text = page.GetText();
            float confidence = page.GetMeanConfidence();
            Console.WriteLine(text);
        }
    }
}

That is the whole shape of it. Load a trained-data set, load an image into Leptonica's Pix format, process it, and read the text and a confidence score back out. On a clean scan it prints the recognized block followed by a GetMeanConfidence value somewhere around 87 percent, and the design is deliberately low-level.

Two things here stand out. The license is Apache 2.0 across both the engine and the charlesw/tesseract wrapper, and the language coverage runs well past 100 scripts. The engine's own cadence backs that reputation up, with 5.5.3 shipping in July 2026 after 5.5.0 through 5.5.2 over the prior two years. For occasional OCR on clean images, with someone on the team keeping the native binaries current, the wrapper does the job for that narrow case. The cost it carries sits off the license line, in the native tesseract and leptonica binaries someone now owns for the life of the project. IronOCR removes that ownership by shipping the engine inside a single managed IronOcr NuGet package, which is where the rest of this comparison lives.

Capability and Maintenance Comparison

The table below sets the wrapper against IronOCR on the dimensions an architect prices before adoption, not on raw accuracy, which for both tools rests on the same underlying engine.

Capability	`charlesw/tesseract` NuGet wrapper	IronOCR
License	Apache 2.0	Commercial, with vendor support and a maintained release line
Engine version wrapped	`5.2.0`, per the wrapper's own README	Tesseract `5.x`, updated by Iron independent of the wrapper cycle
Last NuGet package release	November 2022	`IronOcr` `2026.7.2`, shipped June 2026
Native setup	Manual, VC++ runtime and platform-specific binaries	None, a pure managed NuGet install
Language packs	100+ languages, manual `.traineddata` downloads	125+ languages, bundled through NuGet
PDF input	Not supported directly, images only	Native through `OcrPdfInput`, including password-protected PDFs
Barcode reading	Not supported	Built in
Preprocessing (deskew, denoise, contrast)	Not built in	Built-in filter pipeline via `OcrInput`
Region-of-interest cropping	Broken since 2019 (Issue #489, still open)	Supported
Concurrent OCR calls	One `TesseractEngine` instance per thread	Single `IronTesseract` instance handles concurrent calls
Cross-platform deployment	Native binaries per OS, assembled by hand	Windows, Linux, macOS, and Docker from one `IronOcr` package

Table 1. Built from the wrapper's README, changelog, and GitHub issue tracker, with the gaps that still cost teams real time today.

Where This Approach Falls Short

The single-image demo hides most of what adopting this wrapper commits a team to. The three gaps below are not edge cases, they are the reason a proof of concept that ran in an afternoon turns into a subsystem somebody maintains for years.

The most-downloaded wrapper is frozen at Tesseract 5.2.0: The Tesseract package, the one almost every C# OCR tutorial points to, with 9.6 million total downloads, has not shipped a new version since November 2022. Its own README still describes itself as a .NET wrapper for tesseract-ocr 5.2.0. In the years since, the engine has released 5.3, 5.4, and now 5.5.3, each carrying real accuracy and bug-fix work. None of that reaches a project on this wrapper unless someone manually swaps the native tesseract and leptonica binaries and then confirms the P/Invoke signatures still line up, which the maintainers have not done in a shipped release for over three years. Price that accurately and it carries a real cost, it is a fork the team has silently agreed to own. The question an architect has to answer is who performs that binary swap in year two, who validates it, and what happens to the OCR path when the one developer who understood the P/Invoke layer moves on. That is bus factor and version drift landing on the same line item.

A scanned PDF never reaches the engine as a PDF: The wrapper's image loader, Pix.LoadFromFile, reads image formats through Leptonica and has no concept of a document. A pipeline that starts with a scanned invoice or an ID upload has to render every page to an image with a separate library before Tesseract ever sees it. That means a second native dependency, a second set of platform-specific binaries, and a second component that can break on a runtime the team did not test, all of it standing between the input the business hands you and the shape the engine will accept. Every one of those pieces is another thing to patch, another thing to certify on a new OS image, and another reason the deployment surface grows faster than the feature it supports.

Region-of-interest cropping has been broken since 2019: Issue #489 in the wrapper's own tracker, which reports that setting a region of interest does not work, was filed against the 4.1 release and is still open, still reproducible, and still listed as a known issue in the changelog for the current 5.0 wrapper release. A workflow that only needs one field from a scanned form, an account number or a line-item total, cannot lean on the engine's cropping API to isolate it. The image has to be cropped in a separate step before it reaches Tesseract, which is one more preprocessing stage the team writes, tests, and carries. A bug that has sat open across two major wrapper versions will not be fixed on your timeline, so any long-term plan has to design around it as a permanent shape of the tool.

Preprocessing is a layer the team builds and then maintains: Deskew, denoise, and contrast correction are not part of the wrapper, so a real document pipeline grows its own image-cleanup stage in front of the engine. On more than one project that glue has quietly grown into its own subsystem, with its own dependencies and its own failures, none of which shows up when the demo runs a pristine PNG. The accuracy the engine is famous for assumes an input that has already been cleaned, and on the open-source path the cleaning is code you own.

The native setup never appears in the demo either: Getting to that first snippet takes more than a NuGet reference. The native binaries need the Visual Studio 2019 runtime, System.Drawing interop needs a separate package on .NET Core, and every language beyond English is a manual .traineddata download that then has to stay in sync across developer machines, CI, and every server the code lands on. Each of those is fine on one workstation and a standing liability across an estate, because environment parity is now something the team enforces by hand rather than something the package guarantees. Over a three to five year horizon this is the part of the total cost of ownership that does not show on any invoice and shows up in every incident.

Security and Maintenance

The engine and the wrapper keep separate records, and conflating them leads to the wrong conclusion either way. The Tesseract engine itself has two CVEs on file, and both are effectively historical. CVE-2021-36081 is a use-after-free that affected only a 2020 alpha build, 5.0.0-alpha-20201231, not a stable release. CVE-2011-1136 dates to the 2.x line from over a decade ago. Both predate the 5.x branch teams actually ship today, and the engine has kept releasing on a regular cadence since, with 5.5.3 landing in July 2026.

The charlesw/tesseract .NET wrapper has no CVEs of its own on record in the GitHub Advisory Database, the NVD, or Snyk. The maintenance picture is about pace rather than safety. The repository is not archived and still takes the occasional documentation pull request, but its last tagged NuGet release was November 2022 and 231 issues sit open in its tracker. A more actively maintained binding does exist. TesseractOCR, maintained by Kees van Spelde, was forked from the same original codebase and currently tracks the engine's 5.5.x line at version 5.5.2, far more closely than the popular package has managed since 2022. A team set on staying open-source should evaluate that fork before defaulting to the stalled package everyone links to.

The security review that matters here is not a scan for a live bug on either record, because neither has one. It is the standing question of who applies the next advisory, whenever it lands, on a wrapper whose native binaries no one has shipped in over three years.

Where IronOCR Fits Instead

The teams that reach out to Iron Software tend to hit the PDF-input gap first, a document pipeline built around scanned invoices or ID uploads that does not want a second native library just to turn pages into images before OCR can begin. IronOCR reads the PDF directly.

using IronOcr;

// create the OCR engine
var ocrEngine = new IronTesseract();

// read a PDF directly, no rasterization step
using var pdfInput = new OcrPdfInput("scanned-invoice.pdf");
OcrResult result = ocrEngine.Read(pdfInput);

Console.WriteLine(result.Text);

That is a scanned PDF to extracted text in a handful of lines, with no rasterization step, no native binaries, and no manually managed tessdata folder. It prints the recognized document text straight to the console. Images load the same way through OcrInput, and OcrPdfInput exposes Deskew() and DeNoise() directly, so the preprocessing that was a hand-built layer on the open-source path is a method call here. A single IronTesseract instance also handles concurrent calls, without the one-engine-per-thread limit that shapes how the wrapper scales across a worker pool.

The architectural point is not the line count. It is that this snippet compiles and runs the same way inside a Docker container or on a Linux host as it does on a Windows desktop, from one IronOcr package resolved at build time, with no native runtime to install and no version to swap by hand. The deployment surface that the wrapper grows over years, native binaries, a rasterizer, a preprocessing stage, per-machine language files, collapses into one dependency the build system owns. IronOCR's cost is published up front, so it can be weighed against the upkeep it removes.

Wrapping Up

The Tesseract engine has earned its reputation. It is Apache 2.0 licensed, broad in language support, and still shipping real releases this month. What does not hold up is the assumption that the popular way to reach it from C# has kept pace. The Tesseract package most tutorials point to has been frozen at 5.2.0 since November 2022, PDF input was never part of its job, and a region-of-interest bug has sat open since 2019. For an occasional read of clean images, with someone owning the native binaries, that wrapper is still the right call, and it is worth recommending on those terms. For a team set on open source with real documents, the TesseractOCR fork is worth evaluating before the stalled package.

So here is the architecture question worth putting to the room. If your OCR code has to run three years from now as a headless service inside a Linux container, is the charlesw/tesseract wrapper still the cheap option once you count the native-binary upkeep and the version drift, or has that ownership quietly become the most expensive line in the build? We would genuinely like to hear how that math landed in your own projects, and whether you stayed on the popular package, moved to the fork, or priced out a commercial engine instead.

If the version lag, the native-binary maintenance, or the missing PDF input are the parts costing you time, which one would move you off the wrapper first? Run a scanned PDF through IronOCR, try the same document on the wrapper, and tell us in the comments where each one held up or fell over.

Tesseract is a trademark of its respective owners, and we have no affiliation with the project or its maintainers. The facts above are drawn from the wrapper's public README, changelog, and issue tracker, and from published CVE records. If a detail has moved since, correct us in the responses.

ClosedXML vs IronXL: The Hidden Cost of Open-Source .NET Excel Libraries

IronSoftware — Sat, 01 Aug 2026 05:20:33 +0000

n open-source library rarely arrives as a decision. Someone needs a spreadsheet report on a Friday, EPPlus licensing looks like a conversation nobody wants to have, the Open XML SDK reads like plumbing, and ClosedXML with its XLWorkbook API gets it done. Sixteen years after its first commit it is still one of the most-installed Excel libraries in .NET, and that is exactly why it is worth looking at the way we look at any dependency before it turns load-bearing, which is to ask what it commits a team to over the next two years rather than what it does in the first afternoon. This piece walks ClosedXML the way we would walk it in an architecture review, and where it helps we contrast how IronXL handles the same work.

A quick disclosure before we go further. Our team at Iron Software builds IronXL, and we will point out where ClosedXML is the better buy.

What This Library Does Well

ClosedXML wraps the Open XML SDK in an object model built from workbooks, worksheets, cells, and ranges instead of raw XML parts and relationship IDs. A small report is short.

using ClosedXML.Excel;

// create a workbook and add a worksheet
using var workbook = new XLWorkbook();
var worksheet = workbook.Worksheets.Add("Sales");

// set the header and data cells, plus a SUM formula
worksheet.Cell("A1").Value = "Product";
worksheet.Cell("B1").Value = "Revenue";
worksheet.Cell("A2").Value = "Widgets";
worksheet.Cell("B2").Value = 42500;
worksheet.Cell("B3").Value = "Total";
worksheet.Cell("C3").FormulaA1 = "=SUM(B2:B2)";

// save the file
workbook.SaveAs("sales-report.xlsx");

That writes a two-column sheet to sales-report.xlsx with no relationship IDs and no manual part management, only cells and values set directly.

That pattern is why it shows up in so many codebases. The license is MIT, and version 0.105.1 shipped July 25, 2026. ClosedXML calculates built-in Excel functions itself rather than shelling out to Excel. For an internal report that lives entirely in .xlsx and stays small, ClosedXML does that job, and on that narrow ground it is the better buy. What the core does not cover is the formats and the memory behavior most pipelines reach for next, which is where IronXL opens the file ClosedXML cannot.

Capability and Licensing Comparison

The differences that matter are easier to see side by side, so here is capability and licensing in one view.

Capability	ClosedXML	IronXL
License	MIT	Commercial, with vendor support and a maintained release line
Cost at scale	Engineering time to work around the in-memory model at volume	One license, predictable large-file handling
File formats	`.xlsx` and `.xlsm` only	`.xls`, `.xlsx`, `.xlsm`, `.csv`, `.tsv`, JSON, and XML from one API
Legacy `.xls` (binary) support	Not supported	Supported, `WorkBook.Load` opens binary `.xls` directly
Requires Excel or Interop installed	No	No, `IronXL` runs with no Excel installed
Cross-platform (Linux, Docker, Azure)	Yes	Yes, one build across Windows, Linux, macOS, and containers
Formula calculation	Supported	`WorkBook.EvaluateAll`, 150+ functions calculated in process
Large-workbook memory model	Full in-memory DOM, no built-in streaming reader	In-memory `WorkBook` model with predictable large-file handling
Public API stability	Pre-1.0, own docs say the API is still not stable	Versioned commercial release line, `2026.7.2`
Support channel	Community and GitHub issues	Commercial support included with `IronXL`
Release cadence	Active, `0.105.1` shipped July 2026	Active, `2026.7.2` shipped June 2026

Table 1. Capability and licensing, built from ClosedXML's README, docs site, and NuGet metadata against IronXL's published API.

Where This Library Falls Short

What follows is scope rather than defect, and scope is exactly what an architecture review is for, because the cost of an open-source library is rarely the license. It is the developer time spent building and maintaining what the library does not do, and the question of who owns that work two years from now when the person who chose it has moved to another team. Four gaps carry most of that cost.

No path to legacy .xls - ClosedXML reads and writes the Open XML formats only, .xlsx and .xlsm. A binary .xls file from an older ERP export, a decade-old template, or a partner feed that never left the legacy format will not open, and there is no fallback inside the library. The fix is a second dependency or a conversion step, and that glue is now something the team owns, tests, and carries through every upgrade. It is a small piece of code on the day it ships and a piece of tribal knowledge by the time someone new has to touch it. It also becomes part of the exit cost, because the day the team wants to change Excel libraries, the conversion shim is a second thing to unwind rather than one.
The whole workbook loads into memory at once - ClosedXML builds a full in-memory object model of the spreadsheet, with no streaming or SAX-style reader in the box. The project's own README publishes the numbers. Loading a million-row, ten-column text workbook takes roughly 800 MB of memory, and generating one from scratch runs close to 1.9 GB. A long-open GitHub issue, #86, tracks exactly this cost. On a memory-constrained container, or a batch job that processes several large exports at once, that is an out-of-memory risk to design around rather than a theoretical edge case. The architect version of the question is not how much memory one workbook needs, it is how many concurrent workbooks a container holds before it starts paging, because that number sets the throughput ceiling and it decides whether the answer to more volume is more replicas or a bigger box every month. Designing around it means either paying for that box or funding a rewrite that streams, and both are costs the MIT license never mentioned.
Sixteen years in, and still pre-1.0 - the first commit dates to May 2010 and the current release is 0.105.1. The documentation still tells you to read the release notes and the migration guide before every upgrade, because the public API, in its own words, is still not stable. For a team that does not want to re-test its formatting and formula code on every minor bump, that is a standing tax on maintenance, and it compounds. Multiply one careful upgrade a couple of times a year across a three-year horizon and the open-source library has quietly consumed a real slice of someone's calendar.
It is not thread-safe, and says so - ClosedXML is explicit that it is not thread-safe, and neither is the Open XML SDK underneath it. That is fine for one report at a time in a console app. It matters the moment the same code runs inside a web API or an Azure Function serving concurrent requests, where each request needs its own workbook instance and the team needs to know that rule before the first race condition shows up in production rather than after.

Each of these is survivable on its own. Added together they describe a library whose real price is paid in the code a team writes around it, and that price does not appear on any invoice. The way to make that price visible is to put a number on it. A conversion shim for one legacy format, a streaming path for the large workbooks, a documented per-request instancing rule for concurrency, and a re-test pass on every minor upgrade are not exotic asks, and none is more than a few days of work. Spread across a three-year horizon and a team that turns over even once, though, they add up to a quiet subsystem that someone has to understand well enough to change, and the person who understands it best is usually the one who has already left. That is the bus factor an architecture review is supposed to catch before it becomes a production incident, and it is the part of the total cost that a zero-dollar license line item hides most effectively.

Security and Maintenance

ClosedXML carries no CVEs of its own in the GitHub Advisory Database, NVD, or Snyk. What a security review has to weigh instead is the dependency surface, because a library inherits the advisories of everything it pulls in. ClosedXML's issue tracker shows the pattern. Issue #2491 references CVE-2024-43483 and CVE-2024-43484, the .NET runtime advisories covering a hash-flooding denial-of-service in System.IO.Packaging, System.Security.Cryptography.Cose, and Microsoft.Extensions.Caching.Memory. ClosedXML depends on System.IO.Packaging, so clearing that advisory meant waiting for a ClosedXML release that bumped the dependency. Issue #2099 shows the same shape earlier, flagging CVE-2018-8292 in System.Net.Http. The exposure is real while it is open, and the timeline for closing it runs on the maintainers' release cadence, not yours.

The maintenance picture is mixed. Releases do land, with 0.105.1 shipping July 25, 2026 and a push to the repository a day earlier. The issue tracker also sits at 468 open issues, a meaningful backlog for a community project with no dedicated support team behind it. Releases and a large open-issue count coexist, and both belong in the same review, because the question a security review answers is how fast a fix lands when a deadline is riding on it, not merely whether one exists, and behind a community backlog that timing is out of your hands.

Where IronXL Fits Instead

The teams that hit this in practice are the ones that meet the .xls wall, a legacy export ClosedXML will not open, or that need predictable memory on a large batch without redesigning around a full in-memory DOM. A library that covers the format range and calculates formulas in one pass is solving a different problem than ClosedXML was scoped for, and the code reads about the same.

using IronXL;

// Legacy .xls files that ClosedXML cannot open load the same way as .xlsx
WorkBook workBook = WorkBook.Load("quarterly-export.xls");
WorkSheet workSheet = workBook.DefaultWorkSheet;

// set a formula and calculate it in process, no Excel required
workSheet["C2"].Formula = "=SUM(B2:B50)";
workBook.EvaluateAll();

Console.WriteLine($"Quarterly total: {workSheet["C2"].FormattedCellValue}");

// save the result as xlsx
workBook.SaveAs("quarterly-export.xlsx");

That opens a binary .xls, sets a formula, calculates it in process with WorkBook.EvaluateAll, and writes the result out as .xlsx, printing something like Quarterly total: 48250 on the way.

The trade is straightforward. IronXL opens and writes the older binary .xls alongside .xlsx, .xlsm, .csv, .tsv, JSON, and XML from one API, so there is no second library bolted on for a single file type, and it calculates formulas built in through WorkBook.EvaluateAll on the same WorkBook and WorkSheet model rather than leaving that to Excel. Commercial support comes with it, which is a real difference when a formula edge case is the thing standing between a team and a release. IronXL is licensed per deployment against ClosedXML's MIT terms, and that is the line the decision turns on.

There is a deployment shape behind this too, and it is the part the architect cares about most. Where a spreadsheet job belongs, a synchronous request, a background worker, or a scheduled batch, is driven partly by how the library behaves under load, and a full in-memory model with no streaming pushes the large jobs off the request thread and into a worker pool whose size is capped by memory rather than CPU. Covering the awkward formats and the calculation in one dependency does not remove that constraint on its own, but it removes the second and third libraries that would otherwise each need their own instancing rule, their own upgrade cadence, and their own line in the exit plan. Fewer moving parts is not a slogan here, it is one less thing to keep aligned across a build matrix and one less place for a new hire to guess wrong.

For a small internal report generator that only ever touches .xlsx, ClosedXML does the job. When the pipeline has to ingest whatever format a partner sends, or needs a support line instead of a GitHub queue when production breaks at 2am, the broader-format library is the more direct fit.

Wrapping Up

ClosedXML in 2026 is MIT-licensed and still shipping, and that is what the repository shows rather than anything we are spinning. What has not moved in sixteen years is the shape of it. Open XML formats only, a full in-memory model with no streaming path, an API its own maintainers still call not stable, and a fix timeline that runs on a community backlog. Stay where you are if the pipeline lives entirely in .xlsx, the workbooks stay in the tens of thousands of rows, and one report at a time is all the concurrency you need, and if you are willing to bet the next three years that none of those three ever changes, because ClosedXML will not move to meet you when one of them does. Move to IronXL if you have to open a legacy .xls, if predictable memory on large files is a requirement rather than a hope, or if you need a support channel behind the library when a release is on the line. The longer format-by-format comparison walks the same ground in more depth.

So where does your project land right now, comfortably inside .xlsx and small-to-mid workbooks, or already fighting a legacy format or a memory ceiling in production?

If you are weighing the move, the quickest test is to run one of your own awkward files through IronXL and watch what it does. Which wall did you hit first, the format or the memory ceiling? Tell us in the comments.

ClosedXML is the property of its respective owners, and our team has no affiliation with the project. The facts above are drawn from its public README, documentation, and CVE records at the time of writing. If a detail has moved since, correct us in the responses.

C# PDF Libraries: Evaluating Syncfusion’s License Cliff and Azure Limitations

IronSoftware — Fri, 31 Jul 2026 01:23:39 +0000

When a team already ships Syncfusion grids, charts, and schedulers, adding its PDF library the moment a project needs invoices or reports feels like the safe call. One vendor, one license dashboard, one support contract. We have sat in enough architecture reviews to know that the safe call is exactly the one that deserves a second look, because the cost of a same-vendor default shows up months later in deployment and headcount, not on day one. This piece walks the Syncfusion PDF story the way we would walk it before signing off, and where it makes sense, we contrast it with how IronPDF handles the same work.

A quick note on our involvement is that our team at Iron Software works to develop IronPDF. We will highlight where Syncfusion is the better option as it clearly is in some areas.

The commitment nobody reads until later

Build-versus-buy is rarely the real question with a PDF library. The real question is what you commit to when you buy, and Syncfusion asks for three commitments that stay quiet during evaluation and get loud in production. The first is licensing. The second is a separate rendering package with its own native binaries. The third is a hosting environment where the primary rendering engine will not start. None of these are secrets. All of them are easy to miss when the demo runs clean on a developer laptop.

We want to set the frame before we get into the friction. The core Syncfusion PdfDocument API is solid engineering. Conformance, signatures, and encryption are genuinely deep, and the release cadence is fast. If your work is programmatic document assembly with a heavy compliance angle, Syncfusion is a serious tool and we will say so again later with specifics. The friction is narrow and it is real, and it lives in two places, HTML rendering from markup and the license as your team grows.

The Community License cliff

Syncfusion offers a free Community License, and it is genuinely free, which is why so many prototypes start on it. The catch is that eligibility is not a single threshold you clear once. It is four conditions that must all hold at the same time, and the moment any one of them breaks, the whole thing lapses.

Annual gross revenue under one million US dollars.
Five or fewer developers.
Ten or fewer total employees.
Three million US dollars or less in lifetime raised capital from outside sources.

Read those as an architect planning two years out rather than as a founder shipping this week. A startup that raises a modest seed round can cross the capital line without adding a single engineer. A team that hires its sixth developer trips the developer count while every other number stays comfortable. Cross any one line and you are buying paid seats, and you are doing it on the vendor's timeline rather than your own, usually right when the company is busy with the growth that broke the condition in the first place. The pricing is fine. The problem is that the trigger is coupled to hiring and fundraising, which are the two things a healthy company does on purpose, so the license risk is highest exactly when you can least afford a surprise procurement cycle.

This is not a knock on Syncfusion charging money. Everyone charges money, and IronPDF has no free tier at all, which we get to below. The architecture point is narrower. A free tier whose eligibility is tied to four moving business metrics is a dependency on your own growth, and that belongs in the risk column of the review, not the savings column.

HTML to PDF is a different package with its own binaries

Most teams that reach for a PDF library want to render HTML. It is the fastest way to turn an existing invoice template or a report layout into a document, because the design already exists as markup and CSS. Here is where the Syncfusion architecture asks for the second commitment.

HTML conversion is not in the core PDF package. It lives in a separate Syncfusion.HtmlToPdfConverter.* family, and that converter drives a browser engine, either a modern Blink engine or a legacy WebKit one. Blink needs native binaries, and those binaries are shipped per operating system as distinct packages.

Syncfusion.HtmlToPdfConverter.Net.Windows pulling BlinkBinaries for Windows.
BlinkBinariesLinux for Linux hosts.
BlinkBinariesMac for macOS.
BlinkBinariesAws for AWS Lambda style targets.

If you build on Windows and deploy to a Linux container, and plenty of shops now do exactly that, you have to get the right binary package onto the right target and keep it aligned across your build matrix. This is solvable. Teams solve it every day. But it is real configuration surface that has to be reviewed, documented, and maintained, and it is the kind of surface that passes CI on one machine and fails on the deployment host because the native payload for that platform was never referenced. The core PdfDocument work does not carry this weight. The HTML path does, and the HTML path is the one most product teams actually want.

Blink will not run on Azure App Service for Windows

This is the point that turns a configuration chore into a hosting decision, and it is the one we would flag hardest in a review.

Blink does not run on Azure App Service on Windows. The App Service sandbox restricts the GDI calls the Chromium engine needs, so the engine does not start in that environment. Syncfusion documents this, and the documented workaround is to move HTML rendering off App Service entirely, into a Linux Azure Function or a container, and call it over HTTP from your main application. Read that again as an architecture change rather than a config flag. You are introducing a second deployment unit, a network hop, its own scaling and failure characteristics, and its own monitoring, purely to render HTML to PDF. For a team that chose Azure App Service on Windows precisely because it is simple, that is a meaningful tax.

The escape hatch is the legacy WebKit engine, which sidesteps the Azure block, and it comes with its own bundle of problems that make it a hard sell in 2026.

WebKit does not execute JavaScript, so anything rendered by a client side framework or a charting script never appears.
It mishandles modern CSS3, so current layouts drift.
Its NuGet packages were pulled, so you are building on distribution that is no longer served.
Its bundled Qt binaries carry an unpatched CVE-2019-7317 in the zlib and libpng stack, which is the kind of finding a security review flags on sight.

Syncfusion's own guidance is to move from WebKit to Blink. So the two engines box you in. Blink is the recommended path but it is blocked on the exact Azure tier many .NET shops default to, and WebKit clears Azure but is deprecated, insecure, and cannot run JavaScript. Neither answer is clean for the common case of a Windows-hosted .NET app that needs HTML rendering.

For contrast, IronPDF ships a single Chromium engine inside the one package and handles its own binaries per platform without you selecting them by hand. On Azure the constraint is different in kind. The free, shared, and consumption tiers block the GDI+ calls, so you need Basic B1 or higher, which is a tier requirement rather than a platform block. There is no separate Linux Function to stand up and no HTTP hop to render a document. The Azure deployment notes spell out the tier, and if you are weighing a move the Syncfusion to IronPDF migration guide covers the API mapping.

Clearing up the CVEs, because misattribution is its own risk

If you search for Syncfusion CVEs you will find several, and it would be dishonest to let them sit unexplained, because none of them belong to the PDF component. We want to be precise here, since scaring a team off with a mislabeled vulnerability is as bad as hiding a real one.

The Syncfusion PDF component itself has no CVEs. The widely cited ones belong to other Syncfusion products. CVE-2024-55969 is in DocIO, the Word library. CVE-2024-55970 is in File Manager. CVE-2023-26563, CVE-2023-26564, and CVE-2023-26565 are in file provider components. Do not carry those into a PDF risk assessment, because they are not PDF findings. The one real PDF-adjacent security issue is CVE-2019-7317 in the legacy WebKit Qt bundle we described above, and that is a reason to avoid legacy WebKit specifically, not the core library.

Where Syncfusion is the stronger choice

We promised specifics, so here they are without hedging. Syncfusion's signature and encryption stack is deep, and if regulated document workflows are your center of gravity it may well be the better fit.

Signatures cover PAdES, CAdES, and CMS, with SHA-256 and SHA-512, PFX files, HSM support, OCSP and CRL revocation checking, and RFC 3161 timestamps.
Encryption spans RC4, AES-128 and AES-256, and PDF 2.0 AES-GCM 256.
The release cadence is fast, with quarterly volume releases plus weekly hotfix NuGet packages, and version 34.1.29 landed on July 14 2026.
Suite consolidation is real value. One vendor and one license dashboard across grids, charts, schedulers, and documents is a legitimate operational simplification.

That last point is the whole reason a same-vendor default is tempting, and it is not wrong. If your team already lives inside the Syncfusion suite and your PDF needs are programmatic assembly with heavy signing, staying put is a defensible architecture decision. IronPDF covers digital signing and PDF/A conformance too, so it is not a gap on our side, but we are not going to pretend a single library replaces a whole controls suite for a team that uses the whole suite.

The same job in code

The clearest way to see the split is the code for one small task, rendering an invoice. Syncfusion's core path builds the document programmatically, drawing text at coordinates.

// build a new PDF document and add a page
PdfDocument document = new PdfDocument();
PdfPage page = document.Pages.Add();
PdfGraphics graphics = page.Graphics;
// create a standard font at 20 point
PdfFont font = new PdfStandardFont(PdfFontFamily.Helvetica, 20);
// draw the text at a fixed point on the page
graphics.DrawString("Invoice #1042", font, PdfBrushes.Black, new PointF(0, 0));
// save and close the document
document.Save("invoice.pdf");
document.Close(true);

That is clean for fixed layouts. It becomes tedious the moment the invoice has a table, wrapping text, or a design that a non-developer owns, because every element becomes a coordinate you compute. The IronPDF path renders the markup you already have.

using IronPdf;
// create the Chromium based renderer
var renderer = new ChromePdfRenderer();
// render an HTML string straight to a PDF
using var pdf = renderer.RenderHtmlAsPdf("<h1>Invoice #1042</h1><p>Total due: $250.00</p>");
// write the file to disk
pdf.SaveAs("invoice.pdf");

Same output, different center of gravity. When the source of truth is HTML and CSS, rendering markup keeps the design where designers can touch it. When the source of truth is structured data and coordinates, the drawing API is fine. The architecture question is which one your document pipeline actually starts from.

The side-by-side

Here is the honest comparison in one view, wins and losses on both sides.

Concern	Syncfusion PDF	IronPDF
Free tier	Community License, but four conditions must all hold	No free tier, commercial and tiered by deployment
HTML rendering	Separate converter package, Blink or legacy WebKit	Chromium built into the one package
Native binaries	Per-OS Blink packages you select by hand	Handled per platform for you
Azure App Service on Windows	Blink blocked, needs a Linux Function or container over HTTP	Runs on Basic B1 or higher, a tier requirement not a block
Legacy engine risk	WebKit is deprecated, no JavaScript, carries CVE-2019-7317	Not applicable
Signatures and encryption	Very deep, PAdES CAdES CMS HSM OCSP CRL, AES-GCM 256	Solid coverage of signing and conformance
Suite consolidation	Strong, one vendor across many controls	PDF focused, not a controls suite
PDF component CVEs	None, cited CVEs belong to other products	None

For completeness, IronPDF also handles rasterizing pages to images, and its licensing is deployment tiered rather than headcount gated, which is the direct counterpoint to the Community License cliff.

How we would actually decide

Strip it down and the decision is not about which library draws a rectangle better. Both are competent. The decision is about the two commitments that survive past the demo. If your PDF work is programmatic assembly with serious signing, and your company is stable in size or already paying for the Syncfusion suite, its depth and consolidation are worth real money and we would not talk you out of it. If your documents start life as HTML, or you deploy to Azure App Service on Windows, or your headcount and funding are on a growth curve that will trip the Community License, then the separate converter package, the per-OS binaries, and the Blink block on Azure are recurring costs that a single-package Chromium engine avoids. Name the shape of your pipeline first, and the library mostly picks itself.

So here is the question we would put to your team in the review. Look at your next two years of hiring and funding, and at where you actually deploy. Does a free tier gated on four business metrics you plan to outgrow belong in the savings column, or in the risk column? Tell us in the comments how you would score that trade, because the answer changes a lot depending on your stage.

If you are weighing this right now, the migration guide is the fastest way to see the API mapping for yourself.

Syncfusion and its component suite are trademarks of Syncfusion, Inc. We are not affiliated with them, and the details above draw on Syncfusion's public license terms, documentation, and CVE records as they stood at the time of writing. If a figure or a date has moved since, correct us in the comments.

C# Excel Generation: The Real Cost of Using the Free Open XML SDK

IronSoftware — Fri, 31 Jul 2026 01:20:30 +0000

Every team that generates spreadsheets in .NET eventually runs the same evaluation. There is a free, Microsoft-backed option sitting right there, and there is a commercial one that costs money per deployment. On a spreadsheet of first-order costs, the free option wins before the meeting even starts. The problem is that the interesting costs are second-order, and they do not show up until you are three sprints into building a reporting service. This is a build-versus-buy story, and the fair version of it starts by admitting that Open XML SDK is genuinely excellent at the thing it was designed to do.

At Iron Software, we develop IronXL. We will point out cases where the Open XML SDK is more suitable, as it performs best for specific tasks.

What Open XML SDK Actually Is

DocumentFormat.OpenXml is a low-level schema API. It is shipped by Microsoft under the .NET Foundation, it is MIT-licensed, and the current release is 3.5.1 from March 2026 with more than 1,300 commits behind it. It tracks the OOXML schema that Office itself uses, which means the objects you work with are strongly typed and generated directly from the ECMA-376 and ISO/IEC 29500 standards. When the standard changes, the object model follows.

That design has real, concrete advantages, and we want to name them before we get anywhere near the gaps.

✅ The strongly typed object model means the compiler catches malformed structure. You are manipulating the same schema Word and Excel serialize, not a friendly approximation of it.
✅ There is a built-in OpenXmlValidator that checks byte-level structural fidelity, which is the kind of guarantee you want when a downstream system is strict about the format.
✅ The MIT license carries zero revenue, seat, or SaaS restrictions. You can ship it in a product sold to a million customers and owe nothing and ask no one.
✅ The Open Packaging Conventions give you random access to individual document parts. You can strip the comments out of a docx or move a single slide inside a deck without parsing the rest of the file.

If your work is document surgery, schema validation, or high-volume structural transformation where licensing risk at scale is the thing keeping you up at night, this is the correct tool and nothing we sell changes that. The README is honest about the contract. It expects you to bring detailed knowledge of the relevant formats and standards. It hands you the schema and, deliberately, nothing more.

The architecture question is what "nothing more" costs to build.

The First Gap Is the Expensive One. There Is No Calculation Engine.

This is the gap that surprises people, so it is worth being precise about the mechanics. In OOXML, a cell that contains a formula stores two separate things. CellFormula holds the formula text, something like SUM(B1:B10). CellValue holds a cached result, and that cached number was computed by Excel, not by the SDK. Open XML SDK reads and writes both fields faithfully. What it never does is calculate.

Play that forward. You build a workbook in a headless service, you write the formula text into every total cell, and you save the file. Because your service never computed a result, there is no cached value to write, so those cells are blank or stale on disk. They stay blank until a human opens the file in Excel and Excel recalculates on load. On a server that generates an invoice and emails it straight to a customer, no human ever opens it first. The customer receives a document where the total is empty.

The workaround people reach for is to compute every value in their own C# and write it into CellValue themselves, keeping the formula text alongside only for show. That works, but read what it actually is. You have written a spreadsheet calculation engine. You own SUM and AVERAGE and the operator precedence and the cell-reference resolution and the edge cases around blanks and text-in-numeric-cells, forever, in your application code. That is a large surface to build and a larger one to keep correct.

This is not an oversight that a patch is about to close. The request for a calculation feature has been open since 2018. A formal API proposal was still open in late 2025. This is a matter of roadmap scope rather than neglect, and the safe reading is that you should not architect around it landing. If your workload needs computed results, plan to supply that layer yourself or pick a library that already has one. For teams that live in formulas, our own guide to copying and working with formulas shows the behavior we mean when we say the result should exist the moment the file is written.

The Second Gap Is Legacy Formats. It Is OOXML or Nothing.

Open XML SDK reads and writes the modern XML-based formats and only those. There is no support for the old binary formats, no .xls, no .doc, no .ppt, in either direction. If your pipeline receives files from the outside world, this matters more than it looks.

Consider the common case. A partner or an internal legacy system uploads an .xls file, the binary format that was standard for years and still turns up constantly in finance, logistics, and government data. Hand that file to Open XML SDK and it cannot open it, because it is not OOXML. Your pipeline now needs a separate conversion step in front of the SDK, some other component that turns .xls into .xlsx before the SDK is allowed to see it. That is another dependency, another failure point, and another thing to test against the messy real-world files that never quite match the spec.

None of this is a bug. It is the scope Microsoft chose, and it is a reasonable scope for a tool named after the Open XML standard. It just means the format-conversion layer is, once again, yours to build or source. We wrote up the .xls to .xlsx conversion problem precisely because so many teams hit it the week after they commit to an OOXML-only stack.

The Third Gap Is Memory. The Default API Buffers Everything.

The friendly, discoverable way to use Open XML SDK is the DOM API, the one in every tutorial where you build up Row and Cell objects and append them to SheetData. It is readable and it is the approach the sample below uses. It also loads the entire document part into memory as an object tree.

On a normal report this is fine. On a workbook with hundreds of thousands of rows it is an OutOfMemoryException, and Microsoft's own position is that this is expected behavior for a DOM. A DOM materializes the whole tree by definition, so a big enough tree exhausts the heap. There is nothing broken here, only a boundary you have to know about before you cross it in production.

The supported fix is to drop from the DOM down to the SAX-style OpenXmlReader and OpenXmlWriter. These stream the document element by element and keep memory flat, and they work correctly. The cost is that the streaming API is materially more verbose and lower level than the DOM. Your clean object-building code becomes a state machine of read-element and write-element calls, and the thing you were trying to express gets buried under the mechanics of the stream. You end up maintaining two mental models, the pretty one for small files and the painful one for large files, and choosing between them per feature. When we handle large exports from a DataTable we want one path that does not fall over at scale, not a fork in the code.

What This Looks Like in Code

Here is the SDK writing a single labeled cell into a new workbook. It is verbose by design, and we have kept it that way rather than trim it, because the verbosity is the point. Every part of the package is something you name and wire up by hand.

using DocumentFormat.OpenXml;
using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Spreadsheet;

// Create the package and the workbook part
using var document = SpreadsheetDocument.Create("report.xlsx", SpreadsheetDocumentType.Workbook);
var workbookPart = document.AddWorkbookPart();
workbookPart.Workbook = new Workbook();

// Add a worksheet part and its sheet data container
var worksheetPart = workbookPart.AddNewPart<WorksheetPart>();
var sheetData = new SheetData();
worksheetPart.Worksheet = new Worksheet(sheetData);

// Register the sheet in the workbook's sheet list
var sheets = workbookPart.Workbook.AppendChild(new Sheets());
sheets.Append(new Sheet { Id = workbookPart.GetIdOfPart(worksheetPart), SheetId = 1, Name = "Report" });

// Build one row with one string cell
var row = new Row { RowIndex = 1 };
row.Append(new Cell { CellReference = "A1", DataType = CellValues.String, CellValue = new CellValue("Total Due") });
sheetData.Append(row);

workbookPart.Workbook.Save();

Now the same neighborhood of work in IronXL, including a formula that is actually computed and read back as a number before the file is ever saved.

using IronXL;

// Load an existing workbook, including legacy .xls if that is what arrives
WorkBook workBook = WorkBook.Load("invoice.xlsx");
WorkSheet workSheet = workBook.DefaultWorkSheet;

// Write a label, a value, and a formula
workSheet["A1"].Value = "Total Due";
workSheet["B1"].Value = 250.00m;
workSheet["B2"].Formula = "=SUM(B1:B1)";

// Calculate every formula in the book without Excel installed
workBook.EvaluateAll();
decimal total = workSheet["B2"].DecimalValue;

workBook.SaveAs("invoice-updated.xlsx");

The difference that matters is the one line EvaluateAll(). IronXL computes formulas itself with no Excel on the machine, so total is a real number the instant that call returns. WorkBook.Load opens .xls in the same breath as .xlsx, so the conversion step disappears. And the large-file memory management happens inside the library rather than in a streaming state machine you maintain. The reading walkthrough shows the same shape across more of the surface, and the full API documentation covers the rest.

The Comparison, Both Sides

Concern	Open XML SDK	IronXL
License	MIT, no seat or revenue limits at any scale	Commercial, tiered by deployment, no free tier
Formula calculation	None. You compute values and cache them yourself	Built in via `EvaluateAll()`, no Excel needed
Legacy .xls read and write	Not supported, OOXML only	Loads .xls alongside .xlsx
Large files	DOM buffers in memory, drop to SAX to stream	Managed internally on the default path
Schema and structural fidelity	Strongly typed, built-in validator	Higher-level model over the same formats
API level	Low level, expects format knowledge	Task-level, fewer moving parts
Backing	Microsoft, .NET Foundation, active	Iron Software, commercial support

A quick word on things that get miscounted against the SDK. It has no CVEs of its own. The CVE-2023-21538 that turns up in an issue thread is a denial-of-service in the .NET runtime's System.Private.DataContractSerialization, not in the SDK's code. And the discontinued "Microsoft Open XML File Format Converter", an old Mac Office tool, is a naming coincidence with no relationship to this library. The maintenance story is genuinely healthy and corporate-backed. The formula gap staying open since 2018 is a scope decision, not a sign of an abandoned project.

So What Should You Actually Pick

Reframe it as a total-cost-of-ownership question and the answer stops being universal. If you need schema-level control, structural validation, part-by-part surgery on documents, or zero licensing exposure across an unbounded number of installs, Open XML SDK is the stronger choice and the price is unbeatable. You are trading engineering time for license fees, and for that class of work the trade is sound.

The trade inverts when your service needs computed totals, ingests legacy binaries, or streams very large workbooks under memory pressure. There you are not choosing between free and paid. You are choosing between building and maintaining a calculation engine, a format-conversion layer, and a memory strategy, versus buying those three layers already built and tested. IronXL is commercial and there is no free tier, so it is a real budget line, and you can read exactly how the tiers work on the licensing page. The comparison worth making is that cost against the salaried months your own team would spend rebuilding the layers the SDK deliberately leaves out.

The mistake we watch teams make is pricing only the license and never the layer. When you have shipped one calculation engine of your own, which of the three gaps would cost your team the most to close, and did that surprise you when you first hit it in production? We would genuinely like to read your war stories in the comments.

If you are weighing this decision right now, try the two approaches on your own worst file, the ugliest legacy .xls with the deepest formulas you have, and tell us in the comments how each one held up.

Open XML SDK is maintained by Microsoft under the .NET Foundation, and the names referenced are the property of their owners. We are not affiliated with Microsoft, and the details above draw on the SDK's public documentation, repository, and issue tracker as they stood at the time of writing. If a version or a date has moved since, correct us in the comments.

C# OCR Comparison: Windows.Media.Ocr Limitations vs. IronOCR

IronSoftware — Fri, 31 Jul 2026 01:15:58 +0000

Every OCR decision on Windows eventually reaches the same fork. There is a free text recognition engine already built into the operating system, and there is a commercial library you can pull from NuGet. On paper, the free option wins before the discussion even starts. Windows.Media.Ocr ships inside Windows 10 and 11, costs nothing, and runs fully on the device. When our team weighs that against a paid engine documented in the IronOCR reference docs, the deciding factor is rarely the license fee. It is what the built-in engine quietly asks of your deployment in return.

A quick note on where we stand. Our team at Iron Software builds IronOCR, so we have a stake here. We will point out where Windows.Media.Ocr is the right call, because for one kind of app it clearly is.

What Windows.Media.Ocr gets right

Let us be fair before we get critical, because the engine has real strengths that explain why so many teams reach for it first.

✅ It is free and needs no NuGet reference of any kind.
✅ Every byte stays on the machine, which suits regulated or offline work where nothing may leave the box.
✅ It has been stable since the first Windows 10 release and still appears in the current SDK.
✅ The output is structured. You get OcrResult.Text plus a collection of lines and words, and each word carries a bounding box.
✅ The API describes itself through AvailableRecognizerLanguages and IsLanguageSupported, so you can probe capability at runtime instead of guessing.

For a certain kind of app, this really is enough, and we will name that app clearly before the end. The trouble starts when your deployment shape does not match the one narrow shape this engine assumes you have.

The MSIX trap that blocks services and console apps

Here is the constraint that catches most teams off guard. Windows.Media.Ocr.OcrEngine appears on Microsoft's own published list of WinRT APIs that require package identity. Put in practical terms, the calling process has to run with an MSIX package identity or the call fails outright.

Think about what that rules out. A plain console app has no package identity. A Windows service running under a system account has none. A traditional WPF or WinForms app shipped as a folder of files behind an installer has none either. None of those three can call the engine as written, and those three cover an enormous share of real production .NET software.

The only supported route is to wrap the whole application in an MSIX package for the sole purpose of satisfying this one API. That is a packaging model, a signing story, and an install channel adopted not because your app needs any of it, but because a single OCR call demands it. For a headless service that reads invoices on a schedule, repackaging as MSIX is a heavy architectural tax to pay for text recognition.

The request to relax this restriction has been raised with Microsoft and remains open and unresolved. Our advice is to plan around it holding rather than betting a release date on it lifting. If MSIX is not already how you ship, this one dependency reshapes your deployment before you have read a single character.

The silent null on a missing language pack

The second problem is quieter and, for that reason, more dangerous. When you ask for a language the engine cannot serve, TryCreateFromLanguage returns null. No exception is thrown, no message is written, and no reason is given. You get a null reference and nothing to explain it.

This matters because language packs are a separate per-device install, not part of the OCR component itself. On a developer workstation you may have added the pack by hand through Windows Settings months ago and forgotten it. On Windows Server the packs are absent by default and are pulled in with DISM /Add-Capability for Language.OCR, which often needs a Features on Demand source that a locked-down server does not have configured.

The failure mode writes itself. The engine works perfectly in development on your hand-tuned machine, sails through every test, then throws a null reference on the very first real document in production because the server was never given the pack. The code that broke did nothing wrong. The environment lacked a dependency the API refuses to describe out loud. If you go this route, our migration notes on Windows.Media.Ocr walk through exactly where these environment gaps bite.

The successor that only runs on an NPU

Now the strategic risk, which outweighs both of the above for anyone planning past the current release. Microsoft's Windows AI documentation frames the newer Windows App SDK text recognition API as the forward path for OCR on the platform, and it states that the new API runs exclusively on devices with an NPU.

Read that carefully. The replacement does not run on the large installed base of PCs that lack a neural processing unit. Copilot+ hardware is still a small slice of machines in the field, and the servers most of us deploy to have no NPU at all. So the modern successor cannot target the fleet you actually ship to, while the API you would adopt today is the one Microsoft is steering away from.

That leaves Windows.Media.Ocr in a difficult spot. It is the current engine, it works, and it is also the engine with a documented replacement that most hardware cannot run. Building new architecture on it in 2026 means committing to something in maintenance mode whose only sanctioned future needs silicon your users mostly do not own. For a codebase meant to live five years, that direction is the risk worth pricing in, well ahead of the license cost.

Images and documents are yours to prepare

Two more practical limits deserve a mention because they turn into code you have to write.

OcrEngine.MaxImageDimension caps how large an image the engine will accept, and there is no built-in resize or tiling. A high resolution scan above that ceiling has to be downscaled by your own code before the engine will look at it, and downscaling a dense document is exactly where recognition accuracy tends to slip.

Input is SoftwareBitmap only. The engine has no awareness of document formats, so a PDF page or a multi-page TIFF has to be decoded into that bitmap shape first, one frame at a time, before any text comes back. By contrast, IronOCR reads a scanned PDF directly, and its input handling and image filters for cleanup live inside the library rather than in glue code you maintain.

A fair word on security

We want to be careful and honest here rather than score a point. A search for CVEs tied specifically to the Windows.Media.Ocr namespace comes back clean. That is worth stating, and it is equally worth stating why. Windows vulnerabilities are catalogued against Windows and its broad components, not against individual WinRT namespaces, so a quiet search result reflects how the database is organized as much as any actual track record. We are not implying hidden risk, and we are not claiming proven safety. The real exposure with this engine is not a bug waiting to surface. It is platform direction, which we covered above.

The two code paths, side by side

The runtime story shows up in the code. Windows.Media.Ocr is asynchronous throughout and expects you to arrive already holding a SoftwareBitmap.

// Windows.Media.Ocr, async, and the input must already be a SoftwareBitmap
OcrEngine engine = OcrEngine.TryCreateFromUserProfileLanguages();
StorageFile file = await StorageFile.GetFileFromPathAsync(@"C:\scans\invoice.jpg");
using var stream = await file.OpenAsync(FileAccessMode.Read);
BitmapDecoder decoder = await BitmapDecoder.CreateAsync(stream);
SoftwareBitmap bitmap = await decoder.GetSoftwareBitmapAsync();
OcrResult result = await engine.RecognizeAsync(bitmap);
string text = result.Text;

The IronOCR path takes the file and returns the text, with no package identity and no bitmap decoding to arrange first.

// IronOCR, no MSIX, no SoftwareBitmap, runs unpackaged on every target
using IronOcr;
var ocr = new IronTesseract();
using var input = new OcrInput();
input.LoadImage("scanned-invoice.png");
OcrResult result = ocr.Read(input);
string text = result.Text;

The difference that matters is not line count. It is that the second snippet compiles and runs the same way inside a Docker container or on a Linux host as it does on a Windows desktop, with no packaging ceremony in between.

The comparison at a glance

Concern	Windows.Media.Ocr	IronOCR
Cost	Free, no NuGet	Commercial, tiered by deployment
Package identity	MSIX required for the API	None required
Console app or Windows service	Not supported unless repackaged	Runs directly
Language packs	Per-device OS install, null on miss	NuGet package resolved at build
Platforms	Windows only	Windows, Linux, macOS, Docker
Input formats	SoftwareBitmap only	Image, scanned PDF, multi-page TIFF
Large images	Manual downscale under MaxImageDimension	Handled inside the library
Forward path	Successor needs an NPU	Cross-platform, actively shipped

When Windows.Media.Ocr is the right call

We promised an honest trade-off, so here it is without hedging. If you are building an already-packaged, Windows-only WinUI or UWP app, and it reads languages that are already installed on the device, then Windows.Media.Ocr costs nothing, ships in the box, and is the correct choice. In that world the MSIX requirement is already met, the language pack is already present, and the single-OS limit is not a limit because you were never leaving Windows. Paying for a library there would buy you nothing.

Everything IronOCR adds is aimed at the world outside that box. Each language becomes its own NuGet dependency such as IronOcr.Languages.French or IronOcr.Languages.Japanese, resolved at build time rather than provisioned per machine, so the server that runs your code is guaranteed to have what the code asked for. That is a commercial product with tiered licensing, and it earns its cost precisely when your deployment is a service, a container, or anything other than a packaged Windows desktop app.

Where we land

The built-in engine is free, and for the packaged Windows-only app it is the right free. For a service, a container, or a cross-platform build, the price of the free engine is paid in MSIX packaging, per-device language provisioning, hand-written image preparation, and a bet on an API whose only documented successor needs an NPU most machines do not have. Those costs do not show on the license line, which is exactly why they are worth naming before you commit.

So we will put the real architecture question to you. If your OCR code has to run tomorrow as a headless service or inside a Linux container, does a zero-dollar engine that forces MSIX and single-OS deployment still read as free, or has the platform commitment quietly become the most expensive part? We would genuinely like to hear how that math worked out in your own builds.

If you are weighing this decision now, run a scanned PDF through IronOCR, try the same document on the built-in engine, and tell us in the comments where each one held up or fell over.

Windows, Windows.Media.Ocr, and the Windows App SDK are trademarks of Microsoft Corporation. We are not affiliated with Microsoft, and the details above draw on Microsoft's public API reference and documentation as they stood at the time of writing. If a detail has moved since, correct us in the comments.

List & Label vs a Single .NET Library

IronSoftware — Sun, 26 Jul 2026 15:53:05 +0000

List & Label is not one product a team licenses. It is a Designer, an optional report server, a Web Report Designer, and a stack of connectors, priced per developer per year. A team that needs little more than data in and a PDF out ends up renting the whole ecosystem to use one corner of it.

List & Label has been shipping since 1992, so plenty of the .NET teams running it today never actually chose it. They inherited it, along with a Designer surface nobody on the current team was hired to learn. The useful way to weigh it against a code-first library like IronPDF is not feature by feature. It is by what each choice puts into the deployment, what it bills every year to keep, and what it costs to walk away from once the author has moved on.

For transparency, our team at Iron Software develops IronPDF. We evaluate architecture and long-term costs, highlighting when List & Label might be the better option.

The smallest thing worth looking at first is how little it ships when IronPDF turns data into a document. There is no Designer to install and no project file to inherit, so a first report is one NuGet package and a handful of lines.

// dotnet add package IronPdf
using IronPdf;

License.LicenseKey = "YOUR-LICENSE-KEY"; // a 30-day trial key works here
var renderer = new ChromePdfRenderer();

PdfDocument notice = renderer.RenderHtmlAsPdf(
    "<h1>Renewal Notice</h1><p>The layout lives in HTML the team already reads, not a designer file one person owns.</p>");
notice.SaveAs("renewal-notice.pdf");

Nothing there is a .lst or .lsr file a new hire has to open in a separate application. ChromePdfRenderer hands the markup to an embedded Chromium build and returns a PDF, so the layout a team maintains as HTML is the layout that ships. Whether that reads as a lean deployment or a missing safety net depends on who authors the reports, which is what the rest of this turns on.

The Ecosystem You Deploy, and the Package You Deploy

The deployment surface is the part teams underestimate, because it stays invisible until an audit or a container rebuild forces someone to list it.

A List & Label deployment carries more than a rendering call. It carries the report definitions, the .lst and .lsr and .lld files that only combit tooling opens. It carries the Report Designer somewhere in the organisation, because a format nobody can edit is a liability rather than an asset. When reports show inside the app, it carries a viewer component across whichever targets a team supports, WinForms, WPF, or the browser-based Web Report Viewer. Each of those is a real capability, and each is one more thing to version, patch, and keep compatible across .NET upgrades for years.

An IronPDF deployment carries the library and a Chromium engine it manages for the team. The report definitions are HTML and CSS files that live in the same repository as the rest of the code, readable in any pull request and blamed in git like anything else. Turning an HTML file into a PDF on the server is the same call whether the markup is a string or a file on disk. The honest trade is that Chromium is memory-hungry by design, so the real capacity question is not whether a page renders correctly but how many concurrent renders a container takes before a team pays for a bigger box. List & Label's report engine is lighter per render. Neither answer is free, and the right one depends on throughput rather than a benchmark headline.

List & Label and IronPDF, Feature by Feature

Here is the head-to-head, kept accurate rather than flattering, with the rows that commit a team the longest sitting near the bottom. The row count leans toward List & Label on purpose, because a fair comparison names what the incumbent does that a library does not.

Dimension	List & Label (combit)	IronPDF
Authoring model	WYSIWYG Report Designer plus Web Report Designer	HTML, CSS, JavaScript, plus Razor
Report definition	`.lst` and `.lsr` binaries, combit tooling only	`.html` or `.cshtml`, plain text and diffable
Rendering engine	Proprietary report-band engine	Chromium, the engine behind Chrome
End-user self-service authoring	Yes, desktop and browser designers	No
Data-provider breadth	40 plus built-in providers, plus a custom interface	You bind data in your own code
Interactive viewer	Yes, Web Report Viewer and Ad-hoc Designer	No, generation only
Scheduling and distribution	Yes, combit Report Server	Your own job runner calls the renderer
PDF depth (merge, sign, PDF/A, PDF/UA)	Export-focused	Extensive
Deployment surface	Designer, optional Report Server, viewer components	Library plus a managed Chromium engine
Cross-platform (Linux, Docker, macOS)	Cross-platform edition, Enterprise only	Full, included in every tier
Licensing model	Per developer, per year (EUR)	Perpetual, per developer

Table 1. A capability comparison rather than a scoreboard, where List & Label leads on authoring, data breadth, and distribution while IronPDF leads on rendering fidelity, manipulation depth, and deployment simplicity.

Per-Developer, Per-Year, and the Three-Year Math

Cost is where the two models diverge most, and the shape of the bill matters more than any current figure, because figures move and the shape is what a team lives inside.

List & Label is sold per developer, per year, across three editions, priced in euros on the combit pricing pages. Standard lands around EUR 740 per developer for the first year and roughly half that on renewal, Professional near EUR 1,390 first year adds the bilingual designer and 2D barcodes, and Enterprise near EUR 1,990 first year adds cross-platform support, the Web Report Designer, and the Report Server. Every developer who touches the codebase needs a seat, so the tool bills for people who will never open the Designer on purpose, and volume discounts start at three or more developers.

IronPDF uses perpetual per-developer licensing instead, where a version is bought once and owned, with a full-function trial to evaluate first and no renewal required to keep the version bought. Because exact numbers age, the live tiers sit on the IronPDF licensing page rather than in a snapshot here. The trade cuts both ways. An annual subscription keeps a team on combit's newest Designer release automatically and never strands anyone on an unsupported version, and it also never stops charging, so a five-person team pays five seats every year whether or not the reporting changed. A perpetual license is a larger one-time commitment that then belongs to the team, and a version that ages unless a later purchase refreshes it. Where the crossover lands is a function of team stability, and a small, steady team that stopped changing its reports tends to come out ahead on perpetual across a three-to-five-year horizon.

When List & Label Is the Right Call

IronPDF does not win every scenario, and stating the cases where List & Label is the better buy matters more than winning the comparison, because a migration that fights the actual requirement costs more than the license it was meant to save.

✅ Non-developers design the reports. The desktop WYSIWYG Designer, shipping since the 1990s, hands layout to business analysts and customers through a code-free workflow, and a developer-written HTML template does not give that authorship back.
✅ A scheduled distribution server is a hard requirement. The combit Report Server schedules jobs and delivers output over email, FTP or SFTP, Amazon S3, OneDrive, Google Drive, Dropbox, or webhooks from a browser console, which a rendering library does not pretend to offer.
✅ You want a modern in-browser design surface. The Web Report Designer is a web-component designer that drops into React, Angular, or Vue front ends and redistributes to end users royalty-free.
✅ Deep, pre-built connectors save real work. More than forty providers cover SQL Server, PostgreSQL, MySQL, Oracle, DB2, and MongoDB, plus a custom IDataProvider for anything left over, and recent versions add an AI$() formula built on Microsoft's Semantic Kernel for translation or summarization inside the layout.

When two or more of those describe the project, staying on List & Label is the cheaper decision over any horizon, and the recurring subscription is buying something the team genuinely uses.

Porting a .lst Report to HTML

A large share of production reporting is not interactive at all. It is a scheduled job or an API endpoint turning data into a PDF nobody opens in a designer. When that is the real workload, the concept mapping off the proprietary format is small, and the mapping doubles as the exit cost of leaving it behind.

What leaves the deployment	List & Label	IronPDF
Report definition	`.lst` or `.lsr` binary	`.html` or `.cshtml` in source control
Load and render	`ll.Design.LoadFromFile(path)`	Build the HTML string or file directly
Export to PDF	`ll.Export(ExportTarget.Pdf, ...)`	`renderer.RenderHtmlAsPdf(html).SaveAs(path)`
Export to bytes	Export to a stream target	`RenderHtmlAsPdf(html).BinaryData`
Async rendering	Not the primary workflow	`await renderer.RenderHtmlAsPdfAsync(html)`
Page header and footer	Report bands	`RenderingOptions.TextHeader` or `HtmlHeader`
Page numbers	Field bound to page info	`{page}` and `{total-pages}` placeholders
Data binding	`IDataProvider` in the Designer	Your own template, Razor or loops

Table 2. What actually leaves the deployment on the way out of the proprietary format, direct where the models line up and candid where re-authoring is the real cost.

The first question a migrating team asks is whether footers and page numbers still work, so the sample below wires both in before anything else. The rows would come from EF Core, Dapper, or any data layer already in the app.

// CustomerStatement.cs (.NET 10)
using IronPdf;
using System.Text;

var lineItems = new[]
{
    new { Description = "Consulting, October",  Hours = 24, Rate = 185.00m },
    new { Description = "Consulting, November", Hours = 31, Rate = 185.00m },
    new { Description = "On-site workshop",     Hours = 8,  Rate = 225.00m },
};

// Build the report body as ordinary HTML and reuse existing site CSS if you like.
var body = new StringBuilder(
    "<h1>Customer Statement</h1>" +
    "<table><thead><tr><th>Description</th><th>Hours</th><th>Rate</th><th>Total</th></tr></thead><tbody>");

foreach (var item in lineItems)
    body.Append($"<tr><td>{item.Description}</td><td>{item.Hours}</td><td>{item.Rate:C}</td><td>{item.Hours * item.Rate:C}</td></tr>");

body.Append("</tbody></table>");

var renderer = new ChromePdfRenderer();

// A running footer with real page numbers, the report-band equivalent.
renderer.RenderingOptions.TextFooter = new TextHeaderFooter
{
    LeftText        = "Confidential, Contoso Consulting",
    RightText       = "Page {page} of {total-pages}",
    DrawDividerLine = true
};
renderer.RenderingOptions.MarginTop = 20;
renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;

PdfDocument statement = renderer.RenderHtmlAsPdf(body.ToString());
statement.SaveAs("customer-statement.pdf");

TextHeaderFooter supplies the running band, and the {page} and {total-pages} placeholders resolve per page at render time, so pagination is handled without extra work. Richer layouts swap TextFooter for an HtmlHeaderFooter and use full markup, and the headers and footers how-to goes deeper on both. When the original reports were already close to HTML in spirit, Razor views render straight to PDF with the same shape.

For a batch job, the rendering is async so a worker can stream a run of statements without blocking, and the loop owns nothing but code the team can read.

using IronPdf;

var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.TextFooter.RightText = "Page {page} of {total-pages}";

foreach (var account in await billing.GetActiveAccountsAsync())
{
    string html = StatementTemplate.Build(account); // Razor or plain string composition
    PdfDocument pdf = await renderer.RenderHtmlAsPdfAsync(html);
    pdf.SaveAs($"statement-{account.Number}.pdf");
}

For most tabular output, invoices, statements, audit summaries, translating a layout into HTML is a small task once the data is reachable in code. Reports with heavy grouping or Designer-built subreports carry more of that one-time cost, because those concepts have no one-line HTML equivalent and have to be rebuilt rather than mapped. Two pieces have no automatic equivalent either, end-user self-service authoring and scheduled distribution, so the plan is either a lightweight admin screen for report tweaks or a scheduler the team already runs. IronPDF is also a deeper PDF toolkit past rendering, with PDF/UA accessibility and PDF/A archival compliance for long-term storage. Recent releases also added signing over a hardware token and fine-grained compression, the kind of manipulation a reporting SDK's export pipeline rarely reaches for.

Platform or Package, and When Each Wins

After the deployment, the renewal, and the exit are all on the table, the decision usually resolves into one of three paths.

🚀 Stay with List & Label when non-developers design the reports, when a browser-based interactive viewer with an ad-hoc designer is part of the spec, when a scheduled Report Server delivering to email, FTP, or S3 is a hard requirement, or when one engine already spans Delphi, Java, and .NET. The subscription is buying something used.
💡 Move to IronPDF when reports are code-driven and HTML-based, when existing web templates can be reused, when the deployment targets Linux or containers, or when a perpetual license beats renewing seats that keep charging after the reports stopped changing.
⚠️ Run both, which is more common than teams expect. Some keep List & Label for interactive, business-authored reports and add IronPDF for high-volume, server-side jobs that never touch a designer.

The thread through all three is that the word reporting hides two different commitments, one where a person owns the layout in a design surface and one where code owns it as text, and the commitment a team actually has decides which one is cheaper to carry for years.

What does your production reporting look like once you strip away the demo, are the .lst files still opened and edited by a person each quarter, or have they quietly become a scheduled job writing PDFs that nobody views in a designer? Tell us in the comments, because that answer decides the whole thing.

If it is the second, we think a short prototype is worth running before the next renewal decides for you. Start a trial, point ChromePdfRenderer at one existing report template on current .NET 10, and see how close the first render lands, because that one experiment answers the ownership question better than any table here, including ours.

List & Label and combit are trademarks of combit GmbH. We have no affiliation with combit, and the details above rest on their public documentation. If we have a detail wrong, tell us in the comments and we will correct it.