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

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.