Barcode Generator with Computed Check Digits

Encode Code 128, EAN, UPC, Code 39, Code 93, ITF-14, DataMatrix, Aztec and PDF417 symbols with their check digits and error-correction computed from the specification, export them as PNG or SVG, generate a batch of serial-numbered labels, and read one back from a camera or an image. Everything runs in this tab — nothing is uploaded.

10 symbologies · check digits computed · local only
About this tool

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.

Three of the 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. PDF417 is a stacked format, not a square one — each row is its own linear symbol, one of three cluster patterns chosen by row number so a scanner can tell adjacent rows apart; the data is byte-compacted into base-900 codewords and protected with Reed–Solomon over GF(929), a prime field rather than the binary ones DataMatrix and Aztec use.

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. PDF417 when a single symbol needs to carry a large amount of data — IDs, boarding passes, shipping manifests — more than a 1D symbol or a small 2D one can hold. Code 39 and Code 93 for equipment old enough to expect them; Code 93 is denser and adds two check characters, at the cost of being the less universally supported of the two.

Batch generation fills a printable label sheet from a serial-number range or a pasted CSV, using the symbol format and appearance settings above for every label — useful for inventory tags, asset labels or a run of sequentially numbered tickets that would be tedious to generate one at a time.

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.