Barcodes & QR Codes | Symbologies

The BarcodeFormat enum lists every symbology the renderer supports. The same enum drives the MAUI Format, the Blazor Format, and the headless BarcodeRenderer.

Supported formats

Format	Dimension	Use for	Sample payload
QRCode	2D	URLs, vCards, Wi-Fi configs, generic text	https://shinylib.net
Aztec	2D	Transport tickets, boarding passes	M1JOHNDOE/EXAMPLE...
DataMatrix	2D	Tiny labels, electronics, healthcare	SKU-12345
Pdf417	2D (stacked)	Driver’s licenses, shipping labels	larger structured data
Code128	1D	General-purpose, shipping, IDs	ABC-12345-XYZ
Code39	1D	Legacy industry / military / automotive	HELLO 42 (uppercase + a few symbols)
Code93	1D	Compact alternative to Code 39	HELLO123
Codabar	1D	Libraries, blood banks, FedEx airbills	A123456789B
Ean8	1D	Retail (small packages)	96385074 (valid GTIN-8)
Ean13	1D	Retail (Europe / global)	5901234123457 (valid GTIN-13)
UpcA	1D	Retail (North America)	036000291452
UpcE	1D	Retail (compact, small packages)	04252614
Itf	1D	Carton labels, ITF-14 / SCC-14	even-length numeric string

Choosing a format

• Encoding a URL, text, contact, or Wi-Fi join? → QRCode. It’s the most widely scannable 2D code and the only one with a tunable error correction level.
• A retail product? → Ean13 (or UpcA in North America). The payload must be a valid GTIN with a correct check digit.
• A general-purpose 1D code (shipping, asset tags, IDs)? → Code128. It’s compact and handles the full ASCII range.
• Very small label, lots of data, square footprint? → DataMatrix packs a lot into a tiny area.
• Boarding pass / transit ticket? → Aztec (no surrounding quiet-zone required, common in transport).
• A lot of structured data on a 1D-style label? → Pdf417 (stacked, high capacity — used on IDs and licenses).

Input rules & validation

1D symbologies have strict input rules — fixed lengths, restricted alphabets, and check digits:

• EAN-13 / EAN-8 / UPC-A / UPC-E — numeric only, fixed length, and a valid check digit. (ZXing can compute the final check digit for you depending on input length, but supplying a full, correct GTIN is the safe path.)
• ITF — numeric only and an even number of digits (it encodes digits in pairs).
• Code 39 — uppercase letters, digits, and a small symbol set (- . $ / + % and space).
• Code 93 / Code 128 / Codabar — each has its own character set; Code 128 covers the widest range (full ASCII).

Invalid input never throws — it clears the output

Both the MAUI views and Blazor components wrap encoding in a try/catch. If the payload is invalid for the chosen symbology (wrong length, bad alphabet, bad check digit), the control silently clears the image rather than throwing. The headless BarcodeRenderer does not swallow exceptions — call it inside your own try/catch if you want to detect failures.

If you need user-facing “that’s not a valid barcode” feedback, validate the payload before binding it.

QR error correction

QR codes embed redundant data so they can still be read when partially damaged or obscured. The QRErrorCorrection level controls how much redundancy is added — higher levels survive more damage but leave less room for your actual data at a given module count.

Level	Approx. recovery	Use when
Low	~7%	You need maximum data capacity in the smallest code, and the code lives on-screen / undamaged
Medium (default)	~15%	General use — a sensible default for most apps
Quartile	~25%	Printed codes that may get light wear or partial coverage
High	~30%	Print/stickers that may be scuffed, curved, or partly covered (e.g. with a logo)

Set it via:

• MAUI — QRCodeView.ErrorCorrection
• Blazor — QRCodeView.QRErrorCorrection (or BarcodeView.QRErrorCorrection when Format = QRCode)
• Headless — BarcodeRenderOptions.QRErrorCorrection

The setting is ignored for every non-QR format.

Tip

For anything printed or laser-engraved, lean toward High. For a code shown briefly on a screen where you want to cram in the most data, Low is fine.

See also

• .NET MAUI Usage · Blazor Usage · Headless Rendering