Barcode formats are called symbologies, and choosing between them is simpler than it looks once you separate two questions that get conflated: is this going through a retail till, and does the data have to be numbers?
The decision, up front
Selling through retail? You need EAN-13 or UPC-A, and you need a real, registered number. This is not a technical choice.
Anything internal — stock, assets, shelves, jobs, samples? Use Code 128. It takes letters, it takes numbers, it is compact, and every scanner reads it.
Very small item, retail? EAN-8 exists for exactly this and nothing else.
Everything below is why.
Code 128: for everything that is yours
Code 128 encodes the full ASCII set — letters, digits, punctuation, control characters. Nobody has to allocate you anything; you decide what the codes mean.
It has a property worth understanding because it explains a confusing behaviour. Code 128 has three character sets, called A, B and C, and it can switch between them mid-symbol:
- A — uppercase, digits, control characters
- B — upper and lowercase, digits, punctuation
- C — digits only, encoded in pairs
Set C is the interesting one. By encoding two digits per symbol, it roughly halves the width of a numeric barcode. Our generator switches to set C automatically when the input is an even-length run of digits, which is why 12345678 produces a visibly narrower barcode than 1234567A — same character count, half the symbols.
The practical consequence: if your internal codes are numeric and you can make them an even number of digits, they print about half as wide. For a warehouse label that is the difference between fitting and not fitting.
Code 128 also carries a mandatory check character, computed as a weighted sum of the encoded values. You never see it and never type it; the encoder adds it, the scanner verifies it, and a misread is rejected rather than silently accepted.
EAN-13 and UPC-A: for retail, and not otherwise
These are the codes on grocery packaging. They are fixed-length, digits only, and — the part people miss — the numbers are allocated, not invented.
An EAN-13 begins with a prefix identifying a numbering organisation, followed by a company number issued to a specific business, followed by that company’s own product reference, followed by a check digit. UPC-A is the twelve-digit form used predominantly in North America, and is structurally the same thing; a UPC-A is an EAN-13 with a leading zero.
You cannot make one up. A number you invent may already belong to somebody else’s product, and it will fail validation somewhere in a retail supply chain. Getting a real one means registering with the numbering authority for your territory.
This is the single most common mistake with barcodes: generating an EAN-13 for internal stock because it looks more official. Use Code 128. It is designed for exactly that, it is more compact for the purpose, and nobody has to allocate you anything.
EAN-8 is the short form, for items physically too small for the full symbol. It is separately allocated and comparatively scarce — it is not simply “EAN-13 for small labels”, and you do not get to shorten your own number to fit.
Check digits, and why verification matters more than calculation
Every retail symbology ends in a check digit derived from the preceding digits — for EAN-13, a weighted sum alternating 1 and 3 across the digits, subtracted from the next multiple of ten.
Most generators will compute it for you if you leave it off. Fewer will verify it if you supply it, and that is the more useful behaviour, because the realistic failure is not that you forgot the check digit. It is that you transcribed the number wrong.
Ours does both: compute when omitted, verify when supplied, and reject a wrong one while naming the digit it expected. A generator that silently overwrites your check digit with the correct one for the number you mistyped has hidden the error and printed a label for the wrong product.
Reading the human-readable digits
The digits under a retail barcode are not decoration, and their layout is part of the specification.
On an EAN-13 the first digit sits outside the bars to the left; the next six sit under the left half, the last six under the right half, split by the centre guard pattern. The guard bars at each end and in the middle extend below the digit row.
This matters for two reasons. A scanner needs the quiet zones and guard patterns intact — cropping tightly to the bars, a common instinct when fitting a label, breaks scanning. And the extended guard bars are how a human tells a correctly-formed symbol from a picture of one.
Our generator lays the digits out in the correct positions per symbology and extends the guard bars below the digit row, because a barcode that scans but looks wrong invites someone to “fix” it.
Testing barcodes properly
Looking at a barcode tells you almost nothing. The only test that counts is decoding it with something that reads barcodes.
Every symbology our generator produces was verified by decoding the rendered image with a real scanner library rather than by visual inspection, and a deliberately incorrect EAN-13 check digit was confirmed to be rejected with the correct expected digit named. That distinction matters: a “does it render” test passes on a barcode that no scanner can read.
If you are producing labels at any volume, test the same way. Print one, scan it with the hardware that will actually be used, at the size and on the material you will actually use. Barcodes fail on shiny surfaces, on curved packaging, at small sizes and with insufficient contrast — none of which is visible on screen.
Output format
Print work wants SVG. It is vector, so it scales to any label size without the bar edges softening, and sharp bar edges are what scanners need. Rasterise only when a system demands a bitmap, and rasterise at the final size rather than scaling afterwards.
Quiet zones, and the commonest printing failure
The white space either side of a barcode is not margin. It is part of the symbol.
Scanners use the quiet zone to establish where the code begins and ends. Crop it away and the scanner has no reference for the first and last bars, and the code fails to read — or worse, reads intermittently, which is harder to diagnose than a clean failure.
The requirement is specified per symbology and is proportional to the narrow-bar width. For EAN-13 it works out to roughly ten times the narrow-bar width on the left and seven on the right; for Code 128 it is ten on each side. In practice, leaving a clear margin at least as wide as the barcode is tall will not go wrong.
This is the single commonest failure when designers fit barcodes into tight label layouts. The code looks fine, it scans on the designer’s screen, and it fails intermittently on the line.
Sizing for print
Two rules cover most of it.
Do not scale a barcode non-uniformly. Stretching horizontally changes the bar-to-space ratios the scanner is measuring. If you must fit a narrower space, regenerate the code — reducing the data, or switching to a denser symbology — rather than squashing it.
Do not go below the minimum magnification. Retail symbologies define a nominal size and an acceptable range around it. Printing too small makes the narrow bars narrower than the printing process can reliably reproduce, and ink spread does the rest.
Contrast matters more than people expect. Scanners want dark bars on a light background, and they are measuring reflectance, not colour as you perceive it. Red bars on white are close to invisible to a red-light scanner. Black on white is the only combination that always works; black on a light warm colour usually works; anything else needs testing on the actual hardware.
Shiny surfaces cause specular reflection that blinds the scanner, and curved packaging distorts the bar spacing. Both are worth testing physically rather than reasoning about.
Generate Code 128, EAN-13, EAN-8 and UPC-A barcodes as PNG or print-ready SVG, in your browser, with our barcode generator. Nothing is uploaded, and it has no external dependencies at all.