How GTIN check digits are computed

Every number this site encodes as EAN-13, EAN-8, UPC-A or ITF-14 ends in a check digit, and each one is produced or tested by the same small routine in the site's verification layer. This guide shows that routine at work: the rule, the arithmetic on a cited reference number and on an invented one, how the validator decides between computing and verifying, what a mismatch looks like, and the errors the rule cannot see. Every figure derived from them is computed when the page is built by the code that runs in your browser; only the cited and invented inputs are typed, and each is labelled. This is one of the guides to the verification layer.

The rule, as this engine applies it

The GTIN check digit is a modulo-10 digit over the data digits — every digit except the last. The engine walks the data digits and multiplies each by a weight of 3 or 1, alternating, with the weights anchored at the right: the rightmost data digit always receives 3, the one before it 1, and so on leftwards. It adds the products and takes the sum modulo 10. The check digit is whatever brings that sum up to the next multiple of ten — written as (10 − sum mod 10) mod 10, so a sum that already ends in zero gets check digit 0 rather than 10.

The routine is length-agnostic: one function serves GTIN-8, GTIN-12, GTIN-13 and GTIN-14, and the per-symbology wrappers only enforce the digit count before calling it. And the weights are anchored on the right, not the left — which is why "multiply the odd positions by 3" holds only for some lengths, and why a leading zero changes nothing.

Worked on a cited reference vector

The data digits 400638133393 come from the EAN-13 check-digit walkthrough this site's tests cite (Wikipedia's International Article Number article). The table is the engine's own intermediate values; the check digit comes from the same function the generators call, so the walkthrough cannot disagree with the verdict.

Worked on an invented number

A reference vector proves the engine agrees with published arithmetic; an invented number shows the same mechanics without being mistaken for a product. The data digits 520049871638 were made up for this page and are not claimed as an allocated GTIN.

Change one data digit and the check digit moves with it. Replace the final data digit, 8, with 9 — the position that always carries weight 3 — and the sum rises from 117 to 120. That already ends in zero, so the check digit is 0 and the complete number is 5200498716390. A check digit of 0 is a real check digit, not a missing one.

Why the weights are anchored on the right

Because the weights count from the rightmost data digit, prepending digits never disturbs the weights already assigned. The cited UPC-A walkthrough data (Wikipedia's Universal Product Code article, cited in this site's tests) 03600029145 requires check digit 2; with a leading zero, as the twelve EAN-13 data digits 003600029145, it requires 2 — the same digit, because a zero contributes nothing to the sum whatever weight it receives, which is why a UPC-A is also the EAN-13 form of the same number.

Prepending a non-zero digit is different. Put one in front of the reference vector, making the thirteen data digits of a GTIN-14, 1400638133393, and the new leading digit receives weight 3 and adds to the sum: 92 instead of 89. The check digit becomes 8 rather than 1, giving 14006381333938. Prepend any non-zero digit to the same twelve data digits and the sum, and so the check digit, changes; only a leading 0 leaves both unchanged. The ITF-14 generator recomputes the check digit from the full data string either way.

Compute mode and verify mode

The validator never guesses which job you want; it reads the digit count. The rule under the EAN-13 input states it: 12 digits (check digit computed for you) or 13 digits (check digit verified). Enter the twelve data digits and the engine computes and appends the check digit, saying so in the notes it returns with the payload:

You entered 12 digits — the check digit 1 was computed and appended, making 4006381333931.

The specification it hands onward records the mode as computed. Enter all thirteen and the final digit is verified against the first twelve instead; the mode becomes verified:

You entered all 13 digits — the check digit 1 was verified against the first 12 and is correct.

Any other digit count is refused before any arithmetic runs; 11 digits on the EAN-13 page produce:

A EAN-13 needs 12 digits (check digit computed) or 13 digits (check digit verified) — you entered 11.

Spaces and hyphens are removed before counting — the refusal for non-digit input states that they are ignored: A EAN-13 contains digits 0–9 only (spaces and hyphens are ignored). — so a pasted 4006 3813 3393 1 yields the same payload, 4006381333931. Every other decision the validator makes is reported in a note or an error; the methodology page describes those notes as plain sentences stating what validation did on the way.

A corrupted digit, caught

Take the complete reference number 4006381333931 and mistype one data digit: position 6, the digit 8, entered as 3, giving 4006331333931. The thirteenth digit is still the original check digit, 1, but the first twelve now require 6. The verification routine reports both values and a mismatch; the validator turns that into the error the page shows:

Check digit mismatch: for 400633133393 the final digit must be 6, but you entered 1. Fix the number, or enter only the first 12 digits to have the check digit computed.

Read the error literally. It does not say the thirteenth digit is wrong; it says the final digit does not fit the twelve before it. The engine cannot know which digit was mistyped — here it was the data, not the check — so rewriting the last digit to 6 would manufacture a structurally valid number for a product that does not exist. The flow stops instead: no payload reaches the renderer and no bars are drawn. The required digit is named so you can look for the typo; it is never applied. The check digit calculator follows the same policy, offering a corrected value in its own column rather than writing over the original.

What the rule cannot see

The rule has exact limits, and it is better to know them than to read "verified" as "correct". Changing a single digit changes the weighted sum by one to nine times its weight, and since neither 1 nor 3 shares a factor with 10 that change is never a multiple of ten: every single-digit error is caught. Swapping two adjacent digits a and b moves the sum by 2(a − b), which is a multiple of ten exactly when the digits differ by five.

The invented number 5200498716383 contains the adjacent pair 49. Swap them and the result, 5200948716383, verifies: the first twelve digits require 3 and that is the digit present. The pair 98 differs by 1; swapping those gives 5200489716383, and the engine reports a mismatch — the data requires 5, the number ends in 3.

So a pasted list can pass every check digit and still hide a transposed pair that differs by five: "structurally valid" means internally consistent, nothing more. It also says nothing about ownership — generating an EAN or UPC barcode does not allocate or license the GTIN inside it; that is GS1's role. See Do I need a GS1 barcode? for that question.

One routine, four symbologies

Each tool page enforces its own two digit counts, then calls the routine above; the final digit of each cited example is verified at build time.

The check digit calculator exposes the same routine for any of the four lengths and for a pasted column, where twelve- and thirteen-digit lines are ambiguous; the bulk validation guide explains the explicit modes that resolve it. The EAN-13 structure guide takes the thirteen digits apart — prefix, body, check digit. ISBN-10's mod-11 check character is a different algorithm, covered in the ISBN conversion guide; an ISBN-13 is an EAN-13 and uses exactly this rule.

Check digit FAQ

Math, not optics: this guide, and the tools it describes, verify digits and their mod-10 consistency. Whether a printed symbol scans depends on contrast, size, substrate and preserved quiet zones — test with your own scanner before production or print use. Everything runs locally in your browser; the methodology page draws the full boundary between the renderer and the verification layer.