Create scannable barcodes in the formats retail and logistics actually use — CODE128, EAN-13, UPC-A, CODE39, and ITF-14 — with live validation, then download as crisp PNG or infinitely scalable SVG.
A 1D barcode — the classic stripes — holds a short identifier (typically 8–20 characters) that a laser scanner reads in a millisecond. A QR code holds ~100× more data and needs a camera. The decision rule: if the code will be scanned by retail or warehouse equipment (checkout scanners, inventory guns, conveyor readers), you need a 1D barcode in the format that equipment expects. If it will be scanned by phones to open a link or show information, you want a QR code instead. Product packaging routinely carries both — the EAN for the till, a QR for the customer.
CODE128 is the default for everything internal: asset tags, shelf labels, membership cards, shipment references. It encodes any ASCII text compactly and every modern scanner reads it. EAN-13 (worldwide) and UPC-A (North America) are the retail product codes — but the number isn't yours to invent: real products need a company prefix issued by GS1, the global numbering authority. Generating an EAN here is for testing layouts, internal SKUs, or printing a code you were already assigned. CODE39 survives in older industrial and government systems — bulkier than CODE128 but sometimes contractually required. ITF-14 marks outer shipping cartons with the 14-digit GTIN of the goods inside, printable at low quality on corrugated cardboard.
Numeric formats carry a check digit — the last digit is computed from the others, so scanners can spot misreads. Enter 12 digits for EAN-13 and the tool computes the 13th for you; enter 13 and it verifies. If validation fails, the digits themselves are wrong — a common paste error worth catching before you print five hundred labels.
Most scanning failures are printing failures. The rules that matter: print at 300 DPI or better (download the SVG for perfect sharpness at any size, or a high-resolution PNG); keep the quiet zone — the blank margin either side of the bars — at least 10× the narrow bar width, and never let design elements intrude on it; print dark bars on a light background, ideally black on white, since red bars are invisible to laser scanners; and never stretch the code horizontally or vertically in a layout tool — bar-width ratios are the data, and uneven scaling corrupts them. Before a production run, print one sample and scan it with both a phone app and, if possible, the actual scanner hardware that will read it in the field.
The barcode image is fully standard-compliant — but a retail product needs a number registered with GS1 so it's globally unique. Generate the image here from your GS1-assigned number; don't invent numbers for products headed to real shelves.
SVG for anything going to print or into design software — it's vector, so it stays perfectly sharp at any size. PNG for quick use in documents, spreadsheets, and web pages. If a tool rejects SVG, convert it with our SVG to PNG converter at high resolution.
Each format has rules: EAN-13 and UPC-A accept only digits at exact lengths (and verify the check digit), CODE39 allows uppercase letters, digits, and a few symbols, ITF-14 needs an even count of digits. CODE128 accepts nearly anything — switch to it if your data doesn't fit a numeric format.
No — generation runs entirely in your browser via the JsBarcode library. Internal SKUs and reference numbers stay on your machine.
Retail EAN codes have a nominal size of about 37×26 mm and shouldn't go below 80% of that. For CODE128 labels, keep the narrow bar at least 0.25 mm wide after printing. When in doubt, print larger — no scanner ever failed because a barcode was too big.