Guard patterns, three alphabets, a hidden digit, and the arithmetic that catches mistakes.
A retail barcode looks like decoration until you know what you are looking at. It is not a picture of a number and it is not a font — it is a fixed-length binary message with error checking built in, designed in the early 1970s to be read reliably by a cheap laser and a photodiode. Once you can see the structure, the stripes stop being arbitrary and start being readable by eye.
This guide covers EAN-13, the thirteen-digit code used on almost every retail product outside North America, along with its close relatives UPC-A and EAN-8. Everything here is about the symbology itself, so it applies whether you are generating a label, debugging a scanner, or trying to work out what a damaged code used to say.
The first thing to unlearn is that the code is made of bars. The real unit is the module: a single narrow vertical stripe of fixed width that is either black or white. A bar you see is simply one, two, three or four black modules sitting next to each other, and a wide white gap is several white modules in a row.
This matters enormously in practice. A scanner does not measure bars in millimetres, because it has no idea how far away the label is or how big it was printed. Instead it measures the ratio of run lengths against the narrowest run it can find, and converts everything to module counts. That is why the same barcode works printed two centimetres wide on a tin or two metres wide on a shipping container: only the proportions carry meaning.
An EAN-13 symbol is always exactly 95 modules wide. Not approximately — exactly. That fixed budget is what lets a decoder check its own work.
Those 95 modules are divided into six regions, and the layout never varies:
| Region | Modules | Pattern |
|---|---|---|
| Start guard | 3 | 101 |
| Left half — 6 digits | 42 | 7 modules per digit |
| Centre guard | 5 | 01010 |
| Right half — 6 digits | 42 | 7 modules per digit |
| End guard | 3 | 101 |
Add those up: 3 + 42 + 5 + 42 + 3 = 95. Every digit occupies exactly seven modules, and every digit pattern contains exactly two bars and two spaces — never more, never fewer.
The guards are the scaffolding. The start and end guards are thin bar-space-bar patterns that stick down slightly below the rest of the code, and the centre guard splits the number into two independent halves. Their job is calibration: because the decoder knows the guards are 101, 01010 and 101, it can find them in a noisy signal, measure how many pixels one module currently occupies, and use that scale to read everything in between.
If you look closely at a real label, the three guard patterns extend a millimetre or two lower than the digit bars. That is not styling. It leaves room for the printed digits to sit in the gaps between them without touching any bar that carries data, and it gives the guards a distinctive silhouette that survives a scan line clipping the bottom of the symbol.
Each digit from 0 to 9 has not one seven-module pattern but three, drawn from three alphabets called L, G and R.
Take the digit 6. In L it is 0101111. Invert it and you get R: 1010000. Reverse that R pattern and you get G: 0000101. Three encodings of the same digit, and each one is derived from the others by a simple transformation.
The parity difference is doing quiet work. Because L patterns always have an odd number of dark modules and R patterns always have an even number, a decoder that has read seven modules can tell which half of the symbol it is looking at without knowing where it started. That is the property that makes the next trick possible.
Because G is the reverse of R, a right-half digit read backwards parses cleanly as a left-half digit. This is not a rare edge case — it is guaranteed by the design. If you feed a decoder half a barcode and let it guess the direction, it will happily produce a fluent, plausible, completely wrong number. Anyone writing a decoder has to treat left-to-right and right-to-left as two competing hypotheses and score them separately, rather than blending the evidence. The blend always looks convincing and is frequently wrong.
Here is the elegant part. Twelve digits are encoded directly: six in the left half, six in the right. But EAN-13 has thirteen digits. Where does the first one live?
It is encoded in the choice of alphabet across the left half. Each of the six left digits is drawn from either L or G, and the sequence of those choices — LLLLLL, LLGLGG, LGLGLG and so on — spells out the leading digit. There are exactly ten legal patterns, one per digit:
| First digit | Left-half parity pattern |
|---|---|
| 0 | L L L L L L |
| 1 | L L G L G G |
| 2 | L L G G L G |
| 3 | L L G G G L |
| 4 | L G L L G G |
| 5 | L G G L L G |
| 6 | L G G G L L |
| 7 | L G L G L G |
| 8 | L G L G G L |
| 9 | L G G L G L |
Notice that every pattern begins with L. That is deliberate, and it is what makes a UPC-A code a special case of EAN-13: a UPC-A is simply an EAN-13 whose leading digit is 0, which is why the parity is all-L and why the thirteenth digit is not printed on American packaging. The same physical symbol is valid in both systems.
This design also gives a decoder a free integrity check. Only ten of the sixty-four possible L/G sequences mean anything. If you read a left half and the parity pattern is not on that list, you have misread something — no further checking required.
The final digit of an EAN-13 is not data. It is arithmetic over the previous twelve, and its job is to catch the mistakes humans and scanners actually make.
Working left to right across the first twelve digits, multiply alternate digits by 1 and 3, starting with 1. Add the results. The check digit is whatever you must add to reach the next multiple of ten.
Code: 5 0 1 2 3 4 5 6 7 8 9 ?
Weights: 1 3 1 3 1 3 1 3 1 3 1 3
5(1) + 0(3) + 1(1) + 2(3) + 3(1) + 4(3)
+ 5(1) + 6(3) + 7(1) + 8(3) + 9(1) + 0(3)
= 5 + 0 + 1 + 6 + 3 + 12 + 5 + 18 + 7 + 24 + 9 + 0
= 90
90 is already a multiple of 10, so the check digit is 0.
Full code: 5012345678900The alternating 1-3 weighting is chosen carefully. Because adjacent digits carry different weights, swapping two neighbours — by far the most common typing error — changes the total by twice the difference between them, which is only invisible when the digits differ by exactly 5. And because a single digit is always weighted by 1 or 3, any single wrong digit always changes the sum. In short: it catches every single-digit error and most transpositions.
This one bites people. EAN-8, the short form used on small packaging, has seven data digits plus a check digit, and the weighting starts on 3, not 1 — the pattern is 3, 1, 3, 1, 3, 1, 3. Apply the EAN-13 rule to an EAN-8 and you will get a plausible-looking wrong answer, which is exactly the kind of bug that hides for years because it never triggers on the codes you tested with.
A quick sanity check: the real EAN-8 code
20886509validates only under the 3-1-3-1 weighting. If your implementation says the check digit should be 5, it is using the EAN-13 rule by mistake.
The check digit does something more useful than validation. If you know every digit but one, you can solve for the missing one, because 3 has a multiplicative inverse modulo 10 (3 × 7 = 21 ≡ 1). Whether the hole sits on a weight of 1 or a weight of 3, exactly one of the ten possible digits satisfies the checksum. So a single unreadable digit anywhere in the code is not a loss at all — it is recoverable with certainty.
Two missing digits is a different story. Then the checksum has one equation and two unknowns, which leaves ten candidate pairs and no way to choose between them. An honest decoder reports the ambiguity rather than picking one.
Point a scanner at a code rotated 180 degrees and it still works. The reason follows from everything above: the decoder reads the symbol both ways, and only one direction produces a legal parity pattern and a valid checksum. The wrong direction produces garbage that fails those tests, so it can be discarded with confidence. The redundancy that makes the format robust is the same redundancy that makes orientation irrelevant.
Because the halves are independent — separated by the centre guard, each with its own six digits — a code torn down the middle is not necessarily lost. The left fragment still contains a start guard, six digits and a centre guard, which is enough to recover seven digits (six directly, one from the parity pattern). The right fragment contains a centre guard, six digits and an end guard, which gives the remaining six. Put the two fragments together, and the checksum then confirms whether the reconstruction is right.
The limits are worth being honest about. A tear that runs vertically through the middle of a digit destroys that digit's seven modules and no amount of cleverness recovers them from the bars alone — though if it is the only missing digit, the checksum will solve it. A tear through a guard pattern is worse, because it removes the calibration the decoder relies on to establish module width.
The row of numerals underneath the bars is called the human-readable interpretation, or HRI. It is not decoration and it is not merely a convenience for shop staff — it is a complete second encoding of the same number, in a different physical form, in a different place on the label. Ink survives scuffing that destroys bar edges; bars survive smudging that renders small print illegible. When the two disagree, something is wrong and the honest answer is to say so rather than to average them.
None of this requires special hardware. A photograph and some careful arithmetic will decode a retail barcode, which is precisely what a phone camera does when it reads one.