ZXing.Net: a .NET barcode reader and generator with an image-library split

What ZXing.Net solves, and who ends up using it

The project describes itself as a library that supports decoding and generating barcodes such as QR Code, PDF 417, EAN, UPC, Aztec, Data Matrix and Codabar within images. That sentence covers two jobs that are usually separate products: reading a symbol out of a bitmap, and producing a bitmap that contains one. A warehouse label printer, a point-of-sale till, a ticket scanner and an inventory app all sit on that pair of operations.

The audience is narrower than "anyone who needs barcodes". The README lists assemblies for .NET 2.0 through 7.0, .NET Standard, .NET Core, UWP, Portable Class Library, Unity3D, Xamarin.Android, Windows RT, and COM interop for VBA. That spread is the real story: this is a library for teams already inside the Microsoft stack, often with a legacy component that has to keep working. If you are writing a modern service that shells out to a scanner process, or you only ever need QR codes in a browser, the platform list is not aimed at you.

The port is described as done by hand with optimizations and improvements over the Java original. That matters for anyone comparing behaviour against the upstream zxing project: identical symbology support is the goal, but the code is not a mechanical translation.

How decoding and encoding actually flow through the library

The README's sample code shows the shape of the API. You construct a BarcodeReader, hand it a Bitmap, and call Decode. The return value is either null or a result object with two fields the sample uses: BarcodeFormat, which tells you which symbology was found, and Text, which is the decoded payload. There is no configuration step in the basic path, which is why the sample is five lines long.

Under that surface the reader has to bridge two worlds: image pixels and symbol geometry. That bridge is exactly where the package split lives. The main ZXing.Net package for .NET Standard and .NET 5.0 or higher, in the README's words, "only contains the core classes which are not dependent on a specific assembly for image formats". The core does not know how to open a PNG. A binding package supplies the image type and the pixel access the core needs.

The supported binding list is long and worth reading before you start: Windows.Compatibility, CoreCompat.System.Drawing, ImageSharp, SkiaSharp, OpenCVSharp, Magick, Kinect V1 and V2, EmguCV, Eto.Forms and ZKWeb.System.Drawing. That is a deliberate design choice rather than an accident of packaging. It keeps the core free of a hard dependency on System.Drawing, which matters on Linux and in container images where System.Drawing.Common has been a recurring source of trouble. The cost is that a new user's first compile error is usually a missing binding, not a decoding bug.

Installing ZXing.Net and decoding your first image

The README points at two distribution channels: the GitHub release section and the NuGet package ZXing.Net. For a classic .NET Framework project up to 4.8.1, the main package plus the framework's own System.Drawing is enough, and the sample from the README looks like this.

// create a barcode reader instance
IBarcodeReader reader = new BarcodeReader();
// load a bitmap
var barcodeBitmap = (Bitmap)Image.FromFile("C:\\sample-barcode-image.png");
// detect and decode the barcode inside the bitmap
var result = reader.Decode(barcodeBitmap);
// do something with the result
if (result != null)
{
   txtDecoderType.Text = result.BarcodeFormat.ToString();
   txtDecoderContent.Text = result.Text;
}

If the result is not null you get the format name and the decoded text. If it is null, no symbol was found; the README's basic sample does not distinguish between "no barcode present" and "barcode present but unreadable".

On .NET Standard or .NET 5.0 and above, the README is explicit that you must add one of the additional NuGet packages for a specific image library, listed at the ZXing.Bindings search page. The README's own example uses ZXing.Windows.Compatibility in a .NET 8.0 console application.

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

// create a barcode reader instance
var reader = new BarcodeReader();
// load a bitmap
var barcodeBitmap = (Bitmap)Image.FromFile("C:\\sample-barcode-image.png");
// detect and decode the barcode inside the bitmap
var result = reader.Decode(barcodeBitmap);

The observable difference from the first sample is the using directive and the need to print the outcome yourself; the README's version writes "No barcode found" to the console when the result is null. Note the namespace change: the binding package, not the core, owns the BarcodeReader type in this configuration. Swapping bindings later means changing that using line and the image type you pass in.

Where ZXing.Net stops being the right tool

The binding split is the first real limitation, and it is a usability one rather than a technical one. A developer who installs ZXing.Net on .NET 8.0 and copies the first README sample will not compile. The README does warn about this, but the warning sits below the first code block, and the first code block is the one people paste.

Symbology support is asymmetric. The decoder list includes UPC-A, UPC-E, EAN-8, EAN-13, Code 39, Code 93, Code 128, ITF, Codabar, MSI, RSS-14 in all variants, QR Code, Data Matrix, Aztec and PDF-417. The encoder list is shorter: it adds Plessey, which the decoder list does not mention, and it omits Code 93 and RSS-14 entirely. If your workflow is "read Code 93 labels and write replacements", the library covers the read half and not the write half. That asymmetry is not flagged as a limitation in the README, it is just two lists you have to compare yourself.

Platform drift is the second constraint. Windows Phone 7.0, 7.1 and 8.0, Windows CE, and Silverlight 4 and 5 assemblies are labelled obsolete and only available up to release 0.16. Anyone maintaining a Silverlight or Windows CE application is on a branch, not on the current package. The README also notes that Xamarin.iOS has no pre-built binaries and must be built from the project file in the repository, and that the .NET Micro Framework version lives in a separate branch. Those are all cases where the library works but the packaged convenience does not.

Finally, the demo clients (command line decoder and encoder, Windows Forms, Windows Service, WPF, Windows RT, Windows Store with HTML5/JS, Unity3D and Vuforia, EmguCV, OpenCV, AForge) are described as demos. The README does not present them as supported end-user tools, and nothing in it suggests they should be shipped as such.

ZXing.Net against QRCoder, and against the Java original

The most common comparison is with QRCoder, and the difference is scope rather than quality. QRCoder is a QR code generator. ZXing.Net is a reader and a writer across retail linear barcodes, RSS-14, and four 2D symbologies. If every code you touch is a QR code and you only generate them, a QR-only library is a smaller dependency with a smaller surface. The moment you have to decode an EAN-13 off a product photo, or read a PDF-417 from a shipping label, the QR-only tool has nothing to offer and ZXing.Net does.

The second comparison is with the upstream Java zxing project. ZXing.Net is a hand port of it, and the README credits the zxing team directly. The practical difference is the binding architecture described above: the Java library carries its own image abstractions, while ZXing.Net pushes image handling out to a binding package. That gives .NET users a choice of image stack that Java users do not get, at the price of one more package to install and one more namespace to import.

Maintenance, licence and the cost of upgrading

The repository is not archived. The last push was on 2026-08-26. The most recent tagged release listed is v0.16.11.0 on 2025-10-26, following v0.16.10.0 on 2025-01-26 and v0.16.9.0 on 2023-02-24. The gap between 0.16.9 and 0.16.10 is roughly eleven months, and between 0.16.10 and 0.16.11 roughly nine. Release cadence is therefore slow and irregular, which is normal for a mature port but means you should not expect a fix to land on a predictable schedule.

The licence is Apache-2.0, with the COPYING file at the repository root and a 3rdparty directory alongside it. Apache-2.0 permits commercial use and modification and includes a patent grant, but it also carries notice and attribution obligations: if you redistribute the library you need to preserve the licence and notices, and the 3rdparty directory suggests there are bundled components with their own terms. Read COPYING and 3rdparty before shipping a closed-source product. This is a description of the licence file layout, not legal advice.

Upgrade cost is dominated by the binding decision. Moving a project from .NET Framework to .NET 5.0 or higher is not a version bump on ZXing.Net; it is a change of which package provides BarcodeReader and which image type you pass to Decode. Teams that pin the binding package version and the ZXing.Net version together will have a simpler upgrade path than teams that let them float independently.

Editorial conclusion

Adopt ZXing.Net if you need one library that both reads and writes the common retail and 2D symbologies inside an existing .NET application, and if you are willing to pick the image binding that matches your stack. Do not adopt it expecting the main NuGet package alone to load a PNG on .NET 5.0 or higher, and do not treat the command line demos as production tools. Before committing, verify which binding package matches your target framework, confirm the encoder supports the specific format you need (the README lists Plessey for encoding but not for decoding), and check the release notes for the version you pin.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. micjahn/ZXing.Net on GitHub
4. README
5. Releases