Encode Code 128, EAN, UPC, Code 39, ITF-14, DataMatrix and Aztec symbols with their check digits and error-correction computed from the specification, export them as PNG or SVG, and read one back from a camera or an image. Everything runs in this tab — nothing is uploaded.
{{ activeFormat.blurb }}
Type \F to insert an FNC1 separator — that is what turns a Code 128 symbol into GS1-128.
Scanners read contrast, not colour. Dark bars on a light background is the only combination guaranteed to work — an inverted or low-contrast code may decode on a phone and fail on a laser scanner.
Enter a value to draw the symbol.
{{ error }}
The check digit you typed did not match the data, so the computed one was used instead.
public/tools/shared/lib/zxing/VENDORING.md — three curl commands vendor it locally. Generating codes is unaffected. Decoding uses a local WebAssembly reader (~1 MB). It loads the first time you start the camera or open an image, then stays cached. Reads Code 128, EAN, UPC, Code 39, ITF, DataMatrix, Aztec, PDF417 and QR. Nothing leaves this tab.{{ cameraError }}
Hold a linear code so the bars run across the frame and fill most of its width. A 2D symbol reads at almost any angle.
PNG, JPEG, WebP or GIF — a screenshot, a photo of a label, or a code you just exported from the Generate tab. Paste works too.
{{ imageNote }}
A decoded payload is untrusted text. If it is a link, check where it actually goes — the QR Code Scanner runs those checks on a payload for you.
Every symbol on this page is built from its specification rather than fetched from a service. That matters most for the parts people get wrong by hand. Check digits are computed: EAN-13, EAN-8, UPC-A, UPC-E and ITF-14 all use the same alternating 1/3 weighting, and if you paste a full number whose last digit does not match, the correct one is used and you are told. Code 128 picks the shortest encoding — the A/B/C character-set switches are chosen by a dynamic program over the whole string, which is what keeps a mixed string like an order number with a long digit run from producing a needlessly wide symbol.
The two matrix formats carry real error correction. DataMatrix is ECC200: the data is encoded in ASCII mode with digit pairs packed two-to-a-codeword, padded with the standard randomised 253-state pad, protected with Reed–Solomon parity over GF(256) with the DataMatrix field polynomial, and laid out with the Annex F placement algorithm before the finder and timing patterns are drawn around each data region. Aztec is the compact variant, one to four layers: text is packed with the five-mode latch/shift alphabet, bit-stuffed per word, protected with Reed–Solomon over a field chosen by word size, and spiralled around the central bullseye with the mode message in the ring beside it.
Which one to use. Code 128 for anything internal and alphanumeric. EAN-13 or UPC-A only if you have a real GS1 prefix — a made-up number will scan and then collide with somebody's product. ITF-14 for shipping cartons, where the print is coarse. DataMatrix when the label is tiny or will get scuffed; Aztec for tickets, because it needs no quiet zone. Code 39 only when the equipment on the other end is old enough to require it.
Reading is a different problem from writing — it needs binarisation, perspective recovery and a decoder per symbology — so the Scan tab loads a local WebAssembly build of ZXing instead of reimplementing that. It is fetched from this site, not a CDN, and only when you first use the tab. Round-tripping is the honest test of both halves: export a PNG from Generate, drop it into Scan, and the payload and format should come back unchanged.
Related: the QR Code Generator covers styled QR codes with gradients and a logo, the QR Code Scanner analyses a scanned payload for spoofing signals, and the SVG & Image Optimizer will shrink an exported SVG before it goes into a print template.
Privacy: encoding, rendering, the camera stream and every decoded payload stay in this tab. There is no upload, no server call and no analytics on what you encode or scan.
