DEV Community: IronSoftware

ZXing Decoder Online vs IronBarcode in .NET

IronSoftware — Tue, 30 Jun 2026 00:06:49 +0000

ZXing Decoder Online vs IronBarcode: When Do You Actually Need a .NET Library?

If you have a single QR code image on your desktop and you want to know what it says, the answer is almost never "write code." Open ZXing Decoder Online, upload the file, read the text. Done in ten seconds, nothing installed, nothing to license. So why does a .NET barcode library exist at all?

Full disclosure: we build IronBarcode at Iron Software, so we're not neutral. We'll be straight about when a free online decoder is all you need, and the honest answer is that it covers more cases than vendors like us tend to admit. The real split here isn't quality. It's use case: a manual web tool versus a programmatic library you embed in an app to read codes automatically, in bulk, from messy sources.

Here's what we found. The ZXing project gives you two distinct things that often get lumped together, and keeping them separate is half the battle. There's the website at zxing.org for checking a single image by hand, and there's the open-source ZXing library (and its .NET port, ZXing.NET) that you call from code. Both are free. Here's the ZXing.NET decode in C#:

using ZXing;
using ZXing.QrCode;

BarcodeReader barcodeReader = new BarcodeReader();
Result decodeResult = barcodeReader.Decode(sourceBitmap);
string decodedText = decodeResult.Text;

That's the whole pitch for the library side, and for a lot of projects it's genuinely enough.

The ZXing Decoder Online tool

The website is the part people reach for first, and rightly so. You visit zxing.org, choose a file or paste an image URL, submit, and it shows the decoded contents along with the format and raw bytes. It reads 1D and 2D formats, it's instant, and there is nothing to install or pay for.

✅ For manual, occasional work we'd point you straight at this tool, and we won't pretend otherwise. Debugging a single QR code a teammate sent you, checking what a printed label encodes, sanity-checking one image during development. Reaching for a NuGet package and a build step there would be more work, not less, and we've watched plenty of developers over-engineer exactly this.

The limits show up the moment the task stops being manual. The website can't run inside your application. You can't point it at a folder of 5,000 scans, hand it a 40-page PDF, or call it from a nightly job. It's a person clicking a button, one image at a time. That's a feature for its purpose, not a flaw, but it's also exactly where a library starts to matter.

The ZXing library in code

If you want decoding inside your own app, ZXing.NET is the free, open-source option, and it's a solid one. It's been around for years, has a large community, and ships under a permissive license. You generate and read codes directly:

using ZXing;
using ZXing.QrCode;
using System.Drawing;

BarcodeWriter barcodeWriter = new BarcodeWriter
{
    Format = BarcodeFormat.QR_CODE
};
Bitmap qrBitmap = barcodeWriter.Write("Hello, ZXing!");

The tradeoff here is what you assemble around it. ZXing.NET works on the bitmap you give it, so you handle image loading, rasterizing PDF pages yourself, and any cleanup when a scan is skewed, low-contrast, or noisy. On clean images it decodes reliably. On the imperfect inputs that real-world scanning produces, you tend to write preprocessing code before the bitmap ever reaches the decoder. For many teams that's an acceptable trade, especially when the budget is zero and the inputs are tidy.

Where IronBarcode fits

IronBarcode is a commercial .NET library. That's the honest headline difference from ZXing.NET, and we'll lead with it: it costs money where ZXing is free. So the question we'd ask is what you get for that, and whether it matches your problem.

Installation is one command, and the snippets below run in about five minutes:

Install-Package BarCode

Generating a code is one line, and reading one back is two:

using IronBarCode;

BarcodeWriter.CreateBarcode("Hello, IronBarcode!", BarcodeEncoding.QRCode).SaveAsPng("qrcode.png");

using IronBarCode;
using System;
using System.Linq;

var qrResult = BarcodeReader.Read("qrcode.png").First();
Console.WriteLine(qrResult.Value);

Notice there's no separate image-loading step and no format argument required. You point it at a file and read the value. What you're paying for is the layer around the decoder. IronBarcode reads barcodes directly from PDFs, multi-frame TIFFs, and common image formats, and it applies its own correction for rotation, low resolution, and noise so you don't hand-write that cleanup. It handles batch input across many files and supports the 1D and 2D formats you'd expect, including QR, Code 128, Code 39, EAN, UPC, PDF417, and Data Matrix.

That's the use case we see it built for: programmatic reading inside a .NET app, at volume, from sources that aren't pristine. We'd be the first to say it's not a replacement for the zxing.org website, and it's not trying to be a cheaper ZXing.NET. It's a paid alternative aimed squarely at the automated-pipeline problem.

How the three compare

Factor	ZXing Decoder Online	ZXing.NET	IronBarcode
Read / decode	✅ Manual, one image	✅ In code	✅ In code
Write / generate	❌ No	✅ Yes	✅ Yes
Symbologies	1D and 2D	1D and 2D	QR, Code 128, Code 39, EAN, UPC, PDF417, Data Matrix, more
Image preprocessing	None needed (human-driven)	Manual, you write it	Built-in rotation and noise correction
Read from PDF / batch	❌ No	Manual rasterization	✅ Direct, batched
.NET targets	N/A (web tool)	.NET Standard / Core / Framework (+ binding)	.NET Standard / Core 2.0+, Windows, Linux, macOS, Azure
License	Free, hosted	Apache 2.0, free, open source	Commercial, paid
Maintenance	Hosted by ZXing project	Community cadence	Commercial release cadence

So which should you use?

There's no single winner, and we'd distrust any comparison that pretended there was. It comes down to what you're actually doing:

✅ Reach for ZXing Decoder Online for one-off, manual decoding. It's free, instant, install-free, and the right call when a human is checking a single image.
✅ Reach for the ZXing.NET library when you need decoding in code, your inputs are reasonably clean, and you want a free, open-source dependency you can read and modify.
✅ Reach for IronBarcode when you're reading codes programmatically in .NET in high volume, from PDFs and imperfect scans, and a single-package install with built-in image correction is worth a license fee. The IronBarcode barcode reading tutorial shows the PDF and batch paths.

The cutoff that matters is manual versus automated. If a person is decoding one image, the website wins and nothing we sell changes that. If your application is reading many codes from unpredictable sources without anyone clicking a button, that's where a library, free or paid, starts to pull its weight.

The fairest test is your own data. Take a representative batch of the images you actually deal with, run them through ZXing.NET and IronBarcode, and compare what decodes and how much glue code each one needed.

Do you reach for an online decoder or a library when you need to read codes, and where's your cutoff? We'd like to hear where the line falls for you in the comments.

If your cutoff lands on the library side, you can test IronBarcode on your own files with the free trial.

ZXing is a trademark of its respective owner; this comparison reflects publicly available information at the time of writing.

Tesseract OCR in C#: Setup Pain and an Alternative

IronSoftware — Sat, 20 Jun 2026 01:46:53 +0000

Tesseract OCR in C#: Setup Pain and an Alternative

If you've tried wiring Tesseract into a .NET app, you already know the first hour rarely goes to actual OCR. It goes to native binaries, C++ runtimes, and figuring out why the build that worked on your machine breaks in CI. Tesseract is a genuinely good engine, but the path from "free download" to "running in production" is bumpier than most tutorials admit.

Quick disclosure: we work on IronOCR at Iron Software, so we have a horse in this race. We'll be straight about where vanilla Tesseract is the right call and where it turns into a maintenance tax. If this reads like a sales pitch, tell us in the comments and we'll tighten it up.

Here's the one-liner version of what we're comparing against, so you can see the shape of the API before we get into the weeds:

using IronOcr;
string text = new IronTesseract().Read(new OcrInput("image.png")).Text;
Console.WriteLine(text);

That runs on Windows, Linux, and macOS from the same NuGet package, with no native install step. The rest of this post walks through three places where that difference actually matters: setup, accuracy on messy scans, and cross-platform deployment.

Setup and installation

This is where most teams lose the most time, so we'll start here.

Raw Tesseract in C# means dealing with the C++ side of the engine. You're matching platform-specific binaries, making sure the Visual C++ runtime is present, and juggling 32-bit versus 64-bit compatibility. If you want a current Tesseract 5 build on Windows, you're often looking at cross-compiling with MinGW, which frequently doesn't produce a working binary on the first try. The free C# wrappers on GitHub help, but several of them lag behind the official Tesseract engine, so you can end up stuck on an older 3.x or 4.x build without meaning to.

IronOCR takes a different route: one managed package, installed the way you install anything else in .NET.

Install-Package IronOcr

No native DLLs to copy, no C++ runtime to chase down, no per-platform configuration. It targets .NET Framework 4.6.2+, .NET Standard 2.0+ (covering .NET 5 through 10), and .NET Core 2.0+, and the dependency resolution is handled by NuGet. The trade-off is honest: it's a commercial library rather than a free one. If your budget line is the only constraint and you have time to fight the toolchain, vanilla Tesseract is a reasonable choice. If your constraint is shipping date, the managed package usually wins back its cost in saved setup hours.

💡 You can pull IronOcr from NuGet and have the three-line example above running in a few minutes, with no native install step in the way.

Accuracy on real-world scans

Tesseract reads clean, high-resolution, well-aligned text really well. The problems show up the moment your input looks like something a human actually scanned: a slightly rotated page, a phone photo, a low-DPI fax, background speckle from a cheap scanner.

On those inputs, raw Tesseract output degrades quickly, and the usual fix is to build a preprocessing pipeline in front of it: deskew, denoise, threshold, often with a separate tool like ImageMagick. That's real work, and it tends to be different work for each document type you support.

IronOCR bundles common preprocessing filters into the input pipeline so you can apply them inline:

using IronOcr;

var ocr = new IronTesseract();
using var input = new OcrInput();
var pageIndices = new[] { 1, 2 };
input.LoadImageFrames(@"img\example.tiff", pageIndices);
input.DeNoise();  // removes digital speckle so it isn't read as characters
input.Deskew();   // corrects rotation before the engine tries to line-segment
OcrResult result = ocr.Read(input);
Console.WriteLine(result.Text);

DeNoise() strips scanning artifacts and Deskew() straightens rotated pages, the two corrections that most often rescue a bad scan. Iron Software claims 99.8 to 100% accuracy on typical business documents with this approach; that's their published figure, not a guarantee for your specific inputs, so benchmark it against your own worst-case pages before you commit.

The result object also carries per-word confidence scores and layout blocks, which is handy when you want to flag low-confidence fields for human review instead of trusting the whole page blindly. In our experience, that confidence data is what makes OCR safe to put into an automated workflow: you route the clean pages straight through and kick the doubtful ones to a person, rather than discovering a misread invoice total three steps downstream.

⚠️ One thing we'd push back on, gently: preprocessing is not magic, and neither library reads text that genuinely isn't there. If your source is a 72-DPI screenshot of a screenshot, no amount of DeNoise() will recover characters that were never captured. The honest framing is that good preprocessing widens the band of inputs that work; it doesn't remove the need for reasonable scan quality.

If you need a point of comparison for accuracy on hard inputs, Google Cloud Vision OCR is the usual cloud benchmark. Strong results, but it sends your documents off-machine and bills per request, which rules it out for offline or privacy-sensitive work.

Cross-platform deployment

This is the other place native dependencies bite, and it usually bites later, in a deploy pipeline rather than on your laptop.

With raw Tesseract, every target environment wants its own build. Docker needs a base image with the right libraries baked in. Azure deployments fail when the Visual C++ runtime isn't present. Linux behavior shifts between distributions depending on which packages are available. None of these are unsolvable, but each one is a separate thing to test and maintain.

Because IronOCR is managed code, the same package runs across the environments teams usually target:

Desktop: WPF, WinForms, Console
Web: ASP.NET Core, Blazor
Cloud and serverless: Azure Functions, AWS Lambda
Containers: Docker, Kubernetes
OS coverage: Windows, macOS (Intel and Apple Silicon), and common Linux distros including Alpine

The library handles the platform differences internally, so you're testing your code rather than your runtime's binary layout. That matters most in serverless setups, where you don't fully control the host: an AWS Lambda or Azure Functions cold start that can't find a native dependency is a frustrating thing to debug from a log stream, and avoiding native dependencies sidesteps the whole category of failure.

If you do stay on raw Tesseract for deployment, our advice is to pin everything: the engine version, the wrapper version, and the base image, and treat any one of them changing as a thing to retest. Most of the "it worked yesterday" reports we've seen with native OCR trace back to one of those three drifting underneath the app.

A quick note on languages

One more practical difference. Managing languages in raw Tesseract means downloading and placing the tessdata language files by hand (the full set is around 4GB) with the folder structure and environment paths set exactly right at runtime. IronOCR handles languages as NuGet packages instead:

using IronOcr;
// PM> Install-Package IronOcr.Languages.ChineseSimplified
var ocr = new IronTesseract();
ocr.Language = OcrLanguage.ChineseSimplified;
ocr.AddSecondaryLanguage(OcrLanguage.English);  // mixed-language pages read in one pass
using var input = new OcrInput();
input.LoadPdf("multi-language.pdf");
var result = ocr.Read(input);
result.SaveAsTextFile("results.txt");

You add a language pack the same way you add any dependency, and version compatibility comes along with it. If you want the full setup, the IronOCR documentation walks through the language packs and filter options in more detail.

Tesseract vs IronOCR at a glance

Same engine family underneath, different packaging and tooling around it. Read the rows against your own constraints rather than looking for an overall winner.

Factor	Vanilla Tesseract (C# wrapper)	IronOCR
Install	Native binaries, C++ runtime, per-platform setup	Single NuGet package
Engine version	Depends on wrapper; several lag behind upstream	Current Tesseract 5 build bundled
Preprocessing	Build your own, often with ImageMagick	DeNoise, Deskew, and filters built in
Languages	Manual tessdata files (~4GB full set)	NuGet language packs
Cross-platform	Separate build per OS / container	Same package on Windows, macOS, Linux, Alpine
License	Apache 2.0, free	Commercial, paid
Maintenance	You pin and retest engine + wrapper + image	Handled inside the package

So which one should you reach for?

Vanilla Tesseract earns its place on research projects, proofs of concept, and pipelines where you control the input quality and have time to tune the toolchain. It's free, the license is permissive, and the engine is solid. If cost is the hard constraint and setup time is cheap for you, it's the right call.

IronOCR makes more sense when you're shipping to production against real-world document quality, deploying across several platforms, or working to a deadline where setup time is a cost you can't absorb.

What's your experience been? If you've got a Tesseract setup that runs cleanly in Docker or CI, drop your approach in the comments; the configs people share for native OCR are usually more useful than any official doc. And if you've hit the cross-platform wall, tell us where it broke; we'd like to hear it.

If you want to test against your own documents first, IronOCR has a free trial.

Android OCR Libraries (and Where .NET Developers Fit In)

IronSoftware — Fri, 19 Jun 2026 00:17:40 +0000

Android OCR Libraries (and Where .NET Developers Fit In)

If you're adding text recognition to an Android app, you have a handful of OCR libraries to pick from, and they don't all solve the same problem. Some run on-device, some call a cloud API, and one of them is technically a .NET library that reaches Android through .NET MAUI. We'll walk through the main options, show some code, and be honest about the trade-offs.

Upfront: we work on IronOCR at Iron Software. It's a .NET library, not a native Android SDK. We'll be clear about where it fits (cross-platform code through .NET MAUI, which can target Android) versus the Android-native options below, so you can tell which tool matches your stack.

OCR libraries take an image, find the text inside it, and hand it back as a string you can search, store, or translate. On Android that powers document scanning, live translation, receipt capture, and form data entry. The libraries differ mostly in where the work happens (on the phone or in the cloud), how many languages they cover, and how much setup they ask of you.

The Android OCR options

Tesseract OCR

Tesseract is the open-source OCR engine most people start with. It supports over 100 languages and runs offline. The engine itself is C++, so on Android you reach it through a wrapper rather than calling it directly. For years that wrapper was tess-two, though it's no longer maintained. It's a solid choice when you want local processing and no per-request cost.

Google Mobile Vision API

The Mobile Vision API used to be the quick on-device option bundled with Google Play services. It's deprecated now and you should not start new projects with it. Google's replacement is ML Kit (covered below), which has the current text-recognition models and ongoing support.

Microsoft Azure Computer Vision

Azure's vision service does OCR in the cloud alongside image tagging, object detection, and other analysis. It handles many languages and reads tricky images well, but it needs a network connection and you pay per call. It's a good fit when your app is already online and you want accuracy without shipping models to the device.

ABBYY Mobile Web Capture

ABBYY's Mobile Web Capture is a JavaScript SDK aimed at document capture inside web-based flows, like onboarding screens. A user points the camera at a document and the SDK captures a clean image for processing. It's commercial and built more for capture-and-submit pipelines than for general in-app OCR.

ML Kit

ML Kit is Google's current on-device option and the migration path away from Mobile Vision. Text recognition runs locally, so it's fast and keeps image data on the phone. You get a clean API without needing to train or host models yourself. For most new Android-native apps that want offline OCR, this is the default we'd reach for first.

Tesseract4Android

Tesseract4Android is a fork of tess-two, rewritten to work with CMake and recent Android Studio versions. It wraps the Tesseract OCR engine with Java and JNI, so you get Tesseract's accuracy and language coverage with an interface that fits a modern Android project. Since tess-two is abandoned, this is the maintained way to run Tesseract on Android today.

It bundles Tesseract 5.3.4, Leptonica 1.83.1 for image processing, and libjpeg/libpng for image handling. Setup is two Gradle edits and then a few lines of code.

First, add the JitPack repository to your root build.gradle:

allprojects {
    repositories {
        ...
        maven { url 'https://jitpack.io' }
    }
}

Then add the dependency in your app module's build.gradle. Pick the standard or OpenMP variant depending on whether you want the extra threading:

dependencies {
    // Standard variant
    implementation 'cz.adaptech.tesseract4android:tesseract4android:4.7.0'
    // OpenMP variant
    implementation 'cz.adaptech.tesseract4android:tesseract4android-openmp:4.7.0'
}

With that in place, you talk to TessBaseAPI: point it at your language data and an image, then read the text back. Here's a small manager class that wraps the lifecycle:

import com.googlecode.tesseract.android.TessBaseAPI;
import android.graphics.Bitmap;

public class OCRManager {
    private TessBaseAPI tessBaseAPI;

    public OCRManager(String dataPath, String language) {
        tessBaseAPI = new TessBaseAPI();
        tessBaseAPI.init(dataPath, language);
    }

    public String recognizeText(Bitmap bitmap) {
        tessBaseAPI.setImage(bitmap);
        return tessBaseAPI.getUTF8Text();
    }

    public void onDestroy() {
        if (tessBaseAPI != null) {
            tessBaseAPI.end();
        }
    }
}

Where IronOCR fits for .NET teams

Everything above is for native Android development in Java or Kotlin. If your team writes C# instead, you're in a different lane. IronOCR is a .NET OCR library, not an Android SDK, so it won't drop into a Kotlin project. Where it can reach Android is through .NET MAUI: you write one C# codebase and MAUI builds it for Android (along with iOS, Windows, and macOS).

So the honest framing is this. If you're building a native Android app, one of the libraries above is the right call, and ML Kit or Tesseract4Android are the two we'd shortlist. If you're already a .NET shop and want OCR in cross-platform C# that happens to run on Android, IronOCR is worth a look. It reads text from images and scanned documents, supports many languages, and works across .NET targets including .NET Core, .NET Framework, and MAUI.

To add it to a .NET project, install the NuGet package:

Install-Package IronOcr

Then the API is a couple of lines. Point IronTesseract at an image and read the .Text off the result:

using IronOcr;

class Program
{
    static void Main(string[] args)
    {
        string imageText = new IronTesseract().Read(@"images\image.png").Text;
        Console.WriteLine("Recognized Text:");
        Console.WriteLine(imageText);
    }
}

The same call works whether you run it on a desktop service or inside a MAUI app targeting Android, since you're using the same C# across platforms.

Picking one

Here's the same set of options side by side, so you can match a tool to your constraints at a glance:

Library	Processing	Native Android?	Languages	Cost	Best for
ML Kit	On-device	Yes (Java/Kotlin)	~100+ (Latin, plus Chinese, Japanese, Korean, Devanagari models)	Free	Offline OCR in new native apps
Tesseract4Android	On-device	Yes (Java/JNI)	100+ via Tesseract traineddata	Free (Apache 2.0)	Tesseract's language coverage on native Android
Azure Computer Vision	Cloud	Yes (via REST)	160+	Pay per call	Online apps wanting accuracy without shipping models
ABBYY Mobile Web Capture	Cloud/SDK	No (JavaScript SDK)	Many (commercial)	Commercial license	Document capture inside web-based flows
IronOCR	On-device (.NET)	Via .NET MAUI only	125+	Commercial	OCR in cross-platform C# that also targets Android

There's no single best answer here, only the one that matches your codebase and where the work needs to happen:

Native Android, offline: ML Kit for the current Google path, or Tesseract4Android if you want Tesseract's language coverage.
Native Android, cloud-backed accuracy: Azure Computer Vision.
Capture inside web flows: ABBYY Mobile Web Capture.
C# / cross-platform via MAUI: IronOCR. There's a free trial if you want to test it against your own images before committing.

And skip Mobile Vision for anything new, since it's deprecated.

What are you building OCR into, and which way did you lean? If you've shipped one of these on Android, we'd like to hear how accuracy and setup held up in production. Drop a comment with your experience.

Android OCR Libraries: A Field Guide (and Where .NET Fits)

IronSoftware — Wed, 17 Jun 2026 17:23:23 +0000

Android OCR Libraries: A Field Guide (and Where .NET Fits)

If you need text out of an image on Android, the short version is this: for most apps, ML Kit or Tesseract4Android will get you there. I've spent a lot of the past few years helping teams pick OCR tooling, and the mistake I see most often is choosing a library before knowing whether the work runs on-device, in the cloud, or in a cross-platform .NET project that happens to ship to Android. This guide walks the real options, shows code early, and is upfront about which ones are native Android and which are not.

Full transparency: I'm a Developer Advocate at Iron Software. IronOCR is a .NET library, not a native Android SDK — I'll be clear about where it fits (cross-platform via .NET MAUI) versus the Android-native options below. So when I get to IronOCR, read it as the .NET path, not a drop-in replacement for a Java/Kotlin Android SDK.

Before we get into the options, here's the shape of native Android OCR so you know what we're comparing. With Tesseract4Android — the most common native path — it's essentially three calls:

TessBaseAPI tess = new TessBaseAPI();
tess.init(dataPath, "eng");        // point at your tessdata + language
tess.setImage(bitmap);             // hand it a Bitmap
String text = tess.getUTF8Text();  // read the recognized text back

Load a model, hand it an image, read the text. Almost every option below is a variation on those three lines — the libraries differ mostly in how much work they do around them.

What an Android OCR library actually does

OCR (Optical Character Recognition) reads pixels and gives you back characters. On Android, that usually means taking a photo or a scanned page, running it through a text-recognition engine, and getting editable, searchable strings out the other side. The practical uses are familiar: scanning documents, reading receipts, translating signs from a live camera feed, and pulling fields off ID cards.

The traits worth comparing across libraries are accuracy and language coverage, whether processing happens on-device or in the cloud, how hard the integration is, and how much you can tune preprocessing for messy real-world images. Those four points decide most choices, so I'll touch on them as I go.

A note on accuracy, because it trips people up: OCR quality depends as much on the input image as on the engine. A clean, high-contrast scan reads well in almost any library; a crumpled receipt shot at an angle in poor light will frustrate the best of them. Whatever you pick, budget time for preprocessing — deskewing, thresholding, and cropping to the text region usually move the needle more than swapping engines. The libraries below differ mostly in how much of that work they do for you versus how much they leave in your hands.

The other early decision is on-device versus cloud. On-device OCR keeps images on the phone, works offline, and has no per-request cost, but it's bounded by the device's CPU. Cloud OCR can lean on bigger models and often reads harder images, at the price of latency, a network dependency, and sending user images to a third party. For anything privacy-sensitive — IDs, medical forms, financial documents — that distinction often makes the choice for you before accuracy even enters the conversation.

To set the tone, here's the kind of code you'll actually write — this is Tesseract4Android, the most common native path for getting Tesseract running on Android:

import com.googlecode.tesseract.android.TessBaseAPI;
import android.graphics.Bitmap;

public class OCRManager {
    private TessBaseAPI tessBaseAPI;

    public OCRManager(String dataPath, String language) {
        tessBaseAPI = new TessBaseAPI();
        tessBaseAPI.init(dataPath, language);
    }

    public String recognizeText(Bitmap bitmap) {
        tessBaseAPI.setImage(bitmap);
        return tessBaseAPI.getUTF8Text();
    }

    public void onDestroy() {
        if (tessBaseAPI != null) {
            tessBaseAPI.end();
        }
    }
}

That's the whole shape of it: initialize with a data path and language, set a bitmap, read the text, clean up. Now let's look at the field.

The Android OCR options

1. Tesseract OCR

Tesseract is the long-running open-source OCR engine, with support for over 100 languages. It's the core that most other tools wrap. On Android you don't talk to it directly — you go through a wrapper such as the older tess-two or the maintained Tesseract4Android (more on that below). It runs offline, which is its biggest practical advantage for mobile, and it's free, which is the other. The cost shows up as setup: you manage language data files yourself and you'll do your own image cleanup, since Tesseract does little of that automatically.

2. Google Mobile Vision API

Part of Google Play services, Mobile Vision offered on-device text detection with a simple API. It's deprecated now — Google asks developers to migrate to ML Kit for current features, performance, and ongoing support. If you find a tutorial pointing you here, treat it as historical and use ML Kit instead.

3. Microsoft Azure Computer Vision

Azure AI Vision is a cloud OCR service with strong accuracy and broad language support, plus extras like object detection and image tagging. The trade-off is obvious: it needs an internet connection, and you're sending images to a server. That rules it out for offline or privacy-sensitive apps but suits backend-heavy workloads.

4. ABBYY Mobile Web Capture

ABBYY Mobile Web Capture is a JavaScript SDK aimed at capturing document images inside web-based flows — think customer onboarding where someone points their phone camera at an ID or form. It handles framing and image quality automatically. It's a commercial product, and it's a web SDK rather than a native Android library, so it fits a specific use case rather than general in-app OCR.

5. ML Kit

ML Kit, from Google, is the modern on-device path and the natural successor to Mobile Vision. Text recognition runs locally, which keeps it fast and keeps images off the network — good for both responsiveness and privacy. The API is approachable without machine-learning background, the base text-recognition model ships with the app, and it handles real-time camera input well, which is why I reach for it on translation and live-scan features. For most new native Android apps it's where I'd start, and only move to Tesseract4Android if I need a language ML Kit doesn't cover or want full control over the engine.

Tesseract4Android, in practice

Tesseract4Android is a rewrite of the old tess-two library, rebuilt to work with CMake and current Android Studio. It wraps the Tesseract OCR engine through Java/JNI, so you get Tesseract's accuracy and language support with an interface that fits a normal Android project. If you want offline Tesseract on Android and you want a maintained dependency, this is the one.

It bundles Tesseract OCR 5.x, Leptonica for image processing, and libjpeg/libpng for image handling — you don't wire those up yourself.

Getting it into a project takes two Gradle edits. First, add the JitPack repository to your root build.gradle:

allprojects {
    repositories {
        ...
        maven { url 'https://jitpack.io' }
    }
}

Then declare the dependency in your app module's build.gradle, picking the Standard or OpenMP variant depending on whether you want multi-threaded throughput:

dependencies {
    // Standard variant
    implementation 'cz.adaptech.tesseract4android:tesseract4android:4.7.0'
    // OpenMP variant
    implementation 'cz.adaptech.tesseract4android:tesseract4android-openmp:4.7.0'
}

From there you use TessBaseAPI exactly as shown in the snippet near the top: initialize with your language data, set the image, read the text. That's the full native Tesseract path on Android.

Where .NET fits: IronOCR

Here's where I'm careful, because it's easy to oversell. IronOCR is a .NET OCR library. It is not a native Android SDK, and I won't pretend you can drop it into a Kotlin project. What it does is run OCR inside the .NET ecosystem — and because .NET MAUI can target Android, a cross-platform C# app can ship OCR to Android (and iOS, Windows, and macOS) from one codebase.

So the decision is really about your stack. If you're writing native Java/Kotlin, use ML Kit or Tesseract4Android. If your team builds in C# and you're already shipping to Android through .NET MAUI, IronOCR lets you keep one language across platforms instead of maintaining a separate native OCR layer. That's the honest framing.

On the .NET side, IronOCR wraps Tesseract with handling for things like skew, low resolution, and multi-language documents, and it works across desktop, web, and cloud .NET projects. The reason I bring it up in an Android article is that "Android" increasingly includes cross-platform apps, and people writing C# deserve to know it's an option.

Installation is a single package. From the Package Manager Console:

Install-Package IronOcr

Then import the namespace and read an image. Here's the minimal version:

using IronOcr;
string text = new IronTesseract().Read(new OcrInput("image.png")).Text;
Console.WriteLine(text);

Three lines: construct the engine, read an image into an OcrInput, pull the .Text. In a .NET MAUI project the same call runs on the Android target, which is the whole point — you write the OCR logic once.

How I'd choose

Here's what I tell developers when they ask which one to pick:

Native Android, offline, open source: Tesseract4Android. It's maintained, it bundles its dependencies, and Tesseract's language coverage is hard to beat for free.
Native Android, modern and easy: ML Kit. On-device, privacy-friendly, low friction, and the path Google itself points you to from the deprecated Mobile Vision API.
Cloud, backend-heavy, accuracy first: Azure Computer Vision — as long as you're fine sending images over the network.
Web-based document capture: ABBYY Mobile Web Capture, for onboarding-style flows rather than general in-app OCR.
Cross-platform C# / .NET MAUI: IronOCR, so your Android, iOS, and desktop builds share one OCR codebase.

There's no single winner here — the right call depends on whether you're offline or online, native or cross-platform, and how much you care about keeping images on the device.

Closing

Android OCR isn't one decision; it's a couple of small ones. Pick on-device versus cloud first, then native versus cross-platform, and the shortlist narrows fast. For native apps, ML Kit and Tesseract4Android cover most of what teams need. For C# teams shipping through .NET MAUI, OCR can live in the same codebase as the rest of your app.

If that last case is you, IronOCR offers a free trial so you can read a few real images before committing — the three-line example above is genuinely the whole API surface for basic recognition. Either way, choose the library that matches your stack, not the one with the loudest feature list.

EasyOCR vs Tesseract vs IronOCR: A Practical OCR Comparison

IronSoftware — Tue, 16 Jun 2026 21:32:59 +0000

EasyOCR vs Tesseract vs IronOCR: A Practical OCR Comparison

Optical Character Recognition turns scanned pages, PDFs, and photographed text into data your code can search and process. It powers everything from book digitization and receipt scanning to form processing and accessibility tooling. Picking an engine, though, is less about which one is "best" and more about which one fits your stack and your inputs. We pulled together three of the common choices and tried each one on the same kind of work: EasyOCR and Tesseract on the Python side, and IronOCR on the .NET side.

Full disclosure: we build IronOCR at Iron Software, one of the three tools compared here. We've tried to keep this fair and call out where EasyOCR or Tesseract is the better fit, especially if you're already working in Python. Worth saying up front: two of these are Python libraries and one is a .NET library, so part of this decision is really an ecosystem choice rather than a pure feature contest.

Here's what we found.

EasyOCR

EasyOCR is an open-source Python library built on deep learning, and it supports over 80 languages with no extra setup, including Latin scripts, Chinese, Japanese, Korean, Arabic, and many more. Its big strength is recognition quality on messy inputs. When we ran it on noisy, low-resolution, skewed, or handwriting-adjacent text, its neural models tended to hold up better than older rule-based engines. It's free, and the API is about as simple as OCR gets: one reader object, one call, and you get back the text along with bounding boxes and a confidence score per detection. That confidence value is genuinely useful when you need to flag low-certainty reads for human review.

import easyocr

# Initialize the reader with the languages you need
reader = easyocr.Reader(['en'])

# Run OCR and get text + bounding boxes + confidence
result = reader.readtext('sample_image.png')

for (bbox, text, prob) in result:
    print(f"Detected: {text} (Confidence: {prob:.4f})")

That's the whole core loop. The tradeoff here is setup weight: EasyOCR runs on PyTorch, so your first install pulls in a sizable dependency chain, and it's noticeably faster with a GPU. On CPU-only modern hardware it still works, just slower on large batches. If you're already doing machine-learning work in Python, none of that will surprise you, and EasyOCR slots in cleanly. If you just want a quick text dump and don't otherwise touch PyTorch, the footprint can feel heavy for what you're getting.

Tesseract

Tesseract is the veteran of open-source OCR, and we'll happily give it that respect. Started at Hewlett-Packard, later picked up by Google, it's been refined for decades and supports more than 100 languages. You can train it on new fonts, and the community around it is enormous, which means plenty of answered questions when you hit a snag. In Python you reach it through the pytesseract wrapper.

import pytesseract
from PIL import Image

# Point pytesseract at your installed Tesseract binary if needed
# pytesseract.pytesseract.tesseract_cmd = r'<path_to_tesseract>'

image = Image.open('sample_image.png')
text = pytesseract.image_to_string(image)

print(text)

Where Tesseract shines is clean, machine-printed text: digitized books, receipts, multi-column documents, structured forms. It's fast, mature, and free. It handles layout analysis and can output searchable PDFs. We'd also call out the depth of its configuration options: you can pass page-segmentation modes and engine settings to fine-tune behavior for a given document type. The tradeoff is that it's more sensitive to input quality than EasyOCR. On noisy or distorted images you'll often need to bolt on OpenCV or PIL for preprocessing to get good results, and finding the right configuration takes some trial and error. For clean scans, though, it's hard to argue with a free engine that's been hardened over this many years.

IronOCR

IronOCR is the .NET OCR library we build, aimed at C# and other .NET languages. It wraps a tuned Tesseract engine and adds image preprocessing, multi-format input (JPEG, PNG, GIF, TIFF, and PDF), and direct searchable-PDF output. You install it from NuGet rather than pip.

using IronOcr;

var ocr = new IronTesseract();
ocr.Language = OcrLanguage.English;

// Load the image into an OcrInput, then read it
using var input = new OcrInput();
input.LoadImage(@"path\to\your\image.png");
OcrResult result = ocr.Read(input);

Console.WriteLine(result.Text);

For a .NET team, the appeal is staying in one runtime. You're not standing up a Python service or shelling out to an external process just to read text from an image. The preprocessing (noise reduction, contrast, deskew, resizing) is built in, so you often skip the OpenCV step that Tesseract would otherwise need. Searchable-PDF conversion is built in, it accepts JPEG, PNG, GIF, TIFF, and PDF input, and it handles batch processing for larger volumes. Being commercial, it also comes with support and regular updates rather than community-only help.

The honest tradeoff: IronOCR isn't free, and if you're already in Python, adopting it means crossing an ecosystem boundary you probably don't want to cross. Its value is specifically for .NET shops that want native integration and on-prem processing without gluing a Python toolchain into their build.

How they compare

	EasyOCR	Tesseract	IronOCR
Ecosystem	Python	Python (pytesseract)	.NET / C#
Cost	Free	Free	Commercial
Languages	80+	100+	100+
Best at	Noisy / handwritten-ish text	Clean printed text	Native .NET + searchable PDF
Preprocessing	Basic	External (OpenCV/PIL)	Built in
Searchable PDF	No	Yes	Yes

So which one?

We don't think there's a single winner here, and the choice mostly tracks your context. If you're in Python and your inputs are noisy or varied, EasyOCR's deep-learning recognition is hard to beat for the price (free). If you're in Python and working mostly with clean printed documents, Tesseract is fast, battle-tested, and backed by a huge community. We'd reach for either one happily, and for most Python projects they're the right default.

IronOCR earns its place when you're building on .NET and want OCR that feels native to the platform, with preprocessing and searchable-PDF export handled for you and commercial support behind it. That convenience is the thing you're paying for, and whether it's worth it depends on your team and your stack. If that's your situation, IronOCR offers a free trial so you can test it on your own documents before committing.

What are you running OCR on, and which engine has held up best for your inputs? We'd like to hear what's worked (and what hasn't) in the comments.

QuestPDF C# Tutorial: Generate PDFs in .NET (2026)

IronSoftware — Fri, 12 Jun 2026 19:48:44 +0000

QuestPDF is a code-first PDF library for .NET: you describe a document with a fluent C# API and it renders a PDF, with no HTML pipeline and no headless browser. This guide goes from install to a real, data-driven report, covers the layout model the whole API is built on, and is honest about where QuestPDF stops. Everything targets QuestPDF 2026.5.0 and runs on current .NET (it ships for net6.0 and netstandard2.0, so it runs on .NET 8 and .NET 10).

How do I install and license QuestPDF?

One NuGet package, no native dependencies to provision:

dotnet add package QuestPDF

Then set the license tier once at startup, before any document is generated. Community is free for individuals and for companies under $1M USD annual gross revenue:

using QuestPDF.Infrastructure;

QuestPDF.Settings.License = LicenseType.Community;

The quick-start guide is the canonical reference if you want the official walkthrough alongside this one.

Write your first PDF end to end

A complete, runnable program. Note the shape: a document holds a page, and the page has a header, content, and footer, each a chained call.

using QuestPDF.Fluent;
using QuestPDF.Helpers;
using QuestPDF.Infrastructure;

QuestPDF.Settings.License = LicenseType.Community;

Document.Create(container =>
{
    container.Page(page =>
    {
        page.Size(PageSizes.A4);
        page.Margin(2, Unit.Centimetre);
        page.DefaultTextStyle(x => x.FontSize(12));

        page.Header().Text("Monthly Report").FontSize(20).Bold();

        page.Content().PaddingVertical(15).Column(column =>
        {
            column.Spacing(8);
            column.Item().Text("Generated from C#, no HTML involved.");
            column.Item().Text($"Date: {DateTime.UtcNow:yyyy-MM-dd}");
        });

        page.Footer().AlignCenter().Text(text =>
        {
            text.Span("Page ");
            text.CurrentPageNumber();
            text.Span(" of ");
            text.TotalPages();
        });
    });
})
.GeneratePdf("report.pdf");

This writes report.pdf to disk. The output paginates automatically and the footer page numbers update across pages.

How the container model works

Everything in QuestPDF is a container you configure by chaining methods, and containers nest. page.Content() returns a container; calling .Padding(10).Background(Colors.Grey.Lighten4) wraps it, and .Column(...) fills it with child containers. Once that clicks, the entire API reads the same way: configure a container, then place children inside it. That single idea is what the API reference is built around.

Composing layout with Column, Row, and Text

Three primitives cover most documents:

Column stacks items vertically, with Spacing between them.
Row places items horizontally; size them with RelativeItem (proportional) and ConstantItem(points) (fixed).
Text renders styled runs, including dynamic spans like page numbers.

page.Content().Column(column =>
{
    column.Spacing(10);

    column.Item().Row(row =>
    {
        row.RelativeItem().Text("Invoice #1042").Bold();
        row.ConstantItem(140).AlignRight().Text("2026-06-04");
    });

    column.Item().Text("Thank you for your business.");
});

This produces a two-column header row with the label left-aligned and the date right-aligned, followed by a full-width text line. For tables specifically (line items, statements), QuestPDF has a dedicated table API worth its own read.

Reusing layout with components

For layout you repeat across documents (a letterhead, a signature block), QuestPDF supports components: a class implementing IComponent that drops into any container.

public class Letterhead : IComponent
{
    public void Compose(IContainer container)
    {
        container.Column(column =>
        {
            column.Item().Text("Acme Corp").Bold().FontSize(16);
            column.Item().Text("123 Example Street, Springfield");
        });
    }
}

// Use it anywhere a container is expected:
page.Header().Component(new Letterhead());

The Letterhead component renders its two-line block wherever you call .Component(new Letterhead()). Components keep shared layout in one place instead of copying the same fluent calls into every document.

Styling text, fonts, and color

Styling is chained onto any text run, and a page-wide default keeps things consistent:

page.DefaultTextStyle(x => x.FontSize(11).FontFamily("Lato"));

column.Item().Text("Heading").FontSize(18).Bold().FontColor(Colors.Blue.Darken2);
column.Item().Text(t =>
{
    t.Span("Status: ");
    t.Span("PAID").Bold().FontColor(Colors.Green.Darken1);
});

On Linux containers, make sure the font you name is actually installed (or bundle it), or QuestPDF falls back to a default face.

Setting page size, margins, and orientation

page.Size(PageSizes.A4.Landscape());
page.MarginHorizontal(2, Unit.Centimetre);
page.MarginVertical(1.5f, Unit.Centimetre);

PageSizes includes the common presets (A4, Letter, and so on), and .Landscape() flips any of them.

Generate a report from your data

Real documents come from a model. Here a list of rows becomes a styled report section:

public byte[] BuildReport(IReadOnlyList<(string Label, decimal Value)> rows)
{
    QuestPDF.Settings.License = LicenseType.Community;

    return Document.Create(container =>
    {
        container.Page(page =>
        {
            page.Size(PageSizes.A4);
            page.Margin(2, Unit.Centimetre);
            page.Header().Text("Quarterly Summary").FontSize(18).Bold();

            page.Content().PaddingTop(10).Column(column =>
            {
                column.Spacing(6);
                foreach (var (label, value) in rows)
                {
                    column.Item().Row(row =>
                    {
                        row.RelativeItem().Text(label);
                        row.ConstantItem(100).AlignRight().Text($"${value:0.00}");
                    });
                }
            });

            page.Footer().AlignCenter().Text(t => { t.CurrentPageNumber(); t.Span(" / "); t.TotalPages(); });
        });
    }).GeneratePdf();
}

GeneratePdf() with no argument returns a byte[], which is exactly what an API endpoint returns to the client.

Where QuestPDF stops: HTML, reading, and converting

Worth stating plainly, because it decides whether QuestPDF fits: it is generation-only. It does not render HTML, CSS, or Razor, and it cannot open, read, extract text from, edit, merge, or convert an existing PDF. Those are deliberate scope choices, not bugs, and for code-first document generation they do not matter. They matter when your input is HTML or an existing PDF.

When your source of truth is HTML, not C

If the document already lives as an HTML or Razor template (a designer-owned invoice, an existing web view), reproducing it in fluent code is real work, and QuestPDF cannot consume the markup directly.

IronPDF is a commercial library that renders HTML or Razor markup to PDF through a Chromium engine, so the template you already maintain stays the source of truth. It renders a Razor view straight to PDF and takes a raw HTML string just as readily. A workflow using it looks like this:

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();

// Render an HTML string; a rendered Razor view is passed the same way
var pdf = renderer.RenderHtmlAsPdf("<h1>Invoice #1042</h1><p>Total: $1,200.00</p>");

pdf.SaveAs("invoice.pdf");

This produces a PDF from the HTML string using Chromium's rendering engine. The trade-offs compared to QuestPDF:

Existing HTML and Razor templates work as inputs, which QuestPDF does not support.
It requires a paid commercial license; there is no free tier for production use.
The Chromium engine adds over 100 MB to the deployment footprint.
On Linux, native dependencies (libgdiplus, system fonts) must be installed on the host or container.

For documents you define in code, QuestPDF carries none of those costs: pure managed .NET, no native binary, no commercial license required under the community revenue threshold.

Running QuestPDF on Linux, Docker, and in ASP.NET

QuestPDF is managed code with no native binary to ship, so deployment is the same as the rest of your app. In ASP.NET Core, return the bytes directly:

app.MapGet("/report", () =>
{
    var pdf = BuildReport(GetRows());
    return Results.File(pdf, "application/pdf", "report.pdf");
});

No headless browser to install, no Chromium layer, no extra container configuration. It deploys cleanly to Linux, Docker, and serverless hosts.

Common pitfalls

License set too late. Set QuestPDF.Settings.License at startup, before the first Document.Create, or generation throws.
Naming a font that is not installed. On slim Linux images, reference a font that exists on the host or bundle it.
Expecting HTML. Passing an HTML string to QuestPDF does nothing useful; it is not an HTML renderer.
Over-nesting cells and items. Deep per-item layouts slow large documents; keep item content shallow.

FAQ

Does QuestPDF need a purchased license key in code?
You set a LicenseType (Community, Professional, or Enterprise). Community needs no purchased key under the $1M revenue threshold.

Can QuestPDF render HTML or a Razor view?
No. It is code-first by design. For HTML input, rebuild it with the fluent API or use an HTML-rendering library.

Does it run on Linux and in containers?
Yes. Managed .NET, no native binary, so it deploys like any other dependency.

Which .NET versions are supported?
It targets net6.0 and netstandard2.0, so it runs on .NET 8 and .NET 10.

How do I preview a document while developing?
Use the QuestPDF Companion app for live preview and hot reload, covered in a separate guide.

What kind of documents are you building?

Are you generating reports from structured data, converting existing HTML invoices, or something else? The answer changes which library fits, and I'm curious what real-world use cases people are hitting with .NET PDF generation in 2026.

Takeaways

QuestPDF is the strongest free option for code-first PDF generation in .NET: one package, no native runtime, no commercial license under the community threshold. Learn the container model and the three primitives (Column, Row, Text) and you can build most business documents, with tables and images layered on top. Reach for an HTML renderer when your content genuinely starts life as HTML, or when you need to read or edit existing PDFs, neither of which QuestPDF handles.

If you're in the HTML-to-PDF camp and want to test against your own templates, IronPDF offers a 30-day trial.

QuestPDF Docs: Where to Start with the C# PDF Library

IronSoftware — Fri, 12 Jun 2026 19:48:09 +0000

QuestPDF's official documentation is thorough, which is great once you know the shape of the library and a little overwhelming on day one. This guide is a concept map: the order to learn things in, the few ideas everything else builds on, and the fastest path from install to a document you understand. It points at the official pages so you always have the authoritative reference alongside.

Where should I start in the QuestPDF docs?

Start with the mental model, not the API list. QuestPDF documents are a tree of nested containers, and almost everything you read later is a variation on that one idea. The quick-start guide is the right first page; read it for the shape, then come back here for the order to learn the rest.

The mental model everything builds on

Four concepts unlock the rest of the documentation:

Document and Page: a Document holds one or more pages; each page has a header, content, and footer.
Containers: every element is a container you configure by chaining (.Padding(), .Background(), .AlignRight()), and containers nest.
Layout primitives: Column, Row, and Table arrange child containers.
Text: styled runs, including dynamic spans like page numbers.

Once the container tree clicks, the API reference stops being a wall of methods and becomes a lookup.

Read these three sections first

In order, the minimum to be productive:

Quick start: install the package and set the license.
Basic concepts: the container model and the Column / Row / Table primitives.
One worked example: a document that uses a header, a table, and a footer together.

What to read after the basics

Once the basics land, the high-value pages are the table API (most reports need it), text styling and fonts, images, and page settings (size, margins, orientation). Bookmark the API reference rather than reading it cover to cover; you will return to it per feature, not in one sitting.

Worked example: quick-start to a real document

Run this, then read each method in the docs as a question you already have an answer to:

using QuestPDF.Fluent;
using QuestPDF.Helpers;
using QuestPDF.Infrastructure;

QuestPDF.Settings.License = LicenseType.Community;

Document.Create(container =>
{
    container.Page(page =>
    {
        page.Margin(2, Unit.Centimetre);
        page.Header().Text("Statement").Bold().FontSize(18);
        page.Content().PaddingTop(10).Text("Start here, then add a table.");
        page.Footer().AlignCenter().Text(t => { t.CurrentPageNumber(); t.Span(" / "); t.TotalPages(); });
    });
})
.GeneratePdf("start.pdf");

This generates start.pdf in the working directory. Every method here has a docs page; learning them in the context of a running example is faster than reading them cold.

The example repository worth cloning

Beyond the prose docs, an official repository teaches by example: the invoice sample is a full, realistic document (header, line-item table, totals, footer) you can run and read end to end. For learning how the pieces fit, stepping through that sample is often faster than the reference, and it pairs well with the quick-start.

Finding the API reference

The API reference is organized by element, mirroring the mental model: a page for Column, pages for the table (basics, header and footer, cell styling, overlapping cells), and pages for text, images, and page settings. When you hit a specific need ("repeat a table header," "span two columns"), go straight to that element's page rather than searching the whole site.

Docs for an HTML-first workflow

QuestPDF's docs assume a code-first model: you describe layout in C#. If your team thinks in HTML and CSS instead (designers own the templates, content comes from a web view), the most useful documentation is for a library built around HTML rendering, because QuestPDF's docs never cover an HTML input path.

IronPDF is a commercial library that documents the HTML and ASP.NET view path directly, so the markup your team already writes becomes the PDF. Its guides cover converting HTML to PDF in ASP.NET and C#, a different starting point than fluent layout. A workflow using it looks like this:

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();

// viewHtml is the rendered output of an ASP.NET view, or any HTML string
var pdf = renderer.RenderHtmlAsPdf(viewHtml);

pdf.SaveAs("from-view.pdf");

This produces a PDF from the HTML string. The trade-offs compared to QuestPDF:

HTML and ASP.NET view rendering are fully documented, which QuestPDF does not cover.
It requires a paid commercial license; there is no free tier for production use.
The Chromium rendering engine adds over 100 MB to the deployment footprint.
On Linux, native dependencies (libgdiplus, system fonts) must be installed separately.

For code-first generation, QuestPDF needs none of those things: pure managed .NET, no native binary, no license cost under the community threshold.

Common documentation gotchas

Diving into the API reference first. Read the container model before the method list, or the reference reads as noise.
Skipping the license note. The quick-start sets LicenseType; miss it and your first run throws.
Looking for an HTML page. There is none; QuestPDF is code-first by design.
Reading the whole reference up front. Use it per feature; the worked example teaches more than a cover-to-cover read.

FAQ

Is the QuestPDF documentation free to access?
Yes, it is public on the project's site, independent of which license tier governs your use.

Do I need to read all of it before building?
No. Quick start, basic concepts, and one worked example are enough to be productive; treat the rest as reference.

Where are the code examples?
Throughout the docs and in the worked examples; the fluent API is example-driven, so most pages show runnable snippets.

Where is the table documentation?
Under the API reference: basics, header and footer, cell style pattern, and overlapping cells each have their own page.

What if my documents are really HTML?
HTML-rendering documentation will serve you better than a code-first layout guide; see the section above.

What does your document source look like?

Does your content start life as C# models and data, or does it live in HTML templates that designers maintain? That distinction drives the library choice more than any feature list. I'm curious how your team's documents actually get generated today.

Takeaways

For code-first generation, QuestPDF is the better fit: no commercial license below the revenue threshold, no Chromium, no native dependencies. Learn the container tree first, read quick-start plus basic concepts plus one worked example, then use the rest as reference organized by element. If your pipeline starts with HTML templates instead of C# data, an HTML-rendering library's docs are the ones to follow.

If you're building an HTML-to-PDF workflow on top of ASP.NET, try IronPDF free for 30 days to test it against your own templates.

QuestPDF Companion: Live PDF Preview and Hot Reload

IronSoftware — Fri, 12 Jun 2026 19:47:36 +0000

Iterating on a PDF layout by regenerating the file, opening it in a viewer, and squinting at the diff is slow. QuestPDF's Companion app removes that loop: it renders your document live and refreshes as you change the code. This guide covers what the Companion is, how to wire up hot reload, what it shows that a flat PDF cannot, and where it fits in a real workflow. It requires QuestPDF 2024.10 or newer; everything here targets 2026.5.0.

What is the QuestPDF Companion app?

The Companion is a desktop previewer that pairs with your .NET project. Instead of writing a PDF to disk on every change, you point your document at the Companion and it displays the rendered result, refreshing when you re-run. It also surfaces layout information a flat PDF does not, which is what makes it more than a viewer. The app is a separate download that runs alongside your IDE.

How do I preview a document live?

Build the document as usual, then call the Companion method instead of (or alongside) GeneratePdf:

using QuestPDF.Fluent;
using QuestPDF.Helpers;
using QuestPDF.Infrastructure;

QuestPDF.Settings.License = LicenseType.Community;

var document = Document.Create(container =>
{
    container.Page(page =>
    {
        page.Size(PageSizes.A4);
        page.Margin(2, Unit.Centimetre);
        page.Content().Text("Edit me and re-run to see the preview update.");
    });
});

// Streams the document to the Companion app (default HTTP port 12500)
document.ShowInCompanion();

With the Companion app running, each execution updates the preview. You adjust margins, spacing, or table widths and see the effect immediately without writing a file to disk.

Wiring up hot reload

Live preview becomes a tight loop with hot reload. Start your application in DEBUG mode with "Hot Reload on Save" enabled, and on every file save the document refreshes in the Companion without a full restart. The communication runs over a local HTTP port (12500 by default), which you can override by passing a port to ShowInCompanion(port) if something else is using it. The features page documents the supported workflow.

What the Companion shows you

This is where it earns its place over a PDF viewer. The Companion can:

Highlight the visible layout structure, so you see how containers are sized and nested.
Show the attributes of a selected element (padding, size, alignment).
Present the document as a tree, so you can navigate the hierarchy instead of scrolling pages.
Render in light or dark mode to match your environment.

For debugging an overflow or a spacing bug, seeing the layout tree is far faster than inferring the problem from a generated page.

ShowInCompanion and the older previewer

If you are on an older codebase you may see ShowInPreviewer() instead. The Companion is the current tool, and ShowInCompanion() is its method, available from QuestPDF 2024.10 onward. If the method is missing, your package version predates the Companion; upgrade before wiring it up. The repository for the app lives at github.com/QuestPDF/QuestPDF.Companion.

Why it speeds up the inner loop

Three concrete wins:

No file churn. You are not generating and opening output.pdf dozens of times.
Faster layout debugging. Overflow and spacing problems are visible directly, not inferred from a static page.
Tighter feedback. Change code, save, look. The cycle drops from many seconds to near-instant for small edits.

It is a development-time tool. Production code still calls GeneratePdf (or generates to a stream); the Companion is for the authoring phase only.

From preview to production output

The Companion is a development aid; production code generates the file or bytes directly from the same document definition you previewed. The switch is one call:

// Development: live preview in the Companion
document.ShowInCompanion();

// Production: generate bytes, or GeneratePdf("file.pdf") for a file
byte[] pdf = document.GeneratePdf();

Keep the ShowInCompanion() call behind a debug check or remove it before shipping; the production path never touches the Companion.

An HTML-first preview loop

The Companion is the right tool for code-first layouts. If your document is built from HTML and CSS, the Companion does not apply because QuestPDF does not accept HTML input.

IronPDF is a commercial library that renders HTML files through a Chromium engine, which means your browser stays the live preview tool. It converts an HTML file to PDF using Chromium, so the file you tweak in the browser is the same one that becomes the PDF. A workflow using it looks like this:

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();

// Render the very file you have open in the browser
var pdf = renderer.RenderHtmlFileAsPdf("preview.html");

pdf.SaveAs("preview.pdf");

This produces a PDF from the HTML file on disk. The trade-offs compared to QuestPDF plus the Companion:

Your browser remains the live preview tool with no separate previewer to install.
It requires a paid commercial license.
The Chromium engine adds over 100 MB to the deployment footprint.
On Linux, native dependencies (libgdiplus, system fonts) must be present.

For fluent C# documents, QuestPDF and the Companion carry none of those costs: pure managed .NET, free under the community threshold, no Chromium layer.

Common Companion pitfalls

App not running. ShowInCompanion() streams to the desktop app; start the app first or nothing appears.
Not in DEBUG with hot reload. The live refresh depends on "Hot Reload on Save" in a DEBUG run.
Package too old. ShowInCompanion() needs QuestPDF 2024.10+; older versions only have ShowInPreviewer().
Port in use. The default 12500 can clash; pass an explicit port to ShowInCompanion(port).
Shipping it. Do not leave ShowInCompanion() in production code paths; it is a development aid.

FAQ

Is the Companion app required to use QuestPDF?
No. It is an optional development aid; QuestPDF generates PDFs without it.

Does the Companion affect production?
No. You call ShowInCompanion() only while developing; production code generates the PDF directly.

Does it hot reload on every keystroke?
It refreshes when the document is rendered again, which with "Hot Reload on Save" means on each save.

Which version do I need?
QuestPDF 2024.10 or newer for ShowInCompanion(); the app itself is a separate download.

Is the Companion covered by the Community license?
Yes, the Community tier (free under the $1M revenue threshold) includes the development tooling; confirm specifics on the project's site.

What does your current PDF iteration loop look like?

Are you regenerating a file and opening it in a viewer on every change, or have you found a faster setup? I'd like to know what friction points people hit before finding the Companion.

Takeaways

For code-first .NET PDF work, the QuestPDF Companion is the most practical development tool available: no license cost, no extra runtime dependency, and a layout tree that makes spacing bugs obvious. Call ShowInCompanion(), run in DEBUG with hot reload, and iterate without regenerating files by hand. The only time it is not your fastest loop is when the document is HTML-first, where a browser plus an HTML renderer is the natural fit instead.

If your pipeline is HTML-first, try IronPDF free for 30 days to see if it fits your templates.

PdfPig: Excellent at Extraction, Honest About the Rest

IronSoftware — Thu, 11 Jun 2026 17:23:46 +0000

The conclusion first, because it is the most useful thing here: PdfPig is good. That is meant without qualification, and most of this article shows why.

Here's the thesis in one sentence: PdfPig is honest about its scope, and that honesty is the most underrated feature in any open-source library. The catch (and there is one) is that the scope is narrower than it looks at first glance, so the real question is whether its scope matches what you actually need to do.

To make that concrete, here is the entire setup ceremony for reading a PDF with PdfPig:

using UglyToad.PdfPig;

using PdfDocument document = PdfDocument.Open("report.pdf");
Console.WriteLine($"Pages: {document.NumberOfPages}");

Two lines of using-directives, one to open, one to query. No factories, no DI registration, no async setup, no native binary to ship alongside. That minimalism is a refreshing contrast to a lot of what is in the .NET PDF space.

What PdfPig Is, In Plain Terms

PdfPig is a .NET port of Apache PDFBox, the long-standing Java PDF library. It's licensed Apache 2.0: permissive, no copyleft, safe for commercial products without legal ambiguity (which is the bar a lot of "free" .NET PDF libraries quietly fail to clear). The package on NuGet has over 21 million downloads and a healthy community of contributors. Stars on the GitHub repository sit around 2,400, with active issue triage and a maintainer who actually merges PRs.

That last point matters more than star counts. Plenty of OSS libraries have 10x the stars and zero recent commits. PdfPig's most recent push at the time of this writing was late April 2026, meaning the maintainer was active on the repo within the last two weeks. Releases over the last 18 months: v0.1.11 (July 2025), v0.1.12 (November 2025), v0.1.13 (December 2025), and the current stable v0.1.14 (March 2026). That's a roughly quarterly cadence, which is plenty for a library focused on a stable problem domain.

One real caveat on versioning before we go further: PdfPig is pre-1.0. The README is upfront about this: minor versions can change the public API without SemVer guarantees until 1.0 is reached. If you're pinning a dependency in production, pin the patch version, not just the minor. The README's API-stability warning is worth taking literally.

The Core API: Extracting Text Like It's 2026

To the code. The simplest thing PdfPig does well is pulling text out of a PDF in reading order:

using UglyToad.PdfPig;
using UglyToad.PdfPig.DocumentLayoutAnalysis.TextExtractor;

using PdfDocument document = PdfDocument.Open("invoice.pdf");

foreach (Page page in document.GetPages())
{
    string text = ContentOrderTextExtractor.GetText(page);
    Console.WriteLine($"Page {page.Number}: {text.Length} chars");
}

That's it. Open a document, iterate pages, get text. No service registration, no factory pattern, no fluent builder you have to learn. The class names are honest about what they do: ContentOrderTextExtractor extracts text in content order, NearestNeighbourWordExtractor extracts words by spatial proximity. There's a small set of layout-analysis tools and they each do one thing.

A gotcha worth knowing: page.Text is not the property you want. It returns the raw content stream order, which is rarely the human reading order. The README is explicit about this: "you should not use page.Text directly, unless you know what you're doing." Developers use it anyway because it is the obvious property name, then spend an afternoon wondering why their extracted invoice totals show up before the line items. Use the layout-analysis extractors instead. They exist for exactly this reason.

Going Deeper: Words, Letters, Bounding Boxes

This is where PdfPig earns its place. Most "extract text" libraries give you a string and call it a day. PdfPig gives you a tree: pages, then letters with positions, then words assembled by spatial algorithms, then text blocks via page segmenters, then optional reading-order detection.

Here's what that looks like for a richer extraction:

using UglyToad.PdfPig;
using UglyToad.PdfPig.DocumentLayoutAnalysis.PageSegmenter;
using UglyToad.PdfPig.DocumentLayoutAnalysis.ReadingOrderDetector;
using UglyToad.PdfPig.DocumentLayoutAnalysis.WordExtractor;

using PdfDocument document = PdfDocument.Open("statement.pdf");
Page page = document.GetPage(1);

IReadOnlyList<Letter> letters = page.Letters;

var wordExtractor = NearestNeighbourWordExtractor.Instance;
IEnumerable<Word> words = wordExtractor.GetWords(letters);

var pageSegmenter = DocstrumBoundingBoxes.Instance;
IReadOnlyList<TextBlock> blocks = pageSegmenter.GetBlocks(words);

var readingOrder = UnsupervisedReadingOrderDetector.Instance;
IEnumerable<TextBlock> ordered = readingOrder.Get(blocks);

foreach (TextBlock block in ordered)
{
    Console.WriteLine($"[{block.BoundingBox}] {block.Text}");
}

If you've ever tried to do invoice parsing or statement parsing, you already know that "give us all the text" is the easy half of the problem. The hard half is "give us the text grouped by visual region, in the order a human would read it." PdfPig hands you the building blocks for that, including bounding box coordinates you can reason about geometrically. The Docstrum algorithm and the unsupervised reading-order detector aren't perfect, but they're real implementations of real research, not heuristics duct-taped together. These tools are well-suited to line-item extraction on supplier invoices and tabular data from multi-column PDF reports, exactly the kinds of workflows where regex-over-flat-string approaches collapse.

One more thing worth flagging in this PdfPig review: encrypted PDFs work fine if you have the password: pass it as the second argument to PdfDocument.Open. Some teams switch libraries assuming encrypted reading is a paid feature. With PdfPig, it is included.

Worth knowing on the runtime side: the current stable PdfPig package targets .NET Standard 2.0 and .NET Framework 4.6.2, which means it runs across current .NET LTS releases (.NET 8 and .NET 10), older Framework apps, and anything in between. The same API surfaces in mixed environments without target-framework friction.

The Creation Footnote, and Why It's a Footnote

PdfPig does support PDF creation through PdfDocumentBuilder. The README has an example: register a Standard 14 font, add a page, drop some text, write bytes. It works for what it's documented to do.

But the documentation itself is upfront about what it can't do, and these matter for production workflows. From the README:

Document creation supports very limited changes to existing PDF documents. However it does not support any of the following: Editing forms, Copying or changing annotations, metadata or document structure data, Adding or removing text with existing fonts.

Far from a backhanded criticism, that is the maintainer being honest about what the creation API is for. It's there so you can produce simple debug PDFs (the wiki shows an example of overlaying bounding boxes on an extracted page for layout-analysis debugging, which is a great use case for this API). It's not there to be your invoice generator, your report builder, or your form-filling pipeline.

If your workflow is "read PDFs and extract data," PdfPig is excellent. If your workflow is "read PDFs, modify them, fill forms, sign them, and emit new PDFs," you're going to hit the wall on the creation side fast.

Where PdfPig Stops

Care is warranted here: the goal is to map the boundary rather than to list everything PdfPig doesn't do, which would be an unfair frame for any library. The point is to know whether your workflow lives inside that boundary or outside it.

What PdfPig genuinely does not do, per its own documentation:

HTML-to-PDF conversion. Not its job. The wiki recommends other libraries for this.
PDF rendering to images. Not its job either. The wiki points at docnet or PDFtoImage. There's a separate PdfPig.Rendering.Skia package that adds rendering, but it's a separate concern.
Form population. Forms are readable but read-only: you cannot change values or add new form fields.
Digital signatures. No signing, no signature validation in the way a compliance-driven workflow would need it.
PDF/A or PDF/UA compliance. Out of scope.
Editing existing PDFs. You can read them; the creation API can produce simple new pages but isn't intended for round-trip editing of arbitrary input PDFs.
Accessibility tagging. Out of scope.

None of these are flaws. They're scope boundaries the maintainer drew on purpose, and the documentation tells you exactly where they are. That's the rare, valuable thing.

When PdfPig Is the Right Tool

Concretely, here are workflows where PdfPig is the first choice:

Data extraction from PDFs. Invoices, statements, regulatory filings, scientific papers, anything where the PDF is the input and structured data is the output. PdfPig's letter-level positioning and word/block extractors are specifically designed for this.
Search indexing. Pulling text out of a PDF corpus to feed into a search engine. The text-extraction APIs are fast and stable.
Layout analysis and document understanding. Research workflows where you need bounding boxes, reading order, and the geometric structure of the page. PdfPig is one of the few .NET options that exposes this layer.
Lightweight inspection tooling. Debug viewers, validators, content audits. The basic creation API is good enough for overlays and annotations on extracted content.

If your job description includes the phrase "we need to read a PDF and pull data out of it," PdfPig should be on your shortlist before you look at anything paid.

When PdfPig Leaves You Short

The flip side, also concretely:

You need to render HTML or web content to PDF: PdfPig isn't your tool. You need a browser-engine-backed library or a layout engine.
You need to fill in PDF forms and save them back: PdfPig can read the form fields, but it can't write them.
You need to digitally sign PDFs for compliance, contracts, or audit trail purposes: out of scope.
You need PDF/A archival format compliance for regulated industries: out of scope.
You need to generate complex multi-page reports with tables, charts, and styled typography from a template: the basic creation API isn't built for this.
You need to round-trip-edit existing PDFs (read in, modify, write out). The creation API explicitly doesn't support this for non-trivial documents.

For workflows that span both reading and writing (extract data from a PDF, generate a new PDF based on what you extracted, sign it, archive it), you'll need either a second library to handle the write half or a single library that covers both halves.

The Workflow Tax: One Library Won't Cover Both Halves

The honest scope is exactly what PdfPig's maintainer has documented, and it is the property that makes PdfPig genuinely good at what it does. The implication for production planning is the one most readers leave the documentation without quite naming: any workflow that spans both reading and writing (extract from input PDFs, produce or modify output PDFs) commits the team to a second library, with its own license, its own dependency footprint, its own deployment surface, and its own maintenance trajectory.

This is the workflow tax. PdfPig is free in the literal sense: Apache 2.0, no commercial gating, no revenue threshold, no native binary to ship. PdfPig is not free in the architectural sense for any workflow that needs to write back. The bill comes due the moment the team's roadmap includes form filling, digital signatures, PDF/A archival output, template-driven PDF generation, round-trip editing, HTML-to-PDF rendering, or any of the categories the README is explicit about not covering.

The bill takes one of two forms. Either the team adopts a second PDF library (commercial or open-source) to cover the write half, and now pays a license fee, accepts another dependency's maintenance trajectory, and absorbs the integration cost of coordinating two libraries' object models. Or the team builds the missing functionality in-house, which means writing what is effectively a second PDF library at internal cost, engineer-quarters rather than engineer-weeks for any non-trivial scope.

For teams whose workflow is genuinely one-directional (search indexing, document understanding, invoice parsing, regulatory-filing analysis), PdfPig stands alone and the workflow tax is zero. For teams whose workflow is intake-then-emit (read an invoice, generate an audit document; parse a regulatory submission, produce a redacted version; extract data, sign and archive), the architectural picture is two libraries, and the question becomes not "is PdfPig free?" but "is the combined cost of PdfPig plus the second library lower than the cost of a single-library solution?"

The answer is workload-dependent. The cleaner the read/write split (different teams, different services, different infrastructure), the better the two-library composition. The tighter the integration (same service, shared models, frequent round-trips), the more attractive a single library that covers both halves becomes. Treating this as a workflow architecture decision rather than a free-vs-paid library decision is the framing the rest of this article exists to support.

A Complementary Approach

This is where the honest framing matters most. PdfPig and a generation-capable library aren't strictly competitors; they're often complementary. Teams commonly pair them: PdfPig for the extraction half of a workflow, a generation library for the rendering, signing, and form-filling half.

A toy version of that pattern:

// Stage 1: PdfPig extracts data from the source document
using UglyToad.PdfPig;
using UglyToad.PdfPig.DocumentLayoutAnalysis.TextExtractor;

string sourceText;
using (PdfDocument source = PdfDocument.Open("incoming-invoice.pdf"))
{
    var page = source.GetPage(1);
    sourceText = ContentOrderTextExtractor.GetText(page);
}

InvoiceData parsed = ParseInvoice(sourceText);

// Stage 2: A generation-capable library produces the audit PDF
// (a generation library would handle this stage)
string auditHtml = $"<h1>Audit for {parsed.InvoiceNumber}</h1>...";
// ... HTML-to-PDF conversion, signing, etc., happens here

A range of generation libraries can cover the second stage. The point is that "PdfPig vs anything else" is often the wrong frame. PdfPig is the right tool for its half of the workflow. The architecture question is what tool covers the other half, and whether you want one library that does both halves or two libraries each doing what they do best.

Final Honest Take

If you're building data-extraction tooling and PdfPig fits your workflow, use PdfPig. The library is well-maintained, fairly licensed, technically solid, and refreshingly honest about its scope.

If your workflow needs both reading and writing capabilities and you want to evaluate unified options, read the licensing carefully on whatever you pick. The honest answer to "which library should we use?" almost always depends on your specific workflow, your team's constraints, and your budget.

The .NET PDF space has too many libraries claiming to do everything and quietly failing at half of it, and PdfPig is the opposite: it claims to do a focused set of things, and it does them. That's worth saying out loud.

When you also need to create or edit PDFs

PdfPig is read-only by design. It extracts text, positions, and structure, and does that well, and it cannot create, modify, or sign a document. A pipeline that only ingests PDFs never hits that limit, but a pipeline that reads and also has to produce, fill, or sign one needs a second tool for the write half.

IronPDF, a commercial library, reads and writes in one package, so the same library that extracts text can also create, edit, and sign the output.

It can create and edit PDFs, covering the write half PdfPig leaves open. A commercial-library workflow looks like this:

// Install: dotnet add package IronPdf
using IronPdf;

// One library for both halves: render new output, then edit or sign it
IronPdf.License.LicenseKey = "YOUR-TRIAL-OR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf("<h1>Created, not just read</h1>");
pdf.SaveAs("output.pdf");

Pro: read and write in one library, where PdfPig is read-only and needs a second tool.
Con: a commercial license, where PdfPig is Apache 2.0 and free.

If your workflow has to both read and produce, the free trial, no credit card required lets you prototype the round trip first. For extraction-only work, PdfPig stays the lighter, better-scoped choice.

What are you extracting with PdfPig, and how do you cover the write half when you need it: a second library, or build it in-house?

PdfSharp 2026: Great at the Basics, Narrow Everywhere Else

IronSoftware — Wed, 10 Jun 2026 16:14:06 +0000

PDFSharp is the kind of library that has aged well. It is open source, it is permissively licensed, it is still being released, and its documented feature set has actually grown over the past few years. Reviewing it in 2026 is a different exercise from reviewing it in 2020: several of the gaps that defined PDFSharp's reputation (no PDF/A, no digital signatures, no PDF/UA accessibility) have been closed in the 6.2.x release line, which puts the library in a meaningfully different position than the older comparison articles suggest.

The .NET PDF landscape is full of articles that either oversell free libraries or write them off, and PDFSharp deserves neither treatment. The library is genuinely useful within its scope; the architectural question is whether your scope and PDFSharp's scope are the same shape.

To make the argument concrete before going further, here is what generating a basic styled invoice looks like in PDFSharp:

using PdfSharp.Drawing;
using PdfSharp.Pdf;

var document = new PdfDocument();
var page = document.AddPage();
var gfx = XGraphics.FromPdfPage(page);
var titleFont = new XFont("Arial", 20, XFontStyleEx.Bold);
var bodyFont = new XFont("Arial", 12, XFontStyleEx.Regular);

gfx.DrawString("Invoice 2026-0428", titleFont, XBrushes.Black,
    new XRect(40, 40, page.Width.Point - 80, 30), XStringFormats.TopLeft);
gfx.DrawString("Total due: $1,240.00", bodyFont, XBrushes.Black,
    new XRect(40, 80, page.Width.Point - 80, 20), XStringFormats.TopLeft);

document.Save("invoice.pdf");

That is a complete, runnable program. No external binary, no headless browser, no system dependency: a managed-code .NET library that produces a valid PDF on every supported runtime. If your job is to draw text and lines onto a page in a predictable, scriptable way, PDFSharp does that job and has done it reliably for years.

What PDFSharp Genuinely Does Well

Before the section on where the library's scope ends, the strengths deserve real space. This is not grading on a curve.

The license is genuinely permissive. PDFSharp is published under the MIT License by empira Software GmbH, with copyright spanning 2005 through 2026. There is no dual-licensing trap, no commercial-tier threshold, no "free for non-commercial use" asterisk. You can use PDFSharp in proprietary software, in SaaS deployments, in shipped products, and the licensing question is fully answered by reading one short license file. Among free .NET PDF libraries, that level of clarity is the exception, not the rule.

The project is still maintained. The current package is PDFsharp 6.2.4 on NuGet, with target frameworks of net8.0, net9.0, net10.0, and netstandard2.0. The package was last updated 2026-01-06. The GitHub repository shows ongoing commits and releases, and the maintainer ships regularly. This is not the maintenance picture you get with several other "free" .NET PDF libraries where the last meaningful release was years ago.

The core PDF object model is solid. PDFSharp gives you direct access to the PDF document structure: pages, fonts, graphics state, content streams, the document catalog. If you want to merge documents, split documents, extract pages, set metadata, or manipulate the page tree, the API maps cleanly onto the PDF specification. This is harder to appreciate in a feature checklist than in code, but it matters: you can get unusual things done in PDFSharp because the abstraction does not stand between you and the format.

Encryption is current and standards-aligned. Per the encryption documentation, PDFSharp supports AES-128 (encryption v4, supported by PDF 1.5 and later) and AES-256 (encryption v5, only supported in PDF 2.0). Version 6.2.0 added read support for the proprietary revision-5 encryption scheme as well. For the common case (encrypting a generated document with a user password and an owner password), the API is short and the cipher choices are not stuck in 2010.

Digital signatures landed in 6.2.0. This is the biggest change to PDFSharp's surface area in the recent release line. The signatures topic documents CMS-based signing with a built-in PdfSharpDefaultSigner and an IDigitalSigner interface for custom signers. Timestamp-server URIs are supported on .NET, with the documented caveat that timestamps are not supported on the .NET Framework build. For straightforward signing workflows where you have a certificate and want to apply a CMS signature, the surface area is reasonable and the implementation is in a separate PdfSharp.Cryptography assembly so you do not pay the dependency cost unless you need the feature.

PDF/A and PDF/UA are listed as supported. Per the PDF features overview, PDFSharp supports creating PDF/A-conforming documents for archival and adding PDF/UA accessibility tagging. This is a meaningful expansion from older versions, and it closes one of the most common objections to PDFSharp in regulated-industry contexts. The gaps section returns to this because the breadth of conformance levels matters, but the fact that the categories are addressed at all is the news.

MigraDoc gives you a higher-level composition layer. PDFSharp on its own is a drawing library: you position graphics on a page in coordinate space. For document workflows where you actually want paragraphs, tables, headers, and pagination, the PDFsharp-MigraDoc package layers a document model on top. MigraDoc depends on PDFSharp and ships from the same maintainer at matched versions, so the integration is real, not an afterthought. The trade-off, named explicitly in the next section, is that you are now adopting two libraries with two mental models.

The deployment story is clean. PDFSharp is managed code. There is no native binary to ship, no Chromium engine to package, no system-wide tool to install on the host. A NuGet reference, a dotnet publish, and you are done. On Linux containers, on Windows servers, on serverless functions, the deployment shape is the same one you already use for the rest of your .NET application. The package targets netstandard2.0 alongside the current runtimes, which means it slots into legacy and modern codebases without the target-framework friction that has bitten teams adopting newer libraries.

Performance is rarely the issue. For the workloads PDFSharp is designed for (programmatic generation of structured documents in the dozens-to-thousands per minute range), throughput is not the architectural concern. The library is fast enough that you can usually move on to harder questions.

That is the case for PDFSharp, and it is a stronger case in 2026 than it was three years ago. None of those points are qualified-with-an-asterisk: the library is well-maintained, well-licensed, structurally clean, and substantially more feature-complete than its older reputation suggests. If your PDF needs sit comfortably inside that envelope, you should use PDFSharp and stop reading comparison articles.

Where the Scope Ends

The piece of the article you actually came for: PDFSharp's documented feature set still has gaps, and those gaps are predictable enough to lay out in a table. The feature matrix below was compiled from PDFSharp's own documentation and verified at write-time on 2026-05-09.

Capability	PDFSharp 6.2.x	Notes
Programmatic PDF generation	Yes	Native, well-documented
Merge / split / page manipulation	Yes	Direct PDF object model
Encryption (AES-128, AES-256)	Yes	Including PDF 2.0 crypt filters
Digital signatures (CMS)	Yes (6.2.0+)	Timestamp support not on .NET Framework build
PDF/A archival	Yes	Conformance level breadth not enumerated in docs
PDF/UA accessibility tagging	Yes	Tagging primitives present
HTML to PDF	No	Requires `HtmlRenderer.PdfSharp` (HTML 4.01 / CSS 2)
JavaScript rendering	No	No browser engine
CSS3 / modern web layout	No	Out of scope
PDF to image rasterization	No	No `Page → bitmap` API
High-level text extraction	No	Low-level content-stream access only
Complex table layouts	Limited	Use MigraDoc for document composition
Form filling	Partial	Object-model access; no high-level form API

Each row in that matrix is a real architectural decision waiting to happen. Read this section as the "what does your project actually need" worksheet.

HTML to PDF is the big one. If your PDF generation pipeline starts from an HTML template (and many do, because designers can produce HTML and cannot produce PDFSharp drawing code), PDFSharp does not solve the problem. The community answer is HtmlRenderer.PdfSharp at version 1.5.2 on NuGet. Two things to know about that package: it supports HTML 4.01 and CSS Level 2, which is fine for invoices with tables and predictable layouts but cannot render modern web pages with flexbox, grid, custom properties, web fonts loaded over the network, or anything that depends on JavaScript. Second, the HtmlRenderer repository has an open community discussion (Issue #151) where a user has offered to take over maintenance, indicating the long-term steward of the project is an open question. The package still works; the question of how long it will keep up with the .NET runtime cadence is one the reader should evaluate against their own timeline.

JavaScript-rendered content is out of scope by construction. PDFSharp is not a browser engine. If your source document is a React app, a Vue dashboard, or any HTML page where the visible content is assembled by client-side JavaScript, PDFSharp cannot turn it into a PDF. This is a property of the library's design (managed C# all the way down), not a defect, but it is a hard architectural ceiling.

PDF-to-image rasterization is missing. If your workflow needs to produce thumbnails, page previews, or rendered images from a PDF, PDFSharp does not have a Page → PNG or Page → JPEG API. You would integrate a separate rendering library. For applications that surface PDFs in a web UI with thumbnail navigation, this is a real gap.

Text extraction is low-level only. PDFSharp gives you content-stream access; it does not give you a high-level "extract paragraphs" or "extract words with bounding boxes" API. For document-analysis or invoice-parsing workflows, that means writing your own text reconstruction layer, or using a different library for that step.

PDF/A and PDF/UA support are present, but conformance breadth is not enumerated. The docs confirm that PDFSharp supports creating PDF/A-conforming documents and adding PDF/UA accessibility, which is exactly what the categories require. What the docs do not enumerate is which conformance levels (PDF/A-1a vs A-1b vs A-2a vs A-2b vs A-2u vs A-3a/b/u) are produced, nor whether the output passes third-party validators like veraPDF without remediation. If you are in a regulated context where the conformance level is a contractual requirement rather than a category checkbox, validate the output against your specific level before depending on it.

Complex tables push you to MigraDoc. PDFSharp draws; MigraDoc composes. The split is reasonable, but it is two libraries, two mental models, and two version surfaces to keep aligned. Teams that adopt PDFSharp for "simple PDF generation" and then need real tables often discover they have effectively adopted MigraDoc as well, which is fine but should be a conscious decision.

Why PDFSharp Cannot Be a Modern HTML-Rendering Solution

The feature-matrix gap above is most often summarized as "PDFSharp doesn't do HTML, so you bolt on HtmlRenderer.PdfSharp." The summary is accurate, and it is the half of the picture that justifies a closer look in 2026.

HtmlRenderer.PdfSharp is the community-maintained bridge that lets PDFSharp consume HTML input. It is real, it is functional, and for the workloads it covers (HTML 4.01 with CSS Level 2: invoices, statements, predictable layout templates) it remains a viable choice. The maintenance picture, however, is not as healthy as PDFSharp's. The HtmlRenderer GitHub repository's Issue #151 is an open conversation in which a community member has offered to take over maintenance, an indication that the project's long-term steward is genuinely an open question. The package on NuGet remains at version 1.5.2 with no recent updates, and the rendering engine itself is locked to a 2010-era subset of HTML and CSS that pre-dates flexbox, grid, custom properties, modern web fonts, and anything that depends on JavaScript.

The architectural implication is consequential. PDFSharp the library is well-maintained, MIT-licensed, and structurally clean. The moment a team's PDF pipeline starts from anything other than coordinate-space drawing (Razor views, design-tool exports, customer-facing dashboard captures, anything a designer can produce in HTML), the team is no longer choosing PDFSharp alone. They are choosing PDFSharp paired with HtmlRenderer.PdfSharp, and inheriting both the CSS2-era rendering ceiling and the open question of who will maintain the bridge over the .NET 10 LTS support window.

This is the case where "free" and "fit for modern commercial use" diverge for PDFSharp. The library itself is fine. The HTML-rendering pipeline a modern team actually needs is not built into the library and is not maintained by the same hands. For workloads whose PDF inputs originate as HTML, the practical recommendation is to either commit to a layout-DSL approach (which PDFSharp and MigraDoc together can serve cleanly) or to choose a library whose HTML rendering is in-scope and version-aligned with the rest of the package, a different architectural choice from "free + bolt-on HTML."

There is no inheritance argument against PDFSharp itself. The dependency-decay risk lives one package over, in the HTML bridge most adoptions implicitly take alongside the main library. Teams whose pipeline never needs that bridge can stop reading here and ship PDFSharp; teams whose pipeline does need it should treat HtmlRenderer.PdfSharp's maintenance status as a real input to the decision, not a footnote.

The Trade-Off: Drawing vs. Rendering

The alternative to a coordinate-space drawing library is a Chromium-based rendering engine wrapped in a managed .NET library, which means the HTML row in the matrix above flips: HTML5, CSS3, JavaScript, web fonts, SVG, and modern layout primitives all render through a bundled Chrome engine without an external binary install. Page rasterization, high-level text extraction, form filling, and PDF/A / PDF/UA conformance can be bundled into a single NuGet package. The trade-off is a larger deployment footprint (the Chromium engine ships with the package) and a commercial license.

That trade-off is the actual decision. PDFSharp is free, MIT-licensed, and architecturally minimal; it solves the programmatic-generation problem without expanding your dependency surface. A Chromium-based commercial library costs money, ships a heavier engine, and solves the HTML-rendering and modern-feature problem without you assembling a stack of helper libraries. Neither answer is universally right.

The Conditional Verdict

PDFSharp in 2026 is a better library than its older reviews suggest. The 6.2.x release line meaningfully closed the gaps that used to define the comparison: encryption is current, digital signatures exist, PDF/A and PDF/UA are addressed, the project is being maintained, the license is genuinely permissive. For programmatic PDF generation that lives entirely inside .NET, with no HTML pipeline and no JavaScript-rendered source content, PDFSharp is a reasonable default, with no argument against it here.

The conditional half of the verdict is that the architectural envelope is narrower than it looks on a feature checklist. The moment your pipeline needs HTML-to-PDF beyond HTML 4.01, or JavaScript rendering, or PDF-to-image, or high-level text extraction, or strict conformance-level PDF/A validation, you are either composing PDFSharp with helper libraries (some of which are looking for new maintainers) or you are reaching for a different tool. That is not PDFSharp's fault. It is the scope the maintainer chose, and the scope they have stayed honest about.

So: read the feature matrix above against your actual pipeline. If every row you need is a green cell, ship PDFSharp and go build the rest of your product. If two or three of the rows you need are not green, that is the decision moment, and it is worth making it deliberately rather than discovering it three sprints in.

When you need HTML/CSS rendering

PDFSharp draws in coordinate space: you place text and graphics by position in C#. That fits when you think in points and margins, and fits poorly when the document already exists as HTML and CSS, such as a designer-owned invoice template, a marketing page, or a styled report, because PDFSharp has no modern HTML rendering path.

IronPDF, a commercial library, renders HTML and CSS through a Chromium engine, so the markup the web team already owns becomes the PDF without hand-placed coordinates.

It renders an HTML file to PDF with HTML5 and CSS3 rendering via a bundled Chromium engine, no coordinate math involved. A commercial-library workflow looks like this:

// Install: dotnet add package IronPdf
using IronPdf;

// HTML5 and CSS3 rendering via a bundled Chromium engine
IronPdf.License.LicenseKey = "YOUR-TRIAL-OR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf("<h1 style='color:#2c3e50'>Styled by CSS, not coordinates</h1>");
pdf.SaveAs("output.pdf");

Pro: renders modern HTML and CSS, which PDFSharp does not do without a CSS2-era bolt-on.
Con: a commercial license and a heavier engine, where PDFSharp is MIT and minimal.

If your layout lives in HTML, the 30-day trial that needs no card lets you render a real template before deciding. For coordinate-space, code-first generation with a minimal dependency, PDFSharp stays the right tool.

Where did PdfSharp's scope stop for you? Did you bolt on HtmlRenderer.PdfSharp, move to MigraDoc, or switch libraries entirely?

PuppeteerSharp PDF in Production: The Real Costs

IronSoftware — Wed, 10 Jun 2026 16:13:21 +0000

The architectural conversation that emerges when a logistics team evaluates PuppeteerSharp for high-volume PDF generation has a familiar shape. Someone on the team gets a working prototype in an afternoon. The HTML rendering quality is excellent. The API is faithful to upstream Puppeteer. The team's first inclination is "this works, let's ship it." The architect's second question, posed as a forward-looking hypothetical the review is designed to surface early rather than as a recounted incident, is: "what does this look like at 2,000 PDFs per minute, in containers, behind an autoscaler, when a year-three security audit asks which version of Chromium our PDF service is currently shipping?"

The answer to the second question is the subject of this article. It is written from the position of an architect doing the production-readiness review for a team that has already prototyped, not from the position of someone who has shipped PuppeteerSharp at logistics-scale volume. The recommendations here are based on documented operational characteristics of headless Chromium and on PuppeteerSharp's own posture about what it ships.

PuppeteerSharp is a capable library. The point is that choosing between headless-browser PDF generation and library-based PDF generation is an architectural decision rather than a library-feature one, and the architectural costs compound at production volume.

What PuppeteerSharp does well

The technical merits of PuppeteerSharp deserve airtime before the operational analysis. The library is a serious piece of engineering, and the production-readiness conversation only becomes interesting because PuppeteerSharp is genuinely capable enough to be a viable option in the first place.

PuppeteerSharp is the .NET port of Google's Puppeteer Node.js library, maintained primarily by Darío Kondratiuk. The current stable release is PuppeteerSharp 24.42.0, published in May 2026, and the project has shipped consistently across nearly every Chromium update cycle since 2017. That maintenance posture matters: a wrapper around a moving Chromium target only works if the wrapper moves with Chromium, and PuppeteerSharp's release cadence shows the maintainer takes that responsibility seriously.

Rendering fidelity is the headline strength. Because PuppeteerSharp drives a real Chromium instance, HTML, CSS, JavaScript, web fonts, SVG, modern CSS layout primitives, and even WebGL all render the way they would in a browser. For PDF outputs that have to faithfully reflect a complex web-rendered document, this is the highest-fidelity option in the .NET ecosystem. If the input is "the customer-facing HTML page exactly as the customer sees it, exported to PDF," PuppeteerSharp's output will be closer to ground truth than any layout-DSL-based PDF library can achieve.

The API surface is comfortable. The library exposes Puppeteer's familiar primitives (Browser, Page, Frame, BrowserContext) with idiomatic .NET async patterns. Developers coming from Node Puppeteer find PuppeteerSharp instantly readable. The same is true for browser-automation testing scenarios, where PuppeteerSharp earns its place in test suites that need real Chromium behavior. As a browser-automation tool with a side capability of PDF output, PuppeteerSharp is a defensible default.

The license is friendly. PuppeteerSharp is MIT-licensed, with no commercial gating, no revenue threshold, no AGPL viral exposure. For teams burned by license-shaped surprises elsewhere in the .NET PDF ecosystem, this is meaningful on its own.

These strengths are real. They are also the reason teams reach for PuppeteerSharp when they need an HTML-to-PDF pipeline. The production-readiness conversation is not about whether PuppeteerSharp can do the job; it is about what the job costs to keep doing reliably as volume scales.

What the documentation surfaces, and what it implies

PuppeteerSharp's documentation is honest about its model: the library downloads and manages a Chromium binary, then drives that binary via the DevTools Protocol. This is the same model as upstream Puppeteer, and the implications are well understood by anyone who has run headless Chromium in production at scale. The documentation surfaces that there is a Chromium binary. What it leaves to the reader's experience is what living with that Chromium binary means at logistics-scale volume.

Three operational characteristics drive that cost.

The runtime memory baseline is set by Chromium, not by application code. Two figures matter, and they describe different things. First, the baseline of a typical .NET API service before adding any browser-based dependency: roughly 200–400 MB resident memory for a service in steady state, which is the size class teams are sizing their nodes for. Second, the per-Chromium-instance overhead added on top of that baseline once PuppeteerSharp is in the dependency tree.

The cleanest available inference for the per-instance figure comes from production write-ups that report concurrency limits per host. One frequently-cited write-up reports that a 2 GB VPS comfortably hosts ten to twenty concurrent headless instances under typical conditions. Working backward from that envelope (2,048 MB ÷ 10–20 instances, after subtracting an OS and runtime baseline) implies roughly 100–200 MB per Chromium instance as a working estimate at moderate workload, with the explicit caveat that this is a derived figure, not a measured one, and that peak workloads are documented well higher. The upstream Puppeteer issue tracker documents tabular reports of 50,000+ rows consuming all available memory and crashing the renderer, which is the upper end of the variance the per-instance estimate cannot capture.

For a service running a pool of, say, four browser instances behind an autoscaler, the steady-state memory bill is the .NET service baseline plus four times the per-instance overhead, easily a 600–1,200 MB envelope at moderate workload, with peak excursions into the multi-gigabyte range under the kind of large-document workloads logistics generates. A logistics workflow generating large bills-of-lading or multi-page shipment manifests sits in exactly the size class where Chromium's memory profile becomes the dominant operational variable.

The container image carries the browser. PuppeteerSharp ships a Chromium binary at roughly 170MB per platform target, and a typical Debian-based Chromium container image lands in the 380MB range before any application code. For a microservice whose own assembly is a few megabytes, the deployment artifact is functionally a Chromium image with a thin .NET veneer on top. Not a deal-breaker on its own, but it changes the character of the service: registry storage, image-pull latency, autoscaling cold-start time, and CI build time all become Chromium-bound.

Chromium's release cadence becomes part of the security backlog. Google ships Chromium stable updates on a roughly four-week cycle, with critical CVEs typically patched within one to three days. For a service running PuppeteerSharp in production, every Chromium release is a security event the team owns. The audit question "which version of Chromium is the PDF service running, and when was the renderer last patched" is now part of the service's compliance surface. PuppeteerSharp's BrowserFetcher will pull a newer Chromium when asked; deciding when to ask, regression-testing the new version against PDF outputs, and rolling it through the container pipeline is operational work the documentation does not estimate.

None of these costs is concealed. Each is implicit in the architectural choice rather than enumerated in the API reference. That is the difference the production-readiness review is built to surface.

The scaling math

Throughput per instance is dominated by Chromium startup time and memory pressure. Public discussion of Puppeteer in production consistently lands on the same pattern: do not launch a fresh browser per request. The dominant production design pattern in the .NET community is a single long-lived browser instance with a pool of pages reused across requests, with concurrency tuned to roughly cores - 1 per the codepasta optimization writeup, and browsers recycled periodically to bound memory growth. With a warm pool, per-PDF generation latency for moderate documents lands in the hundreds of milliseconds; the same codepasta writeup cites p95 around 365ms for typical documents. Two cold-start measurements are worth distinguishing: AWS Lambda cold-start with the browser already on disk runs around 5 seconds for the first request after a code update, while a fresh BrowserFetcher Chromium download (e.g., on first deployment) is in the 10-second-plus range, and together they explain why every serious deployment runs a warm pool and pre-fetches the binary at image build time, not at runtime.

For a logistics workload with bursty volume (end-of-day manifest generation clearing tens of thousands of documents in a defined window), the architecture that emerges is a constellation of small services each running a browser pool, fronted by an autoscaler, with a job queue feeding work in. That is a workable architecture. It is also not a library decision. It is a small distributed system whose capacity, reliability, and cost the team now owns.

The transitive cost surface includes:

A pool manager with health checks and page recycling, because unbounded browser/page creation leaks memory in well-documented ways.
Container orchestration tuned for the Chromium memory profile, including --disable-dev-shm-usage and shared-memory routing.
Monitoring for zombie Chromium processes, which the upstream community documents as a recurring failure mode.
A patch-and-test pipeline for Chromium versions, integrated with the organization's security cadence.
A regression-test suite for PDF output, because Chromium updates can subtly shift rendering and the diff is the team's problem.

For some teams this is the right tradeoff: HTML-fidelity is non-negotiable, the operational maturity is there, and the volume justifies the investment. For other teams, this is a microservice pattern they did not realize they were signing up for when they ran dotnet add package PuppeteerSharp.

Why MIT-licensed doesn't mean free at production scale

PuppeteerSharp's MIT license is the cleanest in the .NET PDF space, with no copyleft viral exposure, no revenue threshold, and no per-developer fee. For teams burned by license-shaped surprises elsewhere, the licensing question genuinely is one fewer thing to track. The architectural question is whether "MIT-licensed" is the same property as "free," and at logistics-scale production volume, those two properties diverge by enough to matter.

The total cost of operating PuppeteerSharp in production resolves to four line items, none of which appear in a procurement review.

Memory pressure as a managed-code concern. The dominant production design pattern, a long-lived browser instance with a recycled page pool, is partly a workaround for documented bugs rather than a stylistic preference. Issue #640 on the PuppeteerSharp repository documents a managed memory leak in Connection.cs where entries in the internal _callbacks dictionary are never removed across calls, producing OOM under sustained load and most pronounced with large callback payloads. The mitigation in production is to recycle browsers periodically, which means the team is now operating a small fleet of browsers with health checks, page-count caps, and rolling restart logic. That fleet is real engineering work the dependency tree does not bill for.

Deployment ceiling on serverless. AWS Lambda's documented limits are 50 MB zipped for direct upload and 250 MB unzipped for the function plus all layers combined. PuppeteerSharp's Chromium binary, in its default form, sits in the 150-300 MB range depending on platform. Lambda-targeted deployments of PuppeteerSharp exist, but they are a focused engineering effort (stripped Chromium builds, container-image deployment mode, layer architecture), not a dotnet publish that just works. For teams whose deployment target is serverless, "MIT-licensed and works in Lambda" is two separate problems.

Chromium patch ownership. Every Chromium stable release on the roughly four-week cycle becomes a security event the team owns, with PDF-output regression-testing implied. The patch cadence does not slow because PuppeteerSharp is MIT-licensed; it slows when the team builds the pipeline to handle it.

The four-headed operational tax. A team adopting PuppeteerSharp for HTML-to-PDF in production is implicitly committing to a pool manager, a container orchestration tune-up for Chromium memory, monitoring for zombie processes, and a Chromium patch-and-regression pipeline. None of those items have an upfront line item, and a typical estimate of accumulated engineering investment to build them properly runs into the engineer-month range for the first deployment alone.

The MIT license remains a real benefit. It is also, at production scale, a small fraction of the actual cost surface. For workloads where the operational tax is the right tradeoff (fleets that already exist for browser automation, fidelity-critical document rendering), the license is the cleanest answer in the ecosystem. For workloads where the only reason a Chromium fleet exists is PDF generation, MIT does not mean free; it means the bill is paid in engineering time rather than in a license invoice.

When the headless-browser model is the right choice

There are workloads where the headless-browser model is unambiguously the right architecture. If the team is already operating a headless Chromium fleet for browser-automation testing, web scraping, or web-render snapshotting, adding PDF generation to that fleet is a marginal cost. The pool exists, the patch pipeline exists, the monitoring exists. PuppeteerSharp is the natural choice in that environment, because the team is not paying the operational tax for the first time. They are amortizing it across multiple workloads.

Similarly, if the workload requires real browser behavior beyond rendering (JavaScript execution, dynamic content waiting, interactive form filling before capture), a headless browser is doing work no library-based renderer can replicate. PuppeteerSharp's strength as a browser-automation tool is the same strength here, and the PDF output is a side effect of work the browser was going to do anyway.

The review surfaces a problem only when PDF generation is the only reason the headless-browser fleet exists. In that case, the team has implicitly chosen to run a small Chromium service in exchange for a rendering engine they could have had as a library dependency. That is the framing teams who have not done the review are usually missing when they ship.

The decision the review actually asks for

A logistics team evaluating PuppeteerSharp for a high-volume document-generation workload should be able to answer four questions before adopting:

Is HTML-fidelity rendering of customer-shaped documents a hard requirement, or is a layout-DSL output acceptable?
Does the team already operate a headless-browser fleet for other reasons, or will PDF generation be the first one?
Is the team prepared to take ownership of Chromium's patch cadence as part of the service's compliance surface?
As a reasoned hypothetical: what would the year-three security audit conversation look like when the auditor asks which version of Chromium the PDF service is running, and is the team prepared to answer it deliberately?

Answers to one and two leaning toward "fidelity is required, the fleet already exists" point at PuppeteerSharp. Answers leaning toward "library call, not a service" point at a managed library, commercial or otherwise. The honest reading of the .NET PDF ecosystem is that there are good answers in both directions, and the question is which architecture the team is buying.

PuppeteerSharp on .NET 10 LTS, on a managed Chromium pool, with a competent ops team behind it, will generate PDFs in a logistics pipeline reliably. The operational tax is not catastrophic; it is just real, and it does not appear on the API reference page. The work of the production-readiness review is to put it on the page where the architectural decision is being made, before the team is six months into operating a Chromium service they did not realize they had built.

If the four questions above are the first time the team is encountering them, the review has done its job. The answers, and the architecture they imply, are the team's call.

When you want a library call, not a service

PuppeteerSharp's power is a real browser, and its cost is operating one: a 150 to 300 MB Chromium download, memory pressure under load, and a patch-and-monitoring pipeline that turns PDF generation into a service you run. Teams without that operational bandwidth, and serverless shops bumping into Lambda's 250 MB ceiling, often want the rendering engine as an in-process library rather than a managed Chromium fleet.

IronPDF, a commercial library, bundles its engine in the package with no BrowserFetcher step, so HTML-to-PDF stays a library call instead of a Chromium fleet you keep alive.

It documents first-class AWS Lambda deployment, which is exactly where PuppeteerSharp's footprint hurts most. A commercial-library workflow looks like this:

// Install: dotnet add package IronPdf
using IronPdf;

// Initialize the renderer
IronPdf.License.LicenseKey = "YOUR-TRIAL-OR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf("<h1>A library call, not a service</h1>");
pdf.SaveAs("output.pdf");

Pro: an in-process engine with no pool, watchdog, or BrowserFetcher step to operate.
Con: a commercial license, where PuppeteerSharp is MIT and free.
Con: IronPDF also bundles a Chromium engine -- the difference vs PuppeteerSharp is operational management overhead, not binary size.

If the Chromium operational tax is the problem, the no-card 30-day trial key lets you test a serverless function before committing. If your team already runs a headless-browser fleet, PuppeteerSharp is the natural fit and the tax is already paid.

If you run PuppeteerSharp at volume, how are you handling memory, zombie processes, and Chromium patching? What does your pool look like?

DinkToPdf in 2026: Archived Dependency in Your .NET App

IronSoftware — Tue, 09 Jun 2026 16:55:31 +0000

If you've shipped a .NET service that generates PDFs in the last seven or eight years, there's a reasonable chance you reached for DinkToPdf. It was the obvious answer in the early .NET Core era: a NuGet package, a tidy IConverter interface, and an HTML-to-PDF API that worked the first time you called it. The install-day experience really is friction-free. That's the part that's true.

The part that doesn't show up in the install-day experience is the dependency you took underneath it. DinkToPdf is a P/Invoke wrapper. The thing it wraps is wkhtmltopdf, which is software whose upstream GitHub repository was archived on January 2, 2023, with the whole organization archived on July 10, 2024. What you installed when you ran dotnet add package DinkToPdf is a thin .NET surface over a native library that has not received an upstream release since version 0.12.6 in June 2020.

Here's the install-day code that makes the experience feel so good:

using DinkToPdf;
using DinkToPdf.Contracts;

IConverter converter = new SynchronizedConverter(new PdfTools());

byte[] pdf = converter.Convert(new HtmlToPdfDocument
{
    Objects = { new ObjectSettings { HtmlContent = "<h1>Hello, PDF</h1>" } }
});

File.WriteAllBytes("hello.pdf", pdf);

Two using-statements, one converter, one call. That is genuinely a clean .NET API. The reason DinkToPdf got popular is right there in those eight lines.

What DinkToPdf Actually Does Well

Before the dependency chain, the library deserves its due, because it earned the adoption it got. There are real reasons this was the default choice in 2017–2020 .NET Core projects, and several of those reasons still hold up today on their own terms.

The .NET API is well-designed. The IConverter interface, the SynchronizedConverter for thread-safety, the HtmlToPdfDocument model, the ObjectSettings and GlobalSettings separation: these are idiomatic .NET. Whoever wrote this knew the platform. The DI-friendly registration pattern (services.AddSingleton(typeof(IConverter), new SynchronizedConverter(new PdfTools()))) drops cleanly into ASP.NET Core's container. For teams writing greenfield .NET Core code in 2018, the API shape was a real upgrade over the older Process.Start-the-CLI patterns that wkhtmltopdf wrappers had used in the .NET Framework era.

The first PDF lands fast. The eight-line example above is not pedagogical simplification. That really is the entire setup ceremony, once you've copied the native binary into your output directory. For a developer with a deadline, the speed-to-first-result is meaningful.

The HTML-rendering capability covers a lot of ground. Because wkhtmltopdf wraps QtWebKit, you get a real (if dated) browser engine doing the layout. That covers most static HTML reports, invoice templates, statement formats, the whole "render this Razor view as a PDF" workflow that probably accounts for the majority of HTML-to-PDF use cases in line-of-business .NET applications. CSS works. Images work. Reasonable typography works.

The community knowledge base is large. Because DinkToPdf was popular for several years, there are answers on Stack Overflow for most of the gotchas. Threading patterns, container deployment recipes, the useCmaps flag, font-loading on Linux, the various --page-size and --margin-* flag mappings: all of it has been written down by someone. For a team taking the dependency in 2026, that institutional memory is part of what they're inheriting along with the library itself.

So the product is real. The API is good. The friction is low. None of what follows is intended to argue otherwise. The question worth walking through is what is on the other side of the P/Invoke boundary, because that is the half of the picture the install-day experience never shows you.

The Dependency Chain You Actually Took

Here is the literal dependency graph for a service using DinkToPdf:

Your ASP.NET Core service
        │
        ▼
DinkToPdf 1.0.8  ← .NET wrapper, last NuGet release April 2017
        │
        │ P/Invoke (DllImport on libwkhtmltox.{dll,so,dylib})
        ▼
wkhtmltox native library v0.12.4
   (shipped in the DinkToPdf repo under /v0.12.4/)
        │
        ▼
wkhtmltopdf 0.12.x
   (upstream repo archived 2023-01-02; last release 0.12.6, June 2020)
        │
        ▼
QtWebKit (Qt 4 fork)
   (QtWebKit deprecated by Qt in 2015; Qt 4 unsupported since 2015)
        │
        ▼
WebKit (the rendering engine)
   (the wkhtmltopdf-bundled WebKit fork has not been updated since ~2012,
    per the wkhtmltopdf project's own status page)

Five layers. The .NET package you reference in your .csproj is the top one. The bottom four came along for free, and the bottom three of them are software that the open-source world stopped maintaining at various points between 2012 and 2024. Two specific things are worth pointing out about this graph.

First: the native binary the DinkToPdf repo distributes is wkhtmltox v0.12.4. That is one minor version behind the final wkhtmltopdf release of 0.12.6. The DinkToPdf README still points users to the v0.12.4 folder for the binary, so the most-installed configuration of DinkToPdf in the wild is running a wkhtmltopdf binary that is slightly older than the last upstream release of an already-archived project.

Second: the wkhtmltopdf project's own status page, written by the maintainer before the repo was archived, was already explicit that "Qt 4 (which wkhtmltopdf uses) hasn't been supported since 2015, the WebKit in it hasn't been updated since 2012." That status page also recommends, in its own words, that users not pass untrusted HTML to wkhtmltopdf without sanitization, and points at WeasyPrint, Prince, or Puppeteer as alternatives for new projects. That recommendation was written by the people who knew the codebase best.

The dependency chain is not a secret. The DinkToPdf README mentions wkhtmltopdf in its first sentence. The wkhtmltopdf README links to the status page. Nothing here is being concealed. The documentation stops short of the implication: when you take DinkToPdf, the code you are actually relying on for the rendering work is upstream of the .NET wrapper, and that upstream has an archive flag on it.

Why "DinkToPdf vs wkhtmltopdf" Is a Distinction Without a Difference

A common framing in 2026 production-readiness discussions is "we're not using wkhtmltopdf, we're using DinkToPdf, which is a .NET library." That framing makes the question feel like a .NET ecosystem question rather than an upstream-archive question. It isn't.

DinkToPdf is the wrapper. wkhtmltopdf is the engine. The PDF that gets written to disk is rendered by the engine, not the wrapper. Any rendering bug, any CSS support gap, any font-handling quirk, any security-relevant issue in QtWebKit's WebKit-from-2012 origin: all of those live downstream of the wrapper, in code the wrapper has no ability to fix because the upstream is not accepting changes.

Consider what "still maintained" would have to mean for this stack to behave like a maintained dependency:

A new CSS feature would need wkhtmltopdf to ship a release. wkhtmltopdf's last release was June 10, 2020. The repo archive flag means there will not be another one without a fork takeover.
A WebKit-derived security advisory would need a patched wkhtmltopdf binary. The WebKit version inside QtWebKit-inside-wkhtmltopdf hasn't been touched in the upstream sense since approximately 2012.
A .NET wrapper bug fix would require DinkToPdf to ship a release. DinkToPdf's last NuGet release was 1.0.8 in April 2017. The GitHub repository still receives issue traffic in 2026, but no published package update has shipped in nine years.

The forks that exist (Haukcode.DinkToPdf, the various WkHtmlToPdf-DotNet community packages) modernize the .NET wrapper meaningfully, and credit to those maintainers for the work. But none of them can fix the rendering engine. The thing the wrapper wraps is the thing that does the work, and that thing is archived. For a production decision in 2026, "DinkToPdf" and "wkhtmltopdf" are operationally the same dependency wearing two different labels.

The inherited abandonment: free until it costs you

There is a gap between "free to install" and "free to operate," and DinkToPdf sits squarely inside it. The DinkToPdf NuGet package is MIT-licensed, costs nothing, and clears procurement review without a conversation. What the procurement review does not surface is the cost of operating a dependency whose .NET wrapper has not shipped a release since April 2017 and whose rendering engine has been archived by its maintainer since 2023.

The cost shows up in three places, and none of them are theoretical.

First, deployment friction. The DinkToPdf GitHub issue tracker carries a long-running pattern of native-binary-loading failures in container environments. Issue #116 documents Unable to load shared library 'libwkhtmltox' on Alpine Linux Docker images on .NET Core 3.1, the musl-versus-glibc mismatch that Alpine-based deployments routinely hit. Issue #138 reports the same DllNotFoundException from container deployments more generally. Both issues are open or closed-as-stale; neither has been resolved in the published NuGet package because the published NuGet package has not changed since 2017. Teams running modern .NET on slim Linux containers, which is most teams in 2026, pay for this in deployment-day debugging and in CI flakiness that the dependency's install-day experience never previewed.

Second, compliance exposure. A SOC 2 auditor, a SOC 2 customer questionnaire, or an enterprise security review will note the nine-year gap in DinkToPdf's release history. The wrapper carries the archived rendering engine into the dependency tree. CVE-2022-35583 (CVSS 9.8) and CVE-2020-21365 sit downstream of every DinkToPdf install with no patch path. For commercial workloads subject to vulnerability-management standards, "we use the wrapper, not the engine" is not a defense that survives the auditor's enumeration of the transitively-loaded native libraries.

Third, opportunity cost. Every quarter a team spends maintaining DinkToPdf in production (porting around the Alpine issue, isolating the network egress, documenting the compensating controls, justifying the dependency to the next reviewer) is a quarter not spent on the product. The wrapper was free in 2017. It is not free in 2026; it has simply moved the bill from a license line item to an engineering-time line item.

The honest framing for a 2026 commercial adoption is that DinkToPdf is no longer recommended for new projects, and the active community forks (Haukcode.DinkToPdf, the various WkHtmlToPdf-DotNet packages) do not change this conclusion because none of them can fix the engine. For teams carrying an existing DinkToPdf dependency, the migration is genuinely defensible work even when the renders themselves still produce acceptable output.

When DinkToPdf Is Still Fine

DinkToPdf is still a reasonable choice in specific cases in 2026. The dependency-chain story does not turn it into a bad library. It turns it into a library with a clearly bounded fitness window.

DinkToPdf is fine for:

Internal tools that render trusted HTML you control end-to-end
Batch jobs running on infrastructure you patch yourself
Prototypes where the proof-of-concept matters more than the production posture
Existing services where the renders work and the migration cost would be larger than the value of moving.

None of those use cases is invalidated by anything in this article.

DinkToPdf becomes a harder sell for:

Services that render HTML originating from outside the trust boundary (the wkhtmltopdf status page's own recommendation is to not do this without sanitization)
Services subject to vulnerability-management standards where the dependency tree gets enumerated at audit time
Services running on .NET 10 LTS where the multi-year support window outlives the practical viability of an archived rendering engine
Any greenfield project where the dependency choice is being made today rather than carried forward.

The line is whether your project sits on the side of that boundary where the upstream-archive question matters, rather than a blanket "use this" or "don't."

So What Do You Do With This?

Here is the question worth taking away. Open your .csproj and look at your DinkToPdf reference. Ask the question the documentation didn't ask for you: do you know what's downstream of that line? Do you know what version of the native binary is in your output directory? Do you know when that binary was last built? Do you know whether your security team, the next time they enumerate your container image's dependencies, is going to ask why an archived project is doing the rendering work in your service?

If the answer to all of those is yes and the trade-off is acceptable, that is a real decision. The aim here is to replace a vibe with a graph you can check yourself, dates and links included, rather than to talk anyone out of DinkToPdf.

The library is fine. The wrapper is clean. The dependency chain is the part worth looking at. What does yours look like, and when did you last actually look at it?

A maintained, deployment-friendly alternative

DinkToPdf's cost shows up at deployment. It P/Invokes a native wkhtmltopdf binary that is archived upstream, and the "works on Windows, breaks on Alpine" native-loading failures are a recurring tax on teams shipping to Linux containers.

IronPDF, a commercial library, runs as a managed .NET package. IronPDF handles the native binary extraction automatically, so teams don't need to manually manage per-platform binary placement the way DinkToPdf requires.

It auto-configures its Linux and Docker dependencies, turning deployment into a NuGet reference rather than a P/Invoke binary you copy per target. A commercial-library workflow looks like this:

// Install: dotnet add package IronPdf
using IronPdf;

// Managed package; the engine and its Linux deps come with it
IronPdf.License.LicenseKey = "YOUR-TRIAL-OR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf("<h1>Managed package; dependencies auto-configured</h1>");
pdf.SaveAs("output.pdf");

Pro: automatic dependency management and a maintained engine, where DinkToPdf wraps an archived one.
Con: a commercial license, where DinkToPdf is MIT and free.
Con: the bundled Chromium engine substantially increases image size compared to wkhtmltopdf/DinkToPdf.

If "works on Windows, breaks on Alpine" is your recurring tax, the 30-day trial, no credit card lets you validate a Linux container build first. For an internal tool on trusted HTML where the renders already work, DinkToPdf can stay until the migration is worth it.

Have you hit the Alpine/musl native-loading failure with DinkToPdf, or are your renders still fine? What did you decide to do about the archived engine?