DEV Community: IronSoftware

# DevExpress Reporting Alternative for .NET: Skip the Drag-and-Drop Designer (2026)

IronSoftware — Tue, 21 Jul 2026 00:33:06 +0000

One question keeps landing in our inbox at Iron Software: "We use DevExpress Reporting, but our PDFs get generated on a headless server and nobody opens the visual designer anymore. Is there something lighter?"

Full disclosure: we work on IronPDF at Iron Software, so we're clearly not neutral here. IronPDF comes up constantly as a DevExpress Reporting alternative for .NET, but it's not a drop-in replacement. The two tools solve overlapping problems from opposite directions.

Here's our honest take: if business users design your reports in a banded designer, DevExpress is hard to beat. If your reports are really HTML and CSS that happen to end up as a PDF on a server, a code-first library like IronPDF can feel like taking off a heavy backpack.

Here's our entire IronPDF version of generating a PDF report, so you can see the shape of it before we go further:

// dotnet add package IronPdf
using IronPdf;

var renderer = new ChromePdfRenderer();
PdfDocument report = renderer.RenderHtmlAsPdf(
    "<h1>Q3 Revenue Report</h1><p>Generated on the server, no designer required.</p>");
report.SaveAs("q3-report.pdf");

That's the whole program. No report definition file, no viewer control, no designer to open. Whether that's a relief or a red flag depends entirely on how your team builds reports, so let's unpack that.

Two Tools, One Word Called Reporting

The word reporting hides the real decision here. Both tools end with a PDF, but they start from different places.

DevExpress Reporting, built on XtraReports, is a full reporting platform. You lay out reports in a visual, banded designer inside Visual Studio, bind them to data through SQL, Entity Framework, XPO, JSON, or XML, and the SkiaSharp engine renders the result. It even ships an embeddable End-User Report Designer so business users can build their own reports at runtime.

IronPDF isn't a reporting platform; it's a programmatic PDF library. No designer, no report definition format. Your layout language is HTML, CSS, and JavaScript, rendered through Chromium, the same engine behind Chrome. We build the markup however we like (Razor, a template engine, plain strings) and IronPDF turns it into a PDF.

DevExpress Reporting vs IronPDF at a Glance

Before the code, here's our head-to-head. We've tried to keep each row honest rather than flattering:

Dimension	DevExpress Reporting (XtraReports)	IronPDF
Authoring model	Visual banded report designer + code	HTML, CSS, JavaScript (+ Razor/Blazor)
Rendering engine	SkiaSharp document engine	Chromium (Chrome)
End-user / ad-hoc designer	Yes, embeddable at runtime	No
Built-in data binding	Yes (SQL, EF, XPO, JSON, XML)	You bind in your own code
Licensing	Per-developer annual subscription	Perpetual, per-developer
Ideal use case	User-designed, multi-format enterprise reports	Code-driven, HTML-templated PDFs

Table 1: A capability comparison, not a scoreboard. The "ideal use case" row matters more than any single feature row.

The Same Report, Two Ways

Let's look at the same task (a data-bound invoice exported to PDF on the server) in both tools.

With DevExpress, the layout already exists as a report class built in the designer. The code just binds data and exports:

// DevExpress: export a pre-designed XtraReport to PDF on the server
using DevExpress.XtraReports.UI;
using System.IO;

var report = new InvoiceReport();   // class generated from your .repx banded layout
report.DataSource = invoiceData;    // bind the data
report.CreateDocument();            // build the document tree

using var stream = new MemoryStream();
report.ExportToPdf(stream);         // render to PDF bytes
File.WriteAllBytes("invoice.pdf", stream.ToArray());

InvoiceReport carries the layout drawn visually. ExportToPdf (and the async ExportToPdfAsync) render it, and PdfExportOptions customizes the output, all covered in DevExpress's export-to-PDF documentation. The strength is obvious: the layout, banding, and grouping came from a designer, not code. The cost: that layout lives in a proprietary .repx file only DevExpress tooling understands.

With IronPDF, the layout is HTML we generate, and the renderer does the rest:

using IronPdf;

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

string html = InvoiceTemplate.Build(invoiceData); // your own templating: Razor, interpolation, etc.
PdfDocument pdf = renderer.RenderHtmlAsPdf(html);
pdf.SaveAs("invoice.pdf");

ChromePdfRenderer runs the Chromium engine, so CSS Grid, Flexbox, web fonts, and JavaScript-drawn charts render exactly as they do in the browser. Data binding, though, is on you: you write the HTML. That's the trade: less structure handed to you, more freedom over the output. The C# PDF reports how-to walks through headers, footers, and page breaks if you want more detail.

Where DevExpress Reporting Still Wins

We won't pretend IronPDF wins every scenario. Here are real cases where we'd point you toward DevExpress Reporting, even though it competes with us:

Business users design the reports. The visual banded designer and embeddable End-User Report Designer are differentiators HTML can't match.
One definition, many formats. DevExpress exports the same report to PDF, DOCX, XLSX, RTF, CSV, and images. IronPDF is PDF-only.
You want an in-app viewer. DevExpress ships interactive viewer controls with print preview and parameter panels; IronPDF only generates files.

If two or more of those describe your project, stick with DevExpress. We'd rather send you down the right path than force a migration that fights your requirements.

Where IronPDF Pulls Ahead

Plenty of the reporting we see isn't interactive at all: it's a scheduled job or an API endpoint turning data into a PDF nobody designs by hand. For that pattern:

Your layout language is the web. If your team already knows HTML and CSS, you reuse your existing design system instead of learning banded-layout concepts, and there's no designer to license separately, no .repx to version-control.
Chromium fidelity. What renders in Chrome renders in the PDF: modern CSS, custom fonts, SVG, JavaScript charts. The HTML-to-PDF tutorial covers the rendering options.
Cross-platform without ceremony. IronPDF runs on Linux and in containers, and a recent release cut the Docker image size by roughly 60 percent, worth knowing if you deploy to Docker or a cloud function.

We also like that IronPDF ships monthly: recent versions added PDF/UA-2 accessibility and PDF/A-4 archival compliance, active investment worth checking before you bet a production pipeline on a dependency.

Migrating from XtraReports? Here's the Map

The API swap itself is small: report.ExportToPdf(path) becomes renderer.RenderHtmlAsPdf(html).SaveAs(path), ExportToPdfAsync becomes await renderer.RenderHtmlAsPdfAsync(html), and XRPageInfo page numbers become {page} / {total-pages} placeholders in RenderingOptions. The real work is re-expressing banded layouts and report.DataSource bindings as HTML and template loops.

Invoices and summary reports translate in an afternoon. Heavily banded reports with subreports and cross-tabs take longer. Those concepts don't have a one-line HTML equivalent. On .NET 10, the current LTS, the same ChromePdfRenderer code runs whether you call it from a minimal API or a full MVC controller.

Licensing: Subscription vs Perpetual

Licensing is where the two models diverge most, and we'd encourage you to run the numbers for your own team size before committing either way.

DevExpress Reporting is licensed per developer as an annual subscription. At the time of writing, the standalone Reporting subscription runs around $783.99 per developer per year through resellers, and the broader Universal subscription (600-plus UI controls) is around $2,253.99 per developer per year, with renewals near half the first-year price.

IronPDF uses perpetual, per-developer licensing instead: each tier is a one-time purchase with a 30-day trial, and you own the version you buy. Current tiers are on the IronPDF licensing page.

A subscription keeps you current but never stops charging; a perpetual license is a bigger one-time outlay you own outright. We've seen it cost less over three to four years for a small, stable team, while a team wanting continuous updates across a large control suite may prefer the subscription. Numbers change, so confirm current pricing with each vendor.

Wrapping Up

DevExpress Reporting and IronPDF aren't really competitors so much as tools built for different definitions of reporting. If a human designs the report, DevExpress earns its subscription. If code generates it from HTML, IronPDF removes a lot of weight, licensing cost included. Plenty of teams run both: DevExpress for interactive, user-designed reports, IronPDF for the server-side jobs nobody opens a designer for.

If your reports have quietly become HTML behind a server endpoint, prototype the move. Grab the 30-day trial, install the package, point ChromePdfRenderer at one of your existing templates, and see how close the output lands on the first try.

What's your experience: are your reports still designed interactively, or have they quietly turned into HTML behind an API? Tell us in the comments.

DevExpress and XtraReports are trademarks of Developer Express Inc. We're not affiliated with DevExpress; the facts about their products above come from their own public documentation as of this writing.

Telerik Reporting Alternative: Code-First PDFs in .NET

IronSoftware — Mon, 20 Jul 2026 22:28:17 +0000

We keep hearing a version of the same question from .NET teams: the Telerik Reporting renewal is coming up, and most of what the team actually needs is to turn this data into a clean PDF. Is there something simpler?

Full disclosure: we work on IronPDF at Iron Software. We'll be upfront about where our tool wins and where Telerik Reporting still wins.

Here's our honest take up front: IronPDF is a strong alternative when your reports can be expressed as HTML and CSS and you want code-first control. It's not a drop-in clone. Telerik Reporting is a visual, banded report platform; IronPDF is an HTML-to-PDF engine. Once that distinction clicks, the decision gets a lot easier.

Here's the whole "hello, report" example. One NuGet package is the entire dependency:

// Program.cs (.NET 10, top-level statements)
using IronPdf;

License.LicenseKey = "YOUR-LICENSE-KEY"; // a free 30-day trial key works here

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf("<h1>Q3 Sales Report</h1><p>Generated with IronPDF.</p>");
pdf.SaveAs("report.pdf");

ChromePdfRenderer spins up an embedded Chromium engine and renders that markup the way a browser would. No report server, no designer file, no viewer runtime. That's the trade you're evaluating, so let's break it down.

We've walked plenty of teams through this exact evaluation, and it almost always comes down to one question: is your report really a document, or does it need to stay interactive?

Why Teams Go Looking for an Alternative

Most teams don't leave Telerik Reporting because it's bad. They leave because of fit. Telerik Reporting is a feature-complete embedded reporting suite, and it carries the weight of one. Here's what our conversations with developers turn up most often:

Licensing and bundling. Telerik Reporting starts around $499 per developer per year, often bundled inside the larger DevCraft suite. If reporting is the only piece you use, you're paying for a lot of product you don't touch.
The banded-designer model. Telerik's power comes from WYSIWYG designers and .trdp/.trdx definition files, great for report specialists and end-user self-service but friction for a team that lives in source control and CI/CD, where a binary report definition is hard to diff and test.
Legacy surface area. The engine grew up in the Windows Forms and Web Forms era and has been extended forward to ASP.NET Core and Blazor, which means viewers, REST report services, and designer tooling to deploy and version.

None of that makes Telerik the wrong choice. It makes it a heavy choice for teams whose real requirement is a clean PDF. That's the gap IronPDF fills.

Telerik Reporting vs. IronPDF at a Glance

We've tried to keep this table fair: notice how many rows Telerik wins.F

Capability	Telerik Reporting	IronPDF
Report authoring model	Visual banded designers	Code + HTML / CSS / Razor
End-user self-service authoring	Yes (Web Report Designer)	No
Interactive report viewer	Yes (drill-down, sort, parameters)	No, outputs a static PDF
HTML / CSS / JS rendering fidelity	Limited	Chromium-accurate
Export formats	PDF, Excel, Word, PPT, CSV, RTF, images	PDF (plus raster images)
PDF manipulation (merge, sign, PDF/A, PDF/UA)	Basic	Extensive
Deployment footprint	Engine + optional REST service + viewers	Single NuGet package
Cross-platform (Linux / Docker / macOS)	Partial	Full
Licensing	From ~$499/yr per dev, royalty-free	Perpetual, per developer, royalty-free

Telerik leads on authoring and export breadth; IronPDF leads on rendering fidelity, PDF control, and deployment.

What Telerik Reporting Still Does Well

We'd be doing you a disservice if we glossed over this: there are jobs where Telerik Reporting is the better answer.

Its three WYSIWYG designers (Visual Studio, standalone desktop, and web) let non-developers build and adjust reports, self-service that an HTML-to-PDF library doesn't offer. The Report Viewer controls are the other big win: interactive viewers across HTML5, ASP.NET Core, Blazor, Angular, React, WPF, and WinForms, complete with drill-down, sorting, and parameter prompts. One report definition can export to PDF, Excel, Word, PowerPoint, CSV, RTF, and images.

If your business analysts author their own reports, or you need an in-app interactive viewer, keep Telerik. That's a genuine platform need IronPDF doesn't cover.

Where IronPDF Fits Better

IronPDF wins when your report is really a document, and you'd rather build it with the web skills your team already has. We see this pattern constantly: an invoice, a statement, or a compliance packet that was forced into a banded designer when it was a web page all along.

Because ChromePdfRenderer is Chromium under the hood, your report is styled with the same HTML5, CSS3, and JavaScript a browser uses: Flexbox, Grid, web fonts, SVG charts, print media queries. You can reuse an existing invoice or dashboard template instead of rebuilding it in a proprietary designer.

Everything is code, so everything is testable and diffable. Your template lives in the repo, goes through code review, and runs in CI. Deployment is a single NuGet package (no report server, no viewer runtime), and it runs the same on Windows, Linux, macOS, Docker, and Azure.

IronPDF is also a full PDF toolkit, not just a renderer: merge and split documents, add headers/footers/watermarks, fill forms, digitally sign (including HSM tokens as of the late-2025 releases), and produce PDF/A and PDF/UA compliant output.

Here's the gotcha to know up front: IronPDF has no visual designer, no end-user self-service authoring, and no interactive viewer. It produces a finished PDF, full stop. Its export is PDF-first; for native Excel or Word output, that's a job for IronXL or IronWord, not IronPDF.

A Real Report in C#

Enough theory. Here's a data-driven report with a running footer and automatic page numbers, the banded-report feature people worry about losing:

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

// rows would come from EF Core, Dapper, or any data layer you already have
var rows = new[]
{
    new { Product = "Wireless Mouse",      Units = 1240, Revenue = 30_876.00m },
    new { Product = "Mechanical Keyboard", Units = 860,  Revenue = 51_540.00m },
    new { Product = "USB-C Hub",           Units = 2110, Revenue = 42_411.00m },
};

var body = new StringBuilder(
    "<h1>Quarterly Sales</h1>" +
    "<table><thead><tr><th>Product</th><th>Units</th><th>Revenue</th></tr></thead><tbody>");

foreach (var r in rows)
    body.Append($"<tr><td>{r.Product}</td><td>{r.Units:N0}</td><td>{r.Revenue:C}</td></tr>");

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

var renderer = new ChromePdfRenderer();

renderer.RenderingOptions.TextFooter = new TextHeaderFooter
{
    LeftText        = "Confidential - Contoso Ltd.",
    RightText       = "Page {page} of {total-pages}",
    DrawDividerLine = true
};
renderer.RenderingOptions.MarginTop = 20;
renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;

var pdf = renderer.RenderHtmlAsPdf(body.ToString());
pdf.SaveAs("quarterly-sales.pdf");

TextHeaderFooter gives you the running header/footer band; {page} and {total-pages} are resolved per page at render time, so pagination is handled for you. For richer layouts, swap TextFooter for HtmlFooter (an HtmlHeaderFooter) and use full markup. The C# PDF reports guide and headers and footers how-to go deeper on both.

Migrating From Telerik Reporting

A migration is mostly a translation exercise: most Telerik concepts have an IronPDF equivalent that lives in a different place.

Visual report definition (.trdp/.trdx) → HTML/CSS or Razor template in your project
Report band (page header/footer) → TextHeader/HtmlHeader + CSS @page rules
ObjectDataSource/SqlDataSource → your existing EF Core/Dapper query feeding the template
ReportProcessor.RenderReport("PDF", ...) → ChromePdfRenderer.RenderHtmlAsPdf(...)
Report Viewer control → serve pdf.BinaryData (or embed a JS PDF viewer)
Export to Excel/Word → IronXL/IronWord (separate libraries)

The server-side render is the part people expect to be hard. In IronPDF, the "definition" is your template method, and the render is one call. Here it is as a minimal API endpoint that streams the PDF back, the job the Report Viewer used to do:

// ASP.NET Core minimal API (.NET 10)
app.MapGet("/reports/sales/{quarter}", (string quarter) =>
{
    var html = SalesReportTemplate.Build(quarter); // your template + data query
    var pdf  = new ChromePdfRenderer().RenderHtmlAsPdf(html);
    return Results.File(pdf.BinaryData, "application/pdf", $"sales-{quarter}.pdf");
});

pdf.BinaryData is the rendered byte[], so returning it from a controller, a Blazor endpoint, or a background job is trivial. Report parameters become ordinary method arguments. If your Telerik reports were CSHTML-adjacent already, IronPDF's Razor and MVC rendering lets you render views directly. The one part with no automatic equivalent is multi-format export; plan to route Excel and Word output to IronXL and IronWord.

Licensing, in Plain Terms

Telerik Reporting is royalty-free and starts near $499 per developer per year, with unlimited application and server deployment. That's predictable, and it scales cleanly with team size, though it recurs and is frequently bundled inside DevCraft.

IronPDF uses a perpetual, per-developer license instead of a per-seat subscription: a one-time purchase with a fully functional 30-day free trial and free use during development. Deployment to your own test, staging, and production servers is included; redistributing IronPDF inside a product you ship to third parties uses a separate OEM add-on. Check current tiers on the IronPDF licensing page.

Which Should You Choose?

Choose Telerik Reporting if non-developers author reports, you need an interactive in-app viewer with drill-down and parameters, or one definition must export to Excel, Word, and PowerPoint as well as PDF.

Choose IronPDF if your reports are documents, you'd rather build them in HTML/CSS/Razor and keep everything in source control, you deploy to Linux, Docker, or Azure, or you want deep PDF manipulation from a single package.

Our advice, distilled: don't migrate a platform to a library and expect feature parity. Migrate the reports that are really documents, and you'll wonder why they ever needed more.

What's the report in your app that's secretly just a PDF waiting to happen? Tell us what you're migrating in the comments.

QRCoder Alternatives for C#: When Generation Isn't Enough

IronSoftware — Tue, 14 Jul 2026 04:20:26 +0000

The first time I reached for QRCoder, I had a QR code saved to disk inside of five minutes. A payment link, encoded, rendered, done. It is free under the MIT license, the core has no external dependencies, and it turns a string into a clean QR code in a handful of lines. If the job is purely to generate QR codes, nothing heavier is needed. That is worth saying plainly up front, because most "alternatives" articles cannot bring themselves to admit the incumbent is good. QRCoder is good.

Full transparency: I am a developer advocate at Iron Software, and IronBarcode is one of the options below. The others are free libraries we do not sell. Having shipped barcode reading into systems that scanned thousands of times a day, I have watched the exact moment a QRCoder-only setup hits its ceiling, and that moment is what this article is about.

QRCoder: free, focused, and genuinely enough

One package, no imaging dependency to wire up:

Install-Package QRCoder

using QRCoder;

// PngByteQRCode avoids any System.Drawing dependency, so this runs anywhere.
using var generator = new QRCodeGenerator();
QRCodeData data = generator.CreateQrCode("https://example.com/order/12345", QRCodeGenerator.ECCLevel.Q);

using var qrCode = new PngByteQRCode(data);
byte[] png = qrCode.GetGraphic(20);
File.WriteAllBytes("order-qr.png", png);

That writes a scannable order-qr.png to disk. Short, dependency-light, free.

The honest limit is scope, and it is a design decision rather than a flaw. QRCoder generates QR codes and nothing else. Reading and decoding are out. So are 1D barcodes like Code 128 or EAN-13, which live in a different symbology family entirely. And it has no concept of pulling a code out of a scanned PDF or a noisy camera frame.

That is fine until a feature request crosses one of those lines, and the request almost always arrives in one of three flavors:

"Now we need to scan the codes back in."
"The warehouse team also uses linear barcodes."
"The invoices arrive as PDFs. Can we read the barcode off those?"

ZXing.Net: the free reader and writer

When generation-only stops being enough, ZXing.Net is the usual next step. It is the .NET port of the long-running Java "Zebra Crossing" project, Apache 2.0 licensed, and unlike QRCoder it goes both directions.

The symbology coverage is genuinely broad: UPC-A, UPC-E, EAN-8, EAN-13, Code 39, Code 93, Code 128, ITF, Codabar, MSI, RSS-14, QR Code, Data Matrix, Aztec, and PDF-417. One free library covering 1D, 2D, generation, and scanning is what pulls people off QRCoder.

using ZXing;
using ZXing.Windows.Compatibility;

// The core package has no imaging binding, so BarcodeReader comes from a companion package.
var reader = new BarcodeReader
{
    Options = new ZXing.Common.DecodingOptions { TryHarder = true }
};

using var bitmap = (System.Drawing.Bitmap)System.Drawing.Image.FromFile("order-qr.png");
Result result = reader.Decode(bitmap);

Console.WriteLine(result?.Text ?? "No barcode found.");

That prints the decoded string, or a miss. Note the second using line: it is the whole trade-off in one import.

ZXing.Net's core is pixel-oriented. Binding it to an actual image file means pulling in a companion package (System.Drawing, ImageSharp, SkiaSharp, or OpenCvSharp) and writing the glue that turns a file or stream into the luminance source the decoder expects. It works, and it works well, but the plumbing, the preprocessing, and the platform-specific bindings all become yours. On more than one project that glue has quietly grown into its own subsystem, complete with its own bugs around image rotation and contrast. Budget for that, and ZXing.Net is a strong choice.

SkiaSharp: styling, not scope

A lighter route leaves QRCoder in place and simply dresses it up. QRCoder hands back a raw bitmap or an SVG, and pairing it with SkiaSharp allows compositing, resizing, recoloring, or stamping a logo before saving. Dedicated barcode libraries expose the same idea through built-in styling APIs, but here the drawing stack does the work.

This is the lowest-effort option, and the right one when the requirement is purely cosmetic: a branded code on a landing page, an SVG that scales for print.

⚠️ Trap: System.Drawing.Common is Windows-only on modern .NET, so a cross-platform project gets pushed toward SkiaSharp whether it planned to or not.

What styling does not do is move QRCoder's boundary. A drawing library can style an image but cannot decode one, it knows nothing about 1D symbologies, and it has no notion of error correction. The styling is real. The scope is unchanged.

Cloud barcode APIs: convenient until they aren't

Hosted services move the work off the machine entirely. An endpoint takes an uploaded image and returns the decoded value as JSON. No native dependency to manage, no decoding engine to keep current, and for a low-volume feature inside a bigger workflow that convenience can genuinely outweigh everything else.

The costs are worth listing without flinching. Every scan is a network round trip, which adds latency and rules out offline use. Image data leaves the application boundary, which is disqualifying for documents under privacy or regulatory constraints. And pricing is per call, so a high-throughput pipeline that was free with QRCoder becomes a recurring line item. Cloud APIs fit sporadic, online, non-sensitive workloads. They fit batch-processing confidential files very badly.

IronBarcode: one library for the whole lifecycle

Between "free but generation-only" and "outsource it to a cloud" sits a commercial in-process library covering the whole lifecycle. IronBarcode targets the requests that send people away from QRCoder in the first place.

using IronBarCode;

// Generate: one line, no imaging binding to configure.
QRCodeWriter.CreateQrCode("https://example.com/order/12345", 400).SaveAsPng("order-qr.png");

// Read straight out of a PDF: the case a QRCoder-only stack has no answer for.
BarcodeResults results = BarcodeReader.ReadPdf("scanned-invoice.pdf");

foreach (BarcodeResult barcode in results)
{
    Console.WriteLine($"{barcode.BarcodeType}: {barcode.Value}");
}

That writes a PNG, then prints the type and value of every code found across the PDF's pages. The detail worth noticing is BarcodeReader.ReadPdf sitting two lines under QRCodeWriter.CreateQrCode: same namespace, both directions, and reading from a PDF is the same entry point that handles images and streams, not a bolt-on.

It also ships fault tolerance and image correction for skewed or low-quality scans, instead of handing preprocessing back to the caller.

For a project where QR is the product rather than one symbology among many, IronQR goes deeper on styling and detection than a general barcode library does.

The honest caveat: IronBarcode is commercial, while QRCoder and ZXing.Net are free. What is being bought is the elimination of integration work, not the ability to draw a QR code, because QRCoder does that for nothing. If that integration work is not part of the problem, this is not the tool.

How they compare

Five options blur together fast, so here they are side by side. The row that ends most of these decisions is not "generate," it is "read from PDF."

	QRCoder	ZXing.Net	SkiaSharp	Cloud API	IronBarcode
Generate QR	Yes	Yes	Styling only	Yes	Yes
Read / decode QR	No	Yes	No	Yes	Yes
1D barcodes	No	Yes	No	Varies	Yes
Read from PDF	No	Manual rasterize	No	Varies	Built in
Image correction	No	Bring your own	No	Server-side	Built in
Imaging binding needed	No	Yes	N/A	No	No
Works offline	Yes	Yes	Yes	No	Yes
License	MIT	Apache 2.0	MIT	Per call	Commercial

So which one should you pick?

Match the tool to the scope of the job, not to an imaginary "best library" ranking.

Only generating QR codes. Stay on QRCoder. Free, MIT-licensed, dependency-light, proven. Add SkiaSharp for branding and there is never a reason to leave the open-source world.
Also decoding, or handling 1D barcodes. ZXing.Net is the established free option, as long as the team is comfortable wiring up an imaging binding and owning the preprocessing.
Infrequent scans, always online, non-sensitive images. A cloud API is worth a look.
Reading barcodes out of PDFs, fixing imperfect scans, or covering 1D and 2D in one supported .NET API without assembling the pieces: that is the gap a dedicated library is built to close.

QRCoder did not lose this comparison. It answers one question extremely well, and the moment a project asks a second question, the options above are what is actually on the table.

So what tipped it for you? I am curious how the room splits between teams who stayed on QRCoder and bolted an imaging binding onto ZXing.Net, and teams who gave up and bought the PDF path. Those seem to be the two real routes, and I have never seen a good count of which one wins.

If your second question is "can it read this PDF," IronBarcode has a free trial so you can point it at your own documents first. Run it against the messy files, not the clean ones.

QRCoder, ZXing.Net, and SkiaSharp are the property of their respective owners. This article isn't affiliated with, endorsed by, or sponsored by any of them. Comparisons reflect publicly available information at the time of writing and are provided for informational purposes only.

AWS Textract vs Google Vision (and When to Skip Both)

IronSoftware — Sun, 12 Jul 2026 15:23:52 +0000

The first time I had to choose an OCR service for a document pipeline, I spent a week benchmarking accuracy. Then I watched the whole decision get made in a single meeting by someone from legal who asked where the patient data would be processed. Accuracy barely came up. That meeting reshaped how I evaluate OCR: the question that decides a project is usually not "which engine reads better," it's "what shape are the documents, where is the data allowed to live, and how does the bill behave as volume grows."

Full transparency: I'm a developer advocate at Iron Software, and one of the three options here (IronOCR) is ours. The other two are cloud services we don't sell. I'll keep this grounded in real code and call out where AWS Textract or Google Cloud Vision is the better pick, because for a lot of workloads one of them is exactly right. Judge the code and the trade-offs for yourself.

AWS Textract

Textract is built for structured documents. Beyond returning a wall of text, its Analyze Document API extracts key-value pairs, reconstructs tables with rows and columns intact, detects signatures, and supports queries like "what is the total due?" There are purpose-built APIs for expenses, identity documents, and lending packages. If your core problem is pulling fields out of standardized paperwork, that erases a lot of custom parsing code you'd otherwise own forever.

In .NET you call it through the AWS SDK. The minimal text-detection call looks like this:

using Amazon.Textract;
using Amazon.Textract.Model;

var client = new AmazonTextractClient();

// Read the file into memory; Textract accepts raw bytes for synchronous calls.
var request = new DetectDocumentTextRequest
{
    Document = new Document { Bytes = await File.ReadAllBytesAsync("doc.png") }
};

DetectDocumentTextResponse response = await client.DetectDocumentTextAsync(request);

// Blocks come back typed; LINE blocks hold the reading-order text.
foreach (var block in response.Blocks)
{
    if (block.BlockType == BlockType.LINE)
        Console.WriteLine(block.Text);
}

That prints each detected line of text in reading order. The trade-offs I'd weigh: Textract's OCR is tuned for a focused set of Latin-script languages (English, Spanish, German, Italian, French, Portuguese), so a global multi-script corpus isn't its strength. Pricing is per page and per API, so text, tables, and forms are billed separately, and a document that needs forms plus tables gets charged for both. And the document leaves your machine for AWS to process it. For an English-or-European invoice workflow already running on AWS, none of that is a dealbreaker. Confirm current details on the Textract FAQ and pricing page.

Google Cloud Vision

Vision is built around broad language reach. Its OCR covers 80+ languages, and the recommended practice is to leave the language hint empty so the service auto-detects the script. That makes it a natural fit for mixed-language archives, international receipts, or user-submitted photos where the language isn't known ahead of time. It exposes TEXT_DETECTION for short strings in natural images and DOCUMENT_TEXT_DETECTION for dense pages and handwriting, returning a structured hierarchy of pages, blocks, paragraphs, words, and characters with bounding boxes.

The .NET client library keeps the call short:

using Google.Cloud.Vision.V1;

var client = ImageAnnotatorClient.Create();
var image = Image.FromFile("doc.png");

// DetectDocumentText is the dense-page mode; it also handles handwriting.
TextAnnotation result = client.DetectDocumentText(image);
Console.WriteLine(result.Text);

That prints the full extracted text as one string, with the structured hierarchy available on result when you need geometry. Where Vision stops is form semantics: it returns text geometry, but it does not natively pair a label with its value or rebuild a table as a table. Applications that need that from Google typically add the separate Document AI product or build the logic themselves. Like Textract, it's cloud-only and metered per unit (the first 1,000 units each month are free, with a tiered rate after), and requesting both detection features on one image counts as two units. Current rates and supported languages live on the Cloud Vision OCR docs and pricing page.

IronOCR

IronOCR is a commercial .NET library built on a tuned Tesseract 5 engine that runs entirely inside your own process. It reads images and PDFs and returns text and structured output without sending any data to an external service, which is the whole point: no REST client, no API key, no per-call billing, and it works offline.

using IronOcr;

// Runs in-process. No network call, no document leaves this machine.
var result = new IronTesseract().Read(new OcrInput("doc.png"));
Console.WriteLine(result.Text);

That prints the recognized text, and installation is a single Install-Package IronOcr. It supports 125+ languages through downloadable packs and returns structured results down to pages, blocks, lines, and words for layout-aware work. Because the engine runs locally, the same code runs identically on a developer laptop, a build server, or an air-gapped production host. There's no endpoint to be unreachable.

I'll be honest about where IronOCR is weaker. It does not match Textract's purpose-built form and table extraction, and its handwriting recognition is tuned for printed text rather than free handwriting. If the core problem is parsing handwritten forms in volume, a cloud service is the better tool. What you get in exchange is data residency, predictable licensing, and offline operation.

How they compare

Three options is enough to blur together, so here they are side by side. The row that ends most evaluations isn't accuracy, it's data privacy.

Factor	AWS Textract	Google Cloud Vision	IronOCR
Pricing	Per page, per API	Per unit, tiered after free tier	Perpetual license, no per-call fees
Languages	Focused Latin-script set	80+ with auto-detect	125+ via Tesseract 5
Forms & tables	Strong, dedicated features	Text geometry only	Structured output, no form pairing
Deployment	Cloud-only (AWS)	Cloud-only (Google)	In-process, on your server
Data privacy	Sent to AWS	Sent to Google	Never leaves your machine
Offline use	No	No	Yes

The two cloud services compete most directly on accuracy and managed scale, with continuously updated models a local library can't match on the hardest inputs. The on-prem column doesn't try to win that fight; it competes on residency, predictability, and offline capability. For healthcare records, legal discovery, documents under strict residency rules, or any system inside an air-gapped network, sending the document to a third party is either prohibited or operationally impossible, and that's the gap a local library fills.

So which one?

There's no single winner here, and I'd be suspicious of any comparison that claimed otherwise.

Pick AWS Textract if your documents are structured (invoices, IDs, receipts), the value is in key-value pairs and tables, and you're already on AWS.
Pick Google Cloud Vision if your documents span many languages, include handwriting, or arrive as everyday photos where auto-detection matters more than form structure.
Pick IronOCR if the data can't leave your network, you need offline or air-gapped operation, or you want a fixed cost with no per-page cloud fees inside a native .NET app.

A hybrid is also reasonable: handle the bulk of documents locally for residency and cost, and route the small share of complex forms to a cloud service. The fairest test is your own data, so run the same batch of representative documents through all three and compare the text output, the cost, and where the data ended up.

Which OCR are you running in production, cloud or on-prem, and what made you pick it? I'd genuinely like to hear what won on your documents, and whether it was accuracy or something around it that decided things.

If you want to benchmark the on-prem option against your own files, IronOCR has a free trial.

AWS, Amazon Textract, Google Cloud, and Google Cloud Vision are trademarks of their respective owners. This comparison reflects publicly available information at the time of writing and is provided for informational purposes only.

Open-Source OCR for C#: The Real Options and Trade-Offs

IronSoftware — Fri, 10 Jul 2026 03:18:20 +0000

When a developer asks me for "an open-source OCR library for C#," they're usually picturing something that doesn't exist: a pure-.NET text-recognition engine written from scratch. There isn't one worth shipping. Almost everything you'll find on NuGet is a wrapper, a binding, or a thin .NET surface over a native engine written in C or C++. Tesseract is C++. PaddleOCR runs on Baidu's PaddlePaddle inference runtime. OpenCV, which several of these tools lean on, is C++ too. What .NET gives you is a way to call those engines from idiomatic C# without leaving Visual Studio.

Full transparency: I'm a developer advocate at Iron Software, and we make a commercial OCR library called IronOCR. So I'm biased, but I've spent enough time wiring up the free options on real projects to give you a fair map of the landscape, and I'll be upfront about where our paid tool fits and where it doesn't. The open-source route is the right call for plenty of projects. The trick is knowing what each option actually wraps, and how the licensing shakes out, before you build it into something you have to ship.

That last part matters more than people expect. The license on the .NET wrapper and the license on the underlying engine can differ, and "free to install" is not the same thing as "free to ship in a closed-source product." Let me walk through the choices.

The default: the charlesw Tesseract wrapper

If you do nothing else, this is where you start. The most common answer to "how do I do OCR in C#" is the charlesw/tesseract wrapper, distributed on NuGet as the Tesseract package. It binds the Tesseract engine, the one Google maintained until 2018 and a community of contributors keeps alive today. Tesseract reads more than 100 languages and uses an LSTM neural network for line recognition in version 4 and up.

Here's roughly what a minimal read looks like with that wrapper:

using Tesseract;

using var engine = new TesseractEngine(@"./tessdata", "eng", EngineMode.Default);
using var img = Pix.LoadFromFile("invoice-scan.png");
using var page = engine.Process(img);

Console.WriteLine(page.GetText());
Console.WriteLine($"Mean confidence: {page.GetMeanConfidence():P0}");

That prints the recognized text block followed by a single percentage, something like Mean confidence: 87%. And that's the whole shape of it: point a TesseractEngine at a tessdata folder, load an image, process it, read the text back.

The licensing is the cleanest story in this entire article: the wrapper is Apache-2.0, and the Tesseract engine is Apache-2.0, so the whole stack is safe inside proprietary, closed-source software. No copyleft strings attached.

The friction is operational. You manage the native binaries across platforms yourself, you supply the correct tessdata language files, and you live with the fact that raw Tesseract is very sensitive to image quality. Skewed scans, low resolution, and background noise will ruin your accuracy unless you preprocess the image first. For clean, high-contrast documents, though, it's a solid free starting point and the one I reach for first when prototyping.

Tesseract through the command line

There's a scrappier variant worth knowing. If a NuGet binding feels like the wrong dependency, you can install the Tesseract executable on the host and call it as a separate process from C#.

using System.Diagnostics;
using System.IO;

// The CLI appends its own .txt extension, so pass "result", not "result.txt".
var startInfo = new ProcessStartInfo("tesseract", "invoice-scan.png result")
{
    RedirectStandardError = true,
    UseShellExecute = false
};

using var tesseractProcess = Process.Start(startInfo);
tesseractProcess.WaitForExit();

// Exit code is the only error signal a separate process gives you.
if (tesseractProcess.ExitCode != 0)
    Console.WriteLine(tesseractProcess.StandardError.ReadToEnd());
else
    Console.WriteLine(File.ReadAllText("result.txt"));

On success this writes result.txt to disk and prints its contents. On failure you get whatever Tesseract wrote to stderr, which is the whole problem with this approach.

It trades convenience for isolation. There's no marshalling layer to keep in sync with the engine, and you inherit whatever Tesseract version the OS has installed, which is handy on Linux, where tesseract-ocr is a standard package. The cost is real, though. Process startup overhead per image makes it poor for high-throughput batch work, your error handling becomes parsing exit codes and stderr instead of catching exceptions, and you've now got an external binary to install and version on every deployment target. I'd use it for scripts, scheduled jobs, and container images that already bundle the engine. I wouldn't put it behind a latency-sensitive service.

The built-in Windows engine almost nobody uses

This one gets overlooked constantly: Windows already ships an OCR engine, for free, in the Windows.Media.Ocr namespace of the Windows Runtime. The OcrEngine class runs entirely on the client, works offline, and supports around 21 languages depending on which language packs are installed on the machine. No NuGet packages to vet, no native binaries to chase, no runtime fees. It's genuinely free for commercial use.

The catch is right there in the name. This is a Windows-only API, unavailable on Linux or macOS, which rules it out for cross-platform services or Linux-based containers. Calling it cleanly from a packaged desktop app has historically meant getting your project configuration and Windows SDK targeting just right, which is where some people get stuck. But for a Windows desktop tool that needs reasonable accuracy with zero extra dependencies and no licensing paperwork, it's an easy choice that too many developers pass over. For anything that has to run on a Linux server, though, it's a non-starter.

Emgu CV: not an OCR engine, but the missing preprocessing layer

Emgu CV is a cross-platform .NET wrapper around OpenCV. It's not primarily an OCR library, and I almost left it off, but it earns its place because OCR pipelines so often need exactly what it provides: image loading, thresholding, deskewing, denoising, and contour detection to isolate text regions before recognition runs. In practice, a lot of developers pair Emgu CV preprocessing with a Tesseract pass to claw back accuracy on messy inputs. That combination is the biggest accuracy lever in the free stack.

The licensing is where you have to slow down, because it's the part that trips people up. Emgu CV uses a dual-license model. The free option is GNU GPL v3, which obliges you to release your own source under a compatible license. If you're building closed-source commercial software, GPL v3 is usually not viable, and you'd need to buy a commercial license from the vendor. So Emgu CV is open source, but "open source" here does not mean "free to ship in a proprietary product." That's a different situation from the Apache-2.0 Tesseract wrapper, and one I'd confirm with your legal team before you build it into anything you sell.

PaddleSharp: the strongest free accuracy, at a weight cost

When the inputs get hard, like photographs, rotated text, or Asian scripts, raw Tesseract starts to struggle, and this is where I point people next. The PaddleSharp project provides a .NET binding for Baidu's PaddleOCR and the PaddlePaddle inference runtime. On NuGet the relevant packages are Sdcb.PaddleOCR, Sdcb.PaddleInference, and the matching native runtime packages for your platform and CPU-or-GPU target. Both the binding and PaddleOCR are Apache-2.0, so the closed-source story is clean.

PaddleOCR's detection-plus-recognition pipeline tends to handle real-world scenes, curved text, and over 50 languages noticeably better than a single Tesseract pass, and it can download models on demand. The trade-off is weight. You're pulling in a deep-learning inference runtime, model files, and platform-specific native dependencies, which is a bigger deployment footprint and a more involved platform matrix than a lone tessdata folder. For a service where recognition quality on difficult images is the priority and you can stomach the dependency surface, it's one of the strongest free options available.

Cloud OCR SDKs: a different category entirely

The last "open-source" category isn't a local library at all, and it's worth flagging the distinction. Azure AI Vision, Amazon Textract, and Google Cloud Vision all ship official .NET SDKs that send your image to a hosted endpoint and return structured text. The SDKs themselves are usually open source and permissively licensed, but the service behind them is a metered, paid API, and your data leaves your infrastructure.

These services lead on accuracy for the truly hard inputs: handwriting, forms, dense tables. They also take the burden of managing native engines and models off your plate entirely. The trade-offs are predictable, though. Per-call pricing stops being rounding-error money somewhere around the first few thousand pages a month, you take on a dependency on network availability and latency, and data-residency rules will exclude some regulated or air-gapped workloads outright. If those constraints are acceptable and accuracy is paramount, a cloud SDK is a legitimate choice. If you need to run offline, keep documents in-house, or avoid per-page billing, you're back to a local library.

How the options compare

That's a lot to hold in your head at once, so here they are side by side. The column that surprises people is licensing, not accuracy.

Option	Wraps	License	Cross-platform	Preprocessing included	Cost
`charlesw/tesseract`	Tesseract (C++)	Apache-2.0	Yes, you ship the binaries	No	Free
Tesseract CLI via `Process`	Host-installed Tesseract	Apache-2.0	Yes, host must have it	No	Free
`Windows.Media.Ocr`	Windows Runtime engine	Windows license	No, Windows only	No	Free
Emgu CV	OpenCV (C++)	GPL v3 or commercial	Yes	It is the preprocessing	Free under GPL v3
PaddleSharp	PaddleOCR, PaddlePaddle	Apache-2.0	Yes	Detection model helps	Free
Cloud SDKs	Hosted service	SDK permissive, service metered	Yes	Server-side	Per call
IronOCR	Tuned Tesseract 5	Commercial	Yes	Yes	Paid

Where a commercial library actually fits

Let me be direct, because the brief here is honesty: IronOCR is not open source. It's a commercial .NET library, and it belongs on this list as the paid alternative, not as another free option. I'm not going to dress that up.

The reason it comes up in open-source comparisons at all is that it's built on a tuned Tesseract 5 engine and packages the things the free wrappers leave to you. Native binaries bundled per platform. Built-in image filters for deskewing and denoising, the Emgu CV preprocessing step but already wired in. 125+ languages with downloadable model packs. One managed API surface instead of three NuGet packages and a tessdata folder you maintain by hand.

using IronOcr;

// A trial key is enough to evaluate this against your own scans.
IronOcr.License.LicenseKey = "YOUR-TRIAL-KEY";

// OcrInput accepts images, PDFs, and multi-page documents through the same type.
var ocr = new IronTesseract();
using var input = new OcrInput();
input.LoadImage("invoice-scan.png");

OcrResult result = ocr.Read(input);
Console.WriteLine(result.Text);
Console.WriteLine($"Mean confidence: {result.Confidence:P0}");

The output looks the same as the charlesw/tesseract snippet near the top: recognized text, then a confidence percentage. The difference is in what OcrInput and OcrResult accept and return. OcrInput takes PDFs and multi-page documents directly, and OcrResult hands you text alongside per-word confidence scores and structured pages, blocks, and lines.

Because it's commercial, licensing is the trade-off you weigh: you pay for production use. The fair way to frame it, and I'd say this even if I didn't work here, is that you're paying to skip the integration and preprocessing work, not buying a fundamentally different engine. It's the same Tesseract lineage underneath.

So which one should you pick?

There's no single best OCR library for C#. There's only the one that fits your constraints on platform, accuracy, and licensing. Here's how I'd choose:

Clean documents, fully free, cross-platform: the charlesw/tesseract wrapper (Apache-2.0) is the default. Add Emgu CV preprocessing if your inputs are noisy, but check its GPL-or-commercial license for your distribution model first.
Windows desktop only: the built-in Windows.Media.Ocr engine costs nothing and adds no dependencies. Don't overlook it.
Difficult images, scene text, or Asian scripts: PaddleSharp (Apache-2.0) gives stronger accuracy at the cost of a heavier deployment.
Maximum accuracy with no infrastructure: a cloud SDK, if metered pricing and sending data off-box are acceptable.
Engineering time is your bottleneck, not budget: a commercial library like IronOCR, weighed honestly against the free routes above.

Whatever you pick, the one piece of advice I'd stake my name on is this: prototype on your real inputs before you commit. OCR accuracy depends far more on your specific documents (their resolution, contrast, layout, and language) than on any vendor's headline numbers. The library that wins on a clean PDF can lose badly on a photographed receipt, and the only way to know is to run your own files through it. If the free stack covers your case, use it with a clear conscience. That's the honest recommendation as often as not.

So what are you actually running in production? I'm curious how the room splits between people who stayed on charlesw/tesseract with an Emgu CV preprocessing step bolted on, and people who moved to PaddleSharp once their inputs got messy. Those seem to be the two real paths, and I've never seen a good count of which one wins.

If you want to test the integrated route on your own documents, IronOCR has a free trial you can point at your own files.

Tesseract, PaddleOCR, Emgu CV, and the cloud OCR services named here are the property of their respective owners. This article isn't affiliated with, endorsed by, or sponsored by any of them. Licensing details reflect publicly available information at the time of writing and should be verified against each project's current terms.

OCR on Windows 11: Built-In Tools and a .NET Library

IronSoftware — Thu, 09 Jul 2026 04:41:15 +0000

A few years back, if you wanted the text out of a screenshot, you typed it back in by hand. Today, my Windows 11 machine can pull text off the screen with a keyboard shortcut, and most people I talk to have no idea it can do that. I have spent a good while across QA, .NET development, and now developer relations watching teams reach for a heavyweight OCR setup when a built-in tool would have done the job in two seconds, and, just as often, reach for a keyboard shortcut when what they actually needed was code running on a server at 3 a.m. with nobody at the keyboard.

Full transparency: I work at Iron Software as a Developer Advocate, and I build with IronOCR, so I am biased toward our tools. I will keep this focused on working code and call out the real trade-offs, including the places where the free, built-in Windows tools are genuinely the better choice and you should not pay for anything. That happens more than you might expect.

Here is the way I think about it. There are two completely different OCR problems hiding under one name. One is "I can see some text on my screen and I want it on my clipboard." The other is "my software needs to read text out of files, unattended, possibly on Linux, possibly thousands of them." Windows 11 has gotten genuinely good at the first one. The second one is where you write code. Let me walk through both.

The Snipping Tool already does OCR

This is the one I show people first because it is free, it is already installed, and it reuses a shortcut a lot of folks already have in muscle memory.

Press Win + Shift + S to open the capture overlay, draw a box around the text you want, and the snip opens in the Snipping Tool window. Click the Text Actions button on the toolbar. Every recognized word lights up, and you can drag to select part of it or hit Copy all text to grab the whole block. There is also a Quick Redact option that masks detected email addresses and phone numbers before you copy, which I use constantly when I am about to paste a screenshot into a public ticket or a chat channel.

What I like about it: recognition runs on the device, so the text never leaves your machine, and it handles clean printed text in a single language well. What it deliberately does not do is expose any image preprocessing, language tuning, or batch input, and that is fine, because it is a manual capture tool, not a pipeline. For grabbing a confirmation number off a receipt or a paragraph out of a PDF preview, I genuinely have not found anything faster.

PowerToys Text Extractor, for when you do not want a screenshot at all

Microsoft PowerToys is a free utility suite, and its Text Extractor module is the one I keep enabled on every machine I set up. It predates the Snipping Tool's OCR, and it is still my reflex because of how direct it is: there is no screenshot to manage afterward.

Install PowerToys from the Microsoft Store or GitHub, then enable Text Extractor in the PowerToys settings. The default shortcut is Win + Shift + T. Press it, the screen dims with a crosshair, you drag a rectangle over any text, and the characters land straight on your clipboard. No window, no button to click afterward.

The part that has saved me more than once: it reads text that you cannot normally select. Text baked into a video frame. The label on a disabled button. An error dialog that blocks copy. I have pulled stack traces out of modal error boxes that would not let me select a single character otherwise.

You can change the activation shortcut and pick the OCR language pack in settings, which matters if you read non-English text often. Like the Snipping Tool, it is built for a person at the keyboard. There is no command-line entry point and no way to point it at a folder, so it is a power-user convenience, not an automation tool. That distinction is the whole article, really.

OneNote and Photos read text out of files you already have

The two tools above grab text off the live screen. Sometimes the source is a file sitting on disk instead, and Windows handles that too.

In OneNote, paste or insert an image into a page, right-click it, and choose Copy Text from Picture. OneNote runs OCR and drops the result on your clipboard. I use this for the occasional scanned page I dropped into my notes, and it works well for one document at a time. The Photos app and the Snipping Tool's file mode can do the same when you open an existing image and invoke Text Actions on it.

These are convenient because they meet the image where it already lives. The catch is the recurring theme: every extraction is a manual, one-image-at-a-time action with no way to script it. If you have three images, this is perfect. If you have three thousand, you need code, and that is where the rest of this article lives.

Windows.Media.Ocr: the engine Windows hands to developers

Here is the thing most developers miss. The same on-device engine those built-in tools use is available to you in code, through the Windows.Media.Ocr API in the Windows Runtime. No NuGet package, no third-party anything; it ships with Windows. If you are building a Windows-only desktop app and you want zero external dependencies, this is a reasonable place to start.

using Windows.Globalization;
using Windows.Graphics.Imaging;
using Windows.Media.Ocr;
using Windows.Storage;
using Windows.Storage.Streams;

// Create an OCR engine for the user's language (English here).
OcrEngine engine = OcrEngine.TryCreateFromLanguage(new Language("en"));

// Load an image file into a SoftwareBitmap that the engine can read.
StorageFile file = await StorageFile.GetFileFromPathAsync(@"C:\scans\invoice.png");
using IRandomAccessStream stream = await file.OpenAsync(FileAccessMode.Read);
BitmapDecoder decoder = await BitmapDecoder.CreateAsync(stream);
SoftwareBitmap bitmap = await decoder.GetSoftwareBitmapAsync();

// Run recognition and print the full text.
OcrResult result = await engine.RecognizeAsync(bitmap);
Console.WriteLine(result.Text);

That runs with nothing installed beyond Windows itself, which is a real advantage. The trade-off is sitting right in the namespace. Windows.Media.Ocr only runs on Windows, so the moment your code touches a Linux container it is gone. The language packs you get depend on what the host machine happens to have installed, which makes deployment unpredictable. And there is no image filtering in the box, so a low-contrast or skewed scan comes back with mistakes you have to handle yourself. If your app ships only to Windows desktops and the inputs are clean, that may be a fair deal. The further you drift from that, the more it costs you.

When OCR becomes part of your software, reach for a library

Once OCR has to run server-side, inside Docker, on Linux or macOS, or across a large batch of files, the manual tools and the WinRT engine both run out of road. This is the category IronOCR is built for: a .NET library on a tuned Tesseract 5 engine, aimed at programmatic scenarios, not at replacing a quick screen grab. I will be clear about that boundary, because installing a library to copy a phone number off your screen would be silly.

The three things you get over the WinRT engine are portability, bundled language data, and image correction. IronOCR runs on .NET across Windows, Linux, and macOS; it ships with 125+ languages so you are not at the mercy of what the host has installed; and it includes image filters that deskew, denoise, and binarize a scan before recognition.

using IronOcr;

// Set your license key once at startup (a free trial key works here).
IronOcr.License.LicenseKey = "YOUR-LICENSE-KEY";

var ocr = new IronTesseract();

using var input = new OcrInput();
input.LoadImage(@"C:\scans\invoice.png");

// Clean up a noisy or skewed scan before reading.
input.DeNoise();
input.Deskew();

OcrResult result = ocr.Read(input);
Console.WriteLine(result.Text);
Console.WriteLine($"Confidence: {result.Confidence}");

The OcrInput object is where the batch and quality work happens. You can load many images or whole PDFs, apply filters per page, and read them in one pass. The OcrResult carries more than plain text: there is a confidence score I lean on to flag low-quality pages for human review instead of silently trusting bad output, plus structured access to lines and words. For unattended jobs that grind through documents on a schedule, asynchronous reading keeps throughput up.

Installation is one package:

dotnet add package IronOcr

That confidence score is the feature I would not give up. In a real pipeline you do not want OCR quietly returning garbage that flows downstream into a database. You want a number you can threshold on, so anything below, say, 80% gets routed to a person. The built-in tools do not give you that, because for a manual grab you are the confidence check. You are looking right at the result.

So which one do you actually use?

There is no single best OCR tool on Windows 11. There is a best tool for each kind of job, and the honest answer crosses vendor lines.

For pulling text off your screen right now, the built-in options win on speed and cost, full stop. The Snipping Tool's Text Actions and PowerToys Text Extractor cost nothing, run on-device, and need no code. Reach for those first for any manual, one-off extraction. I do, every day, and I work at an OCR company.

The moment OCR moves into your own software, a server, or a stack of files, those manual tools stop being an option at all. A Windows-only desktop app with clean inputs can use Windows.Media.Ocr and ship zero dependencies. For anything that has to run cross-platform, process many files unattended, clean up poor scans, or report a confidence score you can act on, a library is the layer to build on.

If your project lands in that programmatic category, you can start a free IronOCR trial and run it against your own documents before you commit to anything. The tutorials cover reading scanned documents and the other formats you will hit in practice. Match the tool to the job, and most days the right tool turns out to be free.

Read Handwritten Text From an Image in C# (Handwriting OCR)

IronSoftware — Tue, 07 Jul 2026 19:37:10 +0000

Read Handwritten Text From an Image in C# (Handwriting OCR)

Reading handwritten text from an image is one of the hardest problems in OCR, and I want to set expectations before you write a line of code. Printed text has consistent glyph shapes and predictable spacing, which is why most engines handle it well. Handwriting brings variable stroke widths, joined cursive letters, slanted baselines, and quirks that no two writers share. What follows is the practical path for pulling handwriting out of an image in C#, with honest notes on where it holds up and where it falls apart.

Quick disclosure: I work on IronOCR at Iron Software, so the code here uses it. I'll be straight: handwriting is the hardest case in OCR, and no library (IronOCR included) reads messy cursive reliably. IronOCR builds on the Tesseract LSTM engine, a neural model trained on text lines rather than isolated characters, and that line-based recognition is what gives it any chance against handwriting at all. If your real target is fast cursive on a phone photo, you should know up front that cloud and ML services like Azure and Google Cloud Vision usually beat Tesseract-based engines on genuine handwriting. Where IronOCR earns its place is neat print or block capitals on a clean scan, fully on your own hardware with no image leaving the machine.

Here is the smallest read that returns text from a handwritten sample.

using IronOcr;

var ocr = new IronTesseract();
using var input = new OcrInput();
input.LoadImage("handwritten-note.png");

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

For neat block printing on a clean, high-resolution scan, that output is often usable. For cursive on a low-resolution photo, expect missing words and substituted characters. Treat the basic path as a baseline to improve on, not a finished result.

Installing IronOCR

Install the IronOcr NuGet package. It bundles the Tesseract 5 engine and the English language data, so there are no separate downloads to manage.

Install-Package IronOcr

Once it restores, I add a single using IronOcr; directive to reach IronTesseract, OcrInput, and OcrResult. I recommend confirming the install with a trivial read against any image first, so you can separate setup problems from recognition problems later. I like to keep that smoke test around, because it tells me at a glance whether a later failure is the engine or my image.

Enabling the LSTM engine

Setting the engine to LSTM-only is the change that helps handwriting most. It relies on the neural model that handles connected, irregular strokes better than the legacy character-matching path.

using IronOcr;

var ocr = new IronTesseract
{
    Configuration =
    {
        EngineMode = TesseractEngineMode.LstmOnly,
        PageSegmentationMode = TesseractPageSegmentationMode.SingleBlock,
        ReadBarCodes = false
    }
};

using var input = new OcrInput();
input.LoadImage("handwritten-note.png");

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

I use SingleBlock for a paragraph of handwriting, while a single handwritten line reads more reliably with SingleLine. Page segmentation mode is worth testing per document type, because the wrong mode can cut accuracy more than any filter restores. One gotcha I keep hitting: even with the LSTM engine, handwriting accuracy sits well below the high-90s figures quoted for clean printed text, so do not promise a stakeholder those numbers.

Pre-processing the image

Pre-processing usually delivers a larger gain on handwriting than any engine setting, because handwriting is so often photographed at an angle under uneven lighting. Apply IronOCR's built-in image filters before recognition runs.

using IronOcr;

var ocr = new IronTesseract
{
    Configuration = { EngineMode = TesseractEngineMode.LstmOnly }
};

using var input = new OcrInput();
input.LoadImage("handwritten-note.png");

// Order matters: straighten first so later filters work on aligned text
input.Deskew();    // rotate so text lines sit horizontal
input.Contrast();  // widen the gap between ink and paper
input.DeNoise();   // strip speckle and paper grain

OcrResult result = ocr.Read(input);
Console.WriteLine(result.Text);
Console.WriteLine($"Confidence after filters: {result.Confidence}");

Deskew helps line-based recognition directly, Contrast rescues faint pencil and low-light photos, and DeNoise removes grain the engine would otherwise read as strokes. A common mistake I've made myself is stacking every filter at maximum: over-filtering erases thin pencil strokes and smears closely spaced cursive together. I add one filter at a time and compare the confidence score before keeping it. For tougher samples, IronOCR also exposes Binarize, GrayScale, and Sharpen.

Reading a specific region

On forms, you often want one handwritten field, like a comments box or signature line, without surrounding printed labels interfering. Pass an OcrRegion so recognition runs only on the coordinates you give it.

using IronOcr;

var ocr = new IronTesseract
{
    Configuration = { EngineMode = TesseractEngineMode.LstmOnly }
};

using var input = new OcrInput();

// x, y, width, height in pixels from the top-left corner
var commentsBox = new System.Drawing.Rectangle(60, 420, 900, 180);
input.LoadImage("filled-form.png", new OcrRegion(commentsBox));

input.Deskew();
input.Contrast();

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

Restricting the region does double duty: it removes distracting printed text and speeds up recognition by giving the engine less to scan. I still run pre-processing on the cropped area for the same accuracy reasons. For fixed positions on a standardized form, hardcoding the rectangle is reliable. For variable layouts, detect the field first, then read it.

Checking confidence and flagging low-confidence words

With handwriting, this check is the safeguard that keeps wrong text out of your data. Read the mean Confidence, then walk result.Words to surface the individual words the engine was least sure about. That per-word view is what lets you flag exactly which handwriting needs a human, rather than rejecting a whole page over one bad word.

using IronOcr;

var ocr = new IronTesseract
{
    Configuration = { EngineMode = TesseractEngineMode.LstmOnly }
};

using var input = new OcrInput();
input.LoadImage("handwritten-note.png");
input.Deskew();
input.Contrast();
input.DeNoise();

OcrResult result = ocr.Read(input);

// Tune the threshold to your accuracy tolerance
const double minimumConfidence = 70d;

if (result.Confidence >= minimumConfidence)
{
    Console.WriteLine("Accepted:");
    Console.WriteLine(result.Text);
}
else
{
    Console.WriteLine($"Low confidence ({result.Confidence:F1}). Flag for manual review.");
}

// Surface the weak spots so a reviewer sees only what needs checking
foreach (var word in result.Words)
{
    if (word.Confidence < minimumConfidence)
    {
        Console.WriteLine($"Uncertain word: '{word.Text}' ({word.Confidence:F1})");
    }
}

Choose the threshold to match your tolerance: a legal-records pipeline might demand a high bar, while a search-indexing job can accept more noise. One caution worth repeating: confidence is a relative signal, not a guarantee. The engine can report high confidence on a word it read wrong, especially when the misread is itself a plausible word. For anything consequential, pair the score with human verification rather than treating it as proof.

Where this leaves you

The honest summary is that these techniques give handwriting recognition its best shot in a fully on-premises .NET pipeline, and the confidence gate is what makes the output safe to act on. I treat clean block printing as the realistic success case, and treat cursive or low-resolution photos as work that still needs human review. If neat handwriting on your own hardware is the goal, the IronOCR free trial lets you benchmark against your own samples. If your inputs are genuinely messy cursive, test a cloud OCR service alongside it before you commit. That comparison is worth the afternoon.

The step with the biggest payoff is usually better input: scan at 300 DPI or higher and control the lighting before reaching for software filters. From there, tune page segmentation mode and the filter combination per document type rather than chasing one universal setting.

What handwriting have you tried to read in code, and how did it go? If you have found a preprocessing combination or a threshold that holds up on real-world notes, I would like to hear what worked and what did not. The configs people share usually beat any benchmark table.

How to Read OCR Confidence Scores in C# and Trust Your Tesseract Results

IronSoftware — Fri, 03 Jul 2026 18:42:29 +0000

How to Read OCR Confidence Scores in C# and Trust Your Tesseract Results

When you run OCR over a scanned invoice or a photographed receipt, the extracted text is only half the story. The other half is how much you can trust each piece of it. A street address read from a crisp PDF and the same address read from a blurry phone photo both come back as plain strings, but only one of them deserves to flow straight into your database without a second look.

That trust signal is what makes OCR safe to automate. Instead of accepting a whole page blindly, you can route high-confidence documents straight through and send the doubtful ones to a person. Confidence scores are how you draw that line.

Quick disclosure: we work on IronOCR at Iron Software, so the API here is its result's confidence data. The pattern (threshold, then human-review the doubtful ones) applies to any OCR engine that reports confidence, including raw Tesseract. We'll be honest about the limits too: a confident reading can still be a confident mistake, so the score is a routing heuristic, not a correctness guarantee.

Here's the fastest version. After reading an image, the overall confidence sits on the result as a double between 0 and 100:

// IronOcr namespace exposes the engine and result types
using IronOcr;

// Create the OCR engine
var ocr = new IronTesseract();

// Load the image directly as an OCR input
using var input = new OcrImageInput("invoice-scan.png");

// Recognize the document
OcrResult result = ocr.Read(input);

// Single number summarizing how confident the engine is overall (0-100)
Console.WriteLine($"Overall confidence: {result.Confidence:F1}%");

If you want to follow along, install the package the same way you'd add any other dependency:

# Install the IronOCR NuGet package
Install-Package IronOcr

What an OCR confidence score actually means

A confidence score estimates how certain the engine is about the characters it produced. It reflects how cleanly the recognizer matched glyph shapes against its trained model. Sharp edges, good contrast, and a standard font push the number up, while noise, skew, and odd typefaces push it down.

What it does not tell you is whether the text is semantically right. The engine can be 98% sure it read an 8 when the original ink was a 3 that happened to render with a closed loop. We've watched that exact failure slip through, so we treat the number as a way to prioritize attention, never as a final stamp on critical fields.

The same Confidence property exists at every level of the result, so you can ask about the whole page or a single word:

// IronOcr namespace exposes the engine and result types
using IronOcr;

// Create the OCR engine
var ocr = new IronTesseract();

// Load the statement image as an OCR input
using var input = new OcrImageInput("statement.png");

// Recognize the document
OcrResult result = ocr.Read(input);

// Confidence exists on the whole result...
Console.WriteLine($"Result: {result.Confidence:F1}%");

// ...and on each individual word
Console.WriteLine($"Word:   {result.Words[0].Confidence:F1}%");

The lower you go, the more granular the signal. A page might average 92% while one smudged word inside it sits at 41%. That contrast is exactly what makes per-element scores worth reading.

Triage a whole document with the overall score

The overall Confidence is the quickest first-pass filter we reach for. It's an averaged certainty across everything the engine recognized, so it tells you whether a document is broadly clean or broadly trouble. Here we loop a small batch and compare each against a cutoff:

// IronOcr namespace exposes the engine and result types
using IronOcr;

// Create the OCR engine once and reuse it across the batch
var ocr = new IronTesseract();

// The small batch of scans to triage
string[] documents = { "receipt-01.png", "receipt-02.png", "receipt-03.png" };

// Read each file and score it against a cutoff
foreach (string file in documents)
{
    // Load the current file as an OCR input
    using var input = new OcrImageInput(file);

    // Recognize the document
    OcrResult result = ocr.Read(input);

    // Quick first-pass triage on the document as a whole
    string verdict = result.Confidence >= 85 ? "auto-accept" : "needs review";
    Console.WriteLine($"{file}: {result.Confidence:F1}% -> {verdict}");
}

One gotcha worth flagging early: the average hides outliers. A page can post a healthy 88% overall while a single critical field, an account number or a total, sits far below that. When a field matters, you check it directly rather than trusting the page average. That's the next step.

List the low-confidence words

To find the tokens worth a human's eye, iterate result.Words and read each word's Confidence. Every entry also carries its recognized Text and positional data, so you can point a reviewer straight at the spot on the page:

// IronOcr namespace exposes the engine and result types
using IronOcr;

// Create the OCR engine
var ocr = new IronTesseract();

// Load the label image as an OCR input
using var input = new OcrImageInput("shipping-label.png");

// Recognize the document
OcrResult result = ocr.Read(input);

// Any word scoring below this needs a human's eye
const double wordThreshold = 75;

// Collect every word the engine was unsure about
var suspectWords = result.Words
    .Where(word => word.Confidence < wordThreshold)   // keep the weak ones
    .OrderBy(word => word.Confidence)                 // weakest first
    .ToList();

// Report how many words were flagged
Console.WriteLine($"Flagged {suspectWords.Count} low-confidence word(s):");

// Print each flagged word with its coordinates
foreach (var word in suspectWords)
{
    // Location tells reviewers exactly where to look on the page
    Console.WriteLine(
        $"  '{word.Text}' at ({word.X},{word.Y}) -> {word.Confidence:F1}%");
}

We set a word-level threshold, filter the words below it, and sort the weakest to the top. This is the right granularity for structured-data extraction: a license, a passport, or an invoice has a handful of fields that truly matter, and checking those specific words beats accepting or rejecting the whole document on its average. The same iteration works on result.Lines or result.Paragraphs when your fields span multiple words, and only the collection changes.

Route documents for human review

Now you can put both signals together into a two-tier rule: one cutoff for the overall result and a stricter one for any single word. That catches both globally poor scans and locally damaged fields.

// IronOcr namespace exposes the engine and result types
using IronOcr;

// Create the OCR engine
var ocr = new IronTesseract();

// Load the application image as an OCR input
using var input = new OcrImageInput("loan-application.png");

// Recognize the document
OcrResult result = ocr.Read(input);

const double pageThreshold = 90;   // whole-document floor
const double wordThreshold = 80;   // stricter floor for any single token

// Does the page as a whole clear the floor?
bool pageIsClean = result.Confidence >= pageThreshold;

// Does every single word clear the stricter floor?
bool everyWordIsClean = result.Words.All(word => word.Confidence >= wordThreshold);

// Auto-process only when both checks pass
if (pageIsClean && everyWordIsClean)
{
    Console.WriteLine("Auto-processing: all scores cleared the threshold.");
    // push extracted fields into your system of record
}
else
{
    // Route to a person and tell them why it was flagged
    var weakest = result.Words.OrderBy(w => w.Confidence).First();
    Console.WriteLine("Sent to review queue.");
    Console.WriteLine($"Reason: weakest word '{weakest.Text}' at {weakest.Confidence:F1}%");
}

Only documents that clear both floors get processed automatically; everything else goes to a person along with the reason it was flagged. We've found the thresholds are a business decision: a marketing mailing list tolerates a far lower bar than a medical record or a wire-transfer instruction.

A word of caution we keep coming back to: a passing score is not verified data on high-stakes fields. For figures that carry legal or financial weight, such as totals, account numbers, and dates of birth, keep a human in the loop regardless of the number. Tuning the cutoffs is empirical work. Start strict, run a representative sample through, and watch how many documents land in review versus how many errors slip past. Loosen or tighten until the false-accept rate matches what your use case can absorb.

When a score is low, fix the image first

When a document scores poorly, the fix is usually the image rather than the threshold. You can apply preprocessing filters to the input before reading, then re-check the confidence to confirm the cleanup helped. That turns the score into a feedback loop of measure, clean, then measure again:

// IronOcr namespace exposes the engine and result types
using IronOcr;

// Create the OCR engine
var ocr = new IronTesseract();

// First pass on the raw, noisy scan
using var rawInput = new OcrImageInput("faded-receipt.png");

// Record the baseline confidence before any cleanup
double before = ocr.Read(rawInput).Confidence;

// Second pass after cleaning the same image up
using var cleanInput = new OcrImageInput("faded-receipt.png");
cleanInput.Deskew();           // straighten tilted text
cleanInput.ToGrayScale();      // drop distracting color
cleanInput.Binarize();         // hard black-and-white separation
cleanInput.DeNoise();          // remove speckle and grain

// Record the confidence after preprocessing
double after = ocr.Read(cleanInput).Confidence;

// Compare the two to see whether the cleanup actually helped
Console.WriteLine($"Before: {before:F1}%  After: {after:F1}%  Gain: {after - before:F1} pts");

One mistake we see often is stacking every available filter and hoping for the best. Aggressive binarization or denoising on an already-clean image can erode thin strokes and drag the score down. Add filters one at a time and keep only the ones that move confidence up.

If you'd like to put this on your own documents, IronOCR has a free trial you can run against your real scans and measure the scores you get back.

Where this leaves you

The throughline is short: confidence is a routing signal that decides where attention goes, and human review stays the backstop for anything that truly matters. Read the overall score to triage, drill into per-word scores to flag weak tokens, threshold both to route the doubtful documents, and preprocess to rescue borderline scans.

What thresholds have worked for you in production? If you've found a confidence cutoff that balances throughput against false accepts on a specific document type such as receipts, IDs, or forms, we'd like to hear the number and how you landed on it. And if you've been burned by a confident misread that sailed through automation, tell us where it broke.

ZXing Barcode Scanner in .NET: ZXing.NET vs IronBarcode

IronSoftware — Wed, 01 Jul 2026 18:00:04 +0000

ZXing Barcode Scanner in .NET: ZXing.NET vs IronBarcode

If you have searched for a "ZXing barcode scanner" in C#, you have probably landed on ZXing.NET, the community port of the Java ZXing project (pronounced "zebra crossing"). It reads and writes a broad set of 1D and 2D symbologies, and it has been a reference for barcode handling for well over a decade. This comparison puts it next to IronBarcode and lets the code show where each one fits.

Full disclosure: we build IronBarcode at Iron Software, one of the two libraries here. ZXing.NET is free and genuinely capable; we'll flag where it's the better pick and let the code speak.

Here is the short version. ZXing.NET is free, open source, and mature, and for clean, standard barcodes it does exactly the job. The tradeoff is that you handle the imaging glue and any preprocessing yourself, and the library follows a community release cadence. IronBarcode is commercial, but it bundles the imaging stack, image correction, and PDF reading, so noisy or rotated input needs less code from you. Pick by use case, not by logo.

A minimal ZXing.NET scan

ZXing.NET ships on NuGet. The core package carries the format definitions and decoding logic but deliberately leaves out an imaging dependency, so you pair it with a binding. On Windows, ZXing.Windows.Compatibility adds the System.Drawing glue.

Install-Package ZXing.Net

using System;
using System.Drawing;
using ZXing;
using ZXing.Windows.Compatibility;

var barcodeReader = new BarcodeReader();
var scanResult = barcodeReader.Decode((Bitmap)Image.FromFile("barcode.png"));
Console.WriteLine(scanResult?.Text); // null-conditional: Decode returns null on no match

Decode returns a single Result, or null when nothing is found, which is why the null-conditional ?.Text matters. For a clean image of a standard symbology, we find that is all you need, and it works well.

💡 If you want to spend more CPU recovering a marginal scan, set Options = new ZXing.Common.DecodingOptions { TryHarder = true } on the reader.

What ZXing.NET covers

ZXing.NET inherits the broad symbology coverage of the Java project, which is the main reason developers reach for it:

1D / linear: UPC-A, UPC-E, EAN-8, EAN-13, Code 39, Code 93, Code 128, ITF, Codabar, MSI, RSS-14
2D / matrix: QR Code, Data Matrix, Aztec, PDF-417

Both reading and writing are supported, so the same package generates a QR code or a Code 128 as well as decoding one. If you know which formats you expect, restrict the reader to them, since it cuts false positives and speeds up the scan when the decoder stops probing symbologies you will never receive.

✅ For a project that scans clean retail barcodes or generates QR codes, this is a solid, zero-cost foundation, and we would point you straight at it.

Where the friction shows up

In our experience the rough edges are rarely in the core decoding; they show up around a real integration.

Imaging setup

Because the core package has no image dependency, decoding a file on modern .NET means also installing a binding such as ZXing.Net.Bindings.SkiaSharp, ZXing.Net.Bindings.ImageSharp, or ZXing.Windows.Compatibility. You also work around System.Drawing.Common being Windows-only on newer .NET, which is why cross-platform teams often standardize on SkiaSharp or ImageSharp.

Image correction

ZXing.NET handles grayscale, binarization, and a TryHarder mode, but it offers fewer built-in helpers for rotation, skew, low resolution, or noisy scanner output. When a source image needs cleanup, that preprocessing is your job through whichever imaging library you bound to.

Release cadence

⚠️ ZXing.NET is community-maintained and tracks an upstream Java project, so releases arrive on a community schedule rather than a commercial timeline. For many teams that is fine; for some with stricter support needs, it is a factor to weigh. None of this makes ZXing.NET a poor choice. It describes where the work lives.

The same scan with IronBarcode

IronBarcode is the commercial .NET library we build: it packages the imaging stack, correction, and document handling in one namespace. There is one package to install and no per-platform binding to pick.

Install-Package BarCode

using IronBarCode;
using System;

var scanResults = BarcodeReader.Read("barcode.png");
foreach (var barcode in scanResults)
    Console.WriteLine(barcode.Text);

You can install IronBarcode from NuGet and run that in about five minutes. Read returns a collection rather than a single result, so an image holding several barcodes comes back in one call. For the clean single-barcode case, we think the two libraries are close enough that cost and license model should decide it, and ZXing.NET being free is a real advantage there.

The gap widens on imperfect input. Where you would hand-write rotation and noise handling for ZXing.NET, we expose it through reader options:

using IronBarCode;
using System;

var readerOptions = new BarcodeReaderOptions
{
    ExpectMultipleBarcodes = true,
    Speed = ReadingSpeed.Detailed, // spend more CPU on messy input
    ImageFilters = new ImageFilterCollection
    {
        new SharpenFilter(),
        new ContrastFilter()
    }
};

var skewedResults = BarcodeReader.Read("skewed-scan.png", readerOptions);
foreach (var barcode in skewedResults)
    Console.WriteLine($"{barcode.BarcodeType}: {barcode.Text}");

The Detailed speed setting and the filter chain are what you reach for on skewed, low-contrast, or noisy scans. IronBarcode can also read straight from a PDF and batch across pages without you rasterizing each one first. That is the practical difference: less glue code for messy or multi-page input, at the cost of a commercial license.

How they compare

Factor	ZXing.NET	IronBarcode
Read / write	✅ Both	✅ Both
Symbologies	1D (UPC, EAN, Code 39/93/128, ITF, Codabar, MSI) and 2D (QR, Data Matrix, Aztec, PDF-417)	Same broad 1D and 2D set
Image preprocessing	Manual, through bound imaging library	Built-in sharpen, contrast, rotation, noise correction
Imaging dependency	Separate binding package required	Self-contained
Read from PDF / multi-page	Manual rasterization first	✅ Direct, batched
.NET targets	.NET Standard / Core / Framework (+ binding)	.NET Standard / Core 2.0+, Windows, Linux, macOS, Azure
License	Apache 2.0, free, open source	Commercial, paid
Maintenance	Community cadence, tracks Java upstream	Commercial release cadence and support

So which one?

There is no single winner here, and we would distrust a comparison that claimed one.

✅ Pick ZXing.NET if you want free, open-source, full-source-access barcode handling, your images are clean and standard, and you are comfortable wiring an imaging binding and any preprocessing yourself. For a great many projects, that is the right call.
✅ Pick IronBarcode if your input is skewed, noisy, rotated, or arrives as PDFs, you are batch-reading at volume, and a single-package install with built-in correction and commercial support is worth a license fee. The IronBarcode barcode reading tutorial covers PDF input and the filter options shown above.

The fairest test is your own data. Run the same set of representative images through both and compare what decodes and how much code each one took.

Which barcode library are you running in production, and what tipped the decision? We would genuinely like to hear which one held up on your worst scans in the comments.

If your worst scans are the problem, you can put IronBarcode against your own images with the free trial.

ZXing and ZXing.NET are trademarks of their respective owners; this comparison reflects publicly available information at the time of writing.

ZXing.NET vs IronBarcode: Pick a .NET Barcode Library

IronSoftware — Tue, 30 Jun 2026 17:38:03 +0000

ZXing.NET vs IronBarcode: Picking a Barcode Library for .NET

Choosing a barcode library for a .NET project usually comes down to a few questions: which formats do you need, how clean are your input images, and how much budget do you have. We looked at two options that come up constantly in .NET barcode discussions: ZXing.NET and IronBarcode.

Full disclosure: we're the team behind IronBarcode, one of the two libraries here. We've tried to keep this fair and flag where ZXing.NET is the better pick, so judge the code and the tradeoffs yourself.

Here's what we found: both are real, working choices, and the right one depends on your situation more than on any feature checklist. ZXing.NET is free, open-source, and mature. IronBarcode trades that open-source freedom for a higher-level .NET API and built-in handling of messy real-world images. Let's look at the code.

ZXing.NET

ZXing.NET is the .NET port of the Java ZXing library ("Zebra Crossing"). It's open-source under Apache 2.0, which means it's free to use, modify, and ship commercially with attribution. It decodes and generates a wide list of 1D and 2D formats: QR Code, Data Matrix, Aztec, PDF 417, Code 128, Code 93, UPC-A/E, EAN-8/13, Codabar, and more. It has been around for years and has a large community, so most problems you hit already have an answer somewhere.

You install it from NuGet:

Install-Package ZXing.Net

Generating a code

To produce a QR code you set up a writer, generate pixel data, and turn that into an image yourself. Here's a condensed version:

using ZXing;
using ZXing.QrCode;
using ZXing.Common;

var qrWriter = new BarcodeWriterPixelData
{
    Format = BarcodeFormat.QR_CODE,
    Options = new EncodingOptions { Height = 250, Width = 250, Margin = 0 }
};

PixelData pixelData = qrWriter.Write("hello world");
// pixelData.Pixels is a BGRA byte array you then copy into a Bitmap and save.

Reading a code

Reading is similar: load a bitmap, hand it to the reader, and inspect the result.

using ZXing;
using System;
using System.Drawing;

var barcodeReader = new BarcodeReader();
var sourceBitmap = (Bitmap)Image.FromFile("sample-barcode-image.png");
Result decodeResult = barcodeReader.Decode(sourceBitmap);

if (decodeResult != null)
{
    Console.WriteLine(decodeResult.BarcodeFormat + ": " + decodeResult.Text);
}

That prints the format and decoded text, or skips the block when nothing decodes. The tradeoff here is that you're closer to the metal. On a clean, machine-generated image this works well and costs nothing. ZXing.NET also leans on System.Drawing, so on .NET Core and later you often add a bindings package for image handling, and the decoder is sensitive to skew, rotation, and noise.

✅ If your inputs are clean barcodes and your budget is zero, ZXing.NET is often the right call, and for plenty of projects it's the one we'd reach for too. The project lives at github.com/micjahn/ZXing.Net.

IronBarcode

IronBarcode is a commercial .NET library with a higher-level API for reading and writing barcodes. It targets .NET Standard and Core 2.0+ across Windows, Linux, macOS, and Azure, and supports the same broad set of 1D/2D formats plus styled QR codes with logos and color. The difference you pay for is the layer on top: a simpler API and built-in correction for imperfect images.

Installation is a single NuGet package, and you can run the snippets below in about five minutes:

Install-Package BarCode

Generating a code

A barcode or QR code is one statement to create, and saving to common formats is built in:

using IronBarCode;

// Code 128 barcode
BarcodeWriter.CreateBarcode("https://ironsoftware.com/csharp/barcode", BarcodeEncoding.Code128)
    .SaveAsPng("MyBarCode.png");

// QR code with a chosen error-correction level
QRCodeWriter.CreateQrCode("hello world", 500, QRCodeWriter.QrErrorCorrectionLevel.Medium)
    .SaveAsPng("MyQR.png");

Reading a code

Reading a clean barcode is one call. Read returns a collection of BarcodeResult, so take the first match and read its .Value:

using IronBarCode;
using System;
using System.Linq;

var firstResult = BarcodeReader.Read("GetStarted.png").FirstOrDefault();
if (firstResult != null)
{
    Console.WriteLine("Read value: " + firstResult.Value);
}

The part that justifies the cost is reading from imperfect sources: skewed, rotated, or noisy images such as phone photos and scans. You can pass correction settings and a specific format to steer the reader:

using IronBarCode;
using System;

var photoResults = BarcodeReader.Read(
    "Photo.png",
    new BarcodeReaderOptions
    {
        ExpectBarcodeTypes = BarcodeEncoding.Code128,
        Speed = ReadingSpeed.Detailed
    });

foreach (var barcode in photoResults)
{
    Console.WriteLine(barcode.Value);
}

IronBarcode also reads barcodes directly from PDF documents and multi-frame TIFFs without you splitting pages first, and it can stamp generated barcodes onto existing PDFs. The tradeoff is honest: it's a paid, closed-source library rather than free and open-source. If your images are predictable and clean, that preprocessing buys you little. If you're pulling barcodes off real-world scans and want to stay inside a single .NET API, it removes work you'd otherwise write yourself.

How they compare

Factor	ZXing.NET	IronBarcode
Read / write	✅ Both	✅ Both
Symbologies	QR, Data Matrix, Aztec, PDF 417, Code 128/93, UPC, EAN, Codabar, more	Same broad 1D and 2D set, plus styled QR
API style	Lower-level, you assemble images	High-level .NET, one call to generate or read
Image preprocessing	You handle skew/noise yourself	Built-in rotation and noise correction
PDF / multi-frame TIFF	Manual extraction	Read directly
Image stack	Often needs a System.Drawing bindings package	Self-contained
.NET targets	.NET Standard / Core / Framework (+ binding)	.NET Standard / Core 2.0+, Windows, Linux, macOS, Azure
License	Apache 2.0, free, open-source	Commercial, paid, closed-source
Maintenance	Large community, tracks Java upstream	Commercial support and docs

A few honest takeaways. On price and openness, ZXing.NET wins outright: it's free, the source is right there, and it's backed by years of community use. IronBarcode's advantage is narrower and specific: a single-package install, a simpler API, and correction for messy inputs. For a use case with clean inputs and no budget, ZXing.NET might actually be the better choice, and we'd say so plainly.

So which one?

There's no single winner here, and we'd be skeptical of any comparison that declared one.

✅ Pick ZXing.NET if you want free, open-source code, a mature community, and your barcode images are clean and machine-generated.
✅ Pick IronBarcode if you're staying inside .NET, your inputs are noisy scans or photos that need correction, and you'd trade a license fee for a single install and a higher-level API. The IronBarcode reading and writing tutorial shows the PDF and correction paths end to end.

The fairest test is your own data. Run the same set of representative images through both and compare what decodes and how long it takes.

Which barcode library are you running in production, and what made you pick it? We'd genuinely like to hear which won on your images in the comments.

If you want to put IronBarcode against ZXing.NET on your own files first, there's a free trial.

ZXing and ZXing.NET are trademarks of their respective owners; this comparison reflects publicly available information at the time of writing.

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.