QRCoder: QR generation in pure C#, from WiFi to Swiss bills

Pure C#, zero dependencies, two maintainers

QRCoder is a simple C# library for generating QR codes and Micro QR codes, originally created by Raffael Herrmann and continuing today in the Shane32 repository, a fork that has become the living line of the project. The headline engineering property is stated first in the feature list, zero dependencies, no external libraries required, only framework dependencies, which for a .NET library is a stronger promise than it sounds, the whole encoder and renderer stack compiles from C# alone with nothing to vendor, pin or audit beyond the framework itself. Fast performance with a low memory footprint follows from that restraint, and the support matrix is unusually wide, .NET 5 and later, .NET Framework 3.5 and later, .NET Core 1.0 and later, and .NET Standard 1.3 and later, spanning essentially the entire public history of the platform. The license is MIT, the package is on NuGet, and the wiki, release notes and milestones pages document usage, history and what is coming.

One helper call or generator plus renderer

Installation is the NuGet Package Manager line, Install-Package QRCoder, and the quick start shows both idioms the API supports. The static helper collapses generation into one call:

using QRCoder;

// Generate a simple black and white PNG QR code
byte[] qrCodeImage = PngByteQRCodeHelper.GetQRCode("Hello World", QRCodeGenerator.ECCLevel.Q, 20);

// Generate a scalable black and white SVG QR code
using var qrCodeData = QRCodeGenerator.GenerateQrCode("Hello World", QRCodeGenerator.ECCLevel.Q);
using var svgRenderer = new SvgQRCode(qrCodeData);
string svg = svgRenderer.GetGraphic();

The second half of the snippet is the composable pattern, generate the QR code data first, then hand it to a renderer, which is the shape applications settle on once they render the same code several ways or hold the data across an await. The ECCLevel.Q argument selects error correction in both forms, and the using statements reflect that the generated data and renderers are disposable, the API being explicit about the memory it holds. The wiki's How to use QRCoder page extends from here into the full surface.

Six renderers from PNG to PostScript

The output format list reads as a tour of everywhere a QR code lands, PNG for the web and documents, SVG for scalable embedding, PDF for print workflows, ASCII for terminals and logs, Bitmap for classic System.Drawing consumers, and PostScript for the printing industry, with the renderers following the generator-plus-renderer pattern so a single QR code data object can feed any of them. A separate QRCoder.Xaml project in the solution serves XAML platforms with native rendering, keeping the core free of UI framework references the same way the format renderers stay separable. Configuration covers the appearance dimensions that matter, error correction levels from the standard's L through H, custom colors, and logo and styling support, the ability to embed an image in the center and adjust the modules around it, the feature that separates a library used for product QR codes from one used for utility output. Micro QR support rounds out the generation side, producing the smaller format for space-constrained placements where a full QR code does not fit, a distinction that matters on printed circuit boards, product labels and tiny screens where every square millimeter of module area counts.

The payload generator catalog

The payload generators are where QRCoder accumulates domain knowledge, 23-plus classes each producing the properly formatted string a scanner will act on. The communication family covers WiFi credentials, URLs, browser bookmarks, email with prefilled fields, SMS and MMS, phone numbers, Skype calls, WhatsApp messages, geolocation coordinates, vCard and MeCard contact data, and iCal calendar events. The security family provides OneTimePassword for TOTP and HOTP, the two-factor authentication payloads. The largest family is payments, Bitcoin, Bitcoin Cash, Litecoin and Monero addresses and transactions, Girocode for SEPA EPC QR codes, BezahlCode for the German payment standard, SwissQrCode implementing the Swiss QR bill under ISO-20022, RussiaPaymentOrder under the Russian GOST standard, and a Slovenian UPN QR variant. The usage example shows the pattern, construct the payload, generate the QR code data from it with an optional ECC override, render:

using QRCoder;

// Create a bookmark payload
var bookmarkPayload = new PayloadGenerator.Bookmark("https://github.com/Shane32/QRCoder", "QRCoder Repository");

// Generate the QR code data from the payload
using var qrCodeData = QRCodeGenerator.GenerateQrCode(bookmarkPayload);

// Or override the ECC level
using var qrCodeData2 = QRCodeGenerator.GenerateQrCode(bookmarkPayload, QRCodeGenerator.ECCLevel.H);

// Render the QR code
using var pngRenderer = new PngByteQRCode(qrCodeData);
byte[] qrCodeImage = pngRenderer.GetGraphic(20);

The breadth is the value, a team integrating a payment QR or a WiFi provisioning code writes business logic, not format research, and each payload row in the table links to its own wiki section with constructor signatures and worked examples rather than leaving the reader to infer the parameter order from the type name.

A solution layout built for verification

The repository's project layout reveals how the maintainers earn confidence in a zero-dependency encoder. Beside the core QRCoder library and its XAML sibling sit QRCoderTests for the unit suite, QRCoderApiTests exercising the public surface, QRCoderBenchmarks for performance measurement, QRCoderConsole for command-line driving, QRCoderDemo and a UWP demo for interactive inspection, and QRCoderSamples collecting usage patterns. The most distinctive member is QRCoderTrimAnalysis, a project dedicated to verifying the library's trim safety, the .NET trimming that strips unused IL and historically breaks reflection-heavy code, an analysis project meaning the maintainers treat AOT- and trim-compatible output as a tested property rather than a hope. Directory-wide build properties and targets keep the projects aligned, a global.json pins the SDK, and codecov coverage reporting backs the badge, the infrastructure of a library that expects to be embedded in other people's shipping software.

Release rhythm and the wiki as the manual

The release cadence is measured and steady, v1.6.0 in June 2024, v1.7.0 in October 2025 and v1.8.0 in April 2026, with the repository pushed as recently as 2026-09-11, activity concentrated where a mature library needs it. The wiki carries the real documentation, a How to use QRCoder guide for the basics and an Advanced usage series whose payload generator section anchors every row of the payload table to a page with worked examples, the wiki link structure turning the README's summary into a navigable manual. Milestones publish upcoming features, the changelog rides the releases page, and the contributors graph records the community beyond the two names in the lineage. For an integrator, the shape of the documentation, examples runnable in isolation and each feature explained on its own page, is what keeps a 23-payload API surface approachable.

Where it sits against ZXing.Net

The natural comparison in the .NET ecosystem is ZXing.Net, the port of the ZXing barcode library, and the difference is scope. ZXing spans barcode formats and reads as well as writes, a scanner-and-generator toolkit with a larger surface and a lineage from Java. QRCoder is QR-only and generation-only, and that narrowness is precisely what funds its properties, a pure C# codebase with no dependencies, a support matrix reaching back to .NET Framework 3.5, trim analysis as a first-class concern, and payload generators that encode domain standards directly. A project that needs to scan codes or emit EAN or Code 128 reaches for ZXing.Net, and a project whose entire need is producing excellent QR codes, from WiFi provisioning screens to payment slips, gets a smaller, more focused dependency here, with the payload catalog tipping the decision whenever the string to encode has structure. Both libraries are free to try in a sandbox, so the cheapest evaluation is generating the same three codes through each and comparing the integration effort directly.

Editorial conclusion

Use QRCoder when a .NET application must generate QR codes without carrying native or third-party dependencies, since the pure C# implementation spans .NET Framework 3.5 through modern .NET with framework dependencies only. Consider ZXing.Net when you also need QR and barcode reading or its wider barcode format coverage, since QRCoder generates rather than scans. Verify first which payload standard your region's payments require, the generator list names the exact specifications, choose your error correction level deliberately since it trades capacity for damage tolerance, and check the wiki's usage guide before styling QR codes with logos, because over-decoration can push a code below scannability.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Shane32/QRCoder on GitHub