Parity selection

The problem

EAN-13 prints six digit patterns on the left of the centre guard and six on the right - twelve digit patterns in total. But an EAN-13 number is thirteen digits long. Where does the thirteenth digit go?

The natural answer ("just add a thirteenth digit pattern") would have made EAN-13 longer than UPC-A and incompatible with the millions of UPC-A scanners that were already in service in North America when EAN was being designed. The designers needed EAN-13 to be a strict extension of UPC-A - same overall width, same module layout, same guard patterns - while still carrying a thirteenth digit.

The trick

The six left-half digits in an EAN-13 can each be encoded with one of two module patterns : the L-code (odd parity) or the G-code (even parity). Both patterns encode the same digit value 0-9 - but a scanner can tell them apart because their bit patterns are different (G is the R-code reversed).

So a scanner reading an EAN-13 sees, for each of the six left-half digits, both a value (which digit 0-9) and a parity (L or G). The six L/G choices across the left half form a sequence - for example, L L L L L L or L G L G G L. There are 64 possible six-element sequences of L/G, but only ten of them are valid EAN-13 sequences.

Each of those ten valid sequences corresponds to one value 0-9 of the implicit leading (13th) digit. The scanner reads the data digits from the bar patterns and recovers the 13th digit from the L/G sequence.

The parity selection table

The complete table, indexed by the value of the leading (13th) digit. Source: ISO/IEC 15420 Table 4.

Reading the rows: if the leading digit is 5, the six left-half digits are encoded (in left-to-right order) as L G L L G G. The scanner sees the bar patterns, recognises which L-code and which G-codes appear in which positions, looks up the row, and reports the 13th digit as 5.

Why UPC-A is automatically a valid EAN-13

Row 0 of the parity selection table is L L L L L L - every left-half digit is L-encoded. But that is exactly how UPC-A is laid out - UPC-A always uses L-codes on the left and R-codes on the right with no parity choice.

So when a UPC-A symbol is read by an EAN-13 scanner, the scanner sees six L-codes on the left, decodes the parity sequence as row 0, and reports the leading digit as 0. The 12-digit UPC-A is treated as a 13-digit EAN-13 with leading digit 0 - no other change required. This is why GTIN-12s (UPC-A) are always written as GTIN-13s with a leading zero in modern GS1 systems.

Worked decode example

Take the EAN-13 from the construction tables - 5901234567893. The 12 digits that appear in the bar pattern are 901234 on the left and 567893 on the right. The leading digit 5 is the one carried implicitly by parity.

Look up row 5 in the table: L G L L G G. That tells the encoder to render the six left-half digits as:

On decode the scanner does it the other way: it reads each 7-module pattern, checks both the L-table and the G-table to identify the digit, and records the L/G choice. After six digits it has the sequence L G L L G G - which the parity table maps back to leading digit 5.

Why it's robust

Parity selection has a useful built-in error-detection property. Each L/G choice carries one bit of information (L = 0, G = 1), so the six-bit sequence has 64 possible values but only ten are valid 13th-digit values. The other 54 sequences are impossible - if a scanner reads a parity sequence not in the table, the symbol is rejected as corrupted. This catches most multi-bit read errors in the left half before they reach the check-digit check.

Key standards

Related