Barcode Repair Tool

Why check digits make repair possible

Every GTIN ends with a check digit calculated from all the others. The GS1 algorithm multiplies each digit by alternating weights of 3 and 1, starting from the right of the payload, sums the results, and takes the number that rounds the total up to the next multiple of 10. That gives every non-check digit exactly one correct check digit it pairs with. Change any single payload digit and the expected check digit changes too.

That tight coupling is what makes repair work at all. If you know the check digit and all but one payload digit, you can reconstruct the missing one with a ten-way brute force: try 0 through 9 at the unknown position, compute the resulting check digit, keep the one that matches. Because the arithmetic is linear mod 10, exactly one of those ten attempts will succeed. Never zero, never two.

Two unknowns give you about 10 valid candidates out of 100 combinations, since one in ten satisfies the check digit equation. Three unknowns give you about 100 out of 1,000. You can see the relationship in the visualiser below: hover any digit to watch how changing it shifts the check digit. Every alternative value produces a different result, which is exactly why the brute force works.

When to use this tool

Barcode repair is an unglamorous problem that shows up in a few distinct places. Each has its own texture, but they share the same underlying need: you have most of a GTIN, you need the rest, and retyping blindly isn’t an option.

Warehouse receiving and returns

Cartons get scuffed in transit. A forklift fork catches a label, a conveyor belt rubs one corner thin, a puddle takes out two digits. Receiving staff don’t have time to call the supplier for every damaged label, and rescanning isn’t an option if the symbol itself is gone. Typing in everything you can read plus a wildcard for each smudge takes seconds, and in the common one-smudge case the answer is unique.

OCR cleanup pipelines

OCR on receipts, invoices, or scanned documents is good enough to recognise most digits and bad enough to occasionally miss one. A typical OCR stage emits a confidence score per character; anything below the threshold becomes a ?, and the whole string flows into this tool. The valid-check-digit constraint acts as an automatic error-correcting code. OCR engineers sometimes call it “free redundancy”, since they didn’t have to add it themselves.

Damaged retail labels

Shelf stickers get peeled. Promo labels cover part of the original code. Customers at the till pull old labels from clothes. Any time a human needs to key a GTIN into a cash register or inventory system and the label is partially unreadable, this tool beats guesswork.

Data-entry cleanup

Sometimes the problem isn’t a physical label at all. It’s a legacy spreadsheet where the last digit was dropped by a mangled CSV export, or an order form where someone wrote the GTIN by hand and their 3s and 8s are indistinguishable. A wildcard in the problem position plus the rest of the digits resolves it in one keystroke.

Limits and edge cases

It’s worth being explicit about what this tool does not do, because honesty up front saves everyone a round trip.

• More than 3 unknowns is out of scope.The brute-force space stays manageable through 3 (up to 1,000 combinations, ~100 valid candidates) but explodes from there. Four unknowns gives you 10,000 combinations and around 1,000 valid candidates. Nobody’s going to scan that list productively.
• Non-GTIN identifiers aren’t supported. SSCC-18, GLN-13, ITF-14 (structurally the same as GTIN-14 so it works), ISBN-10 (mod-11, different algorithm), and other identifiers either use different check digit schemes or carry different semantic constraints. We’ll build dedicated tools for them rather than bending this one to fit.
• Label context doesn’t factor in.The tool doesn’t know your company prefix, your supplier list, or your product catalogue. If you have that context elsewhere, use the candidate list as a shortlist to cross-reference.
• No OCR or image upload. The input is always text. If your workflow starts with a photo, run it through an OCR pipeline first and feed the uncertain characters here as wildcards.
• Padding is deliberately missing in tolerant mode. Tolerant mode strips stray characters (dashes, spaces, dots) but doesn’t pad short inputs with leading zeros. Padding would fabricate known-good digits, which is exactly wrong for a repair tool: every digit the tool treats as known actually has to be known.

The algorithm, in plain English

Under the hood the tool does the simplest thing that works. Given your input, it first normalises * to ? (so both wildcard styles behave identically), strips stray characters if you’re in tolerant mode, and validates the total length against the four legal GTIN lengths of 8, 12, 13 and 14. If anything about the character set or length is off, it refuses to guess and tells you why.

Then it finds the positions of every ?and counts them. Zero unknowns means there’s nothing to repair. More than three means there’s too much to repair. Between one and three, the tool enumerates every combination of digits that could fill those positions (at most a thousand). For each combination it asks the GS1 check digit function whether the resulting GTIN is valid. Valid combinations go into the candidate list; invalid ones are discarded.

There’s no cleverness beyond that. The mod-10 arithmetic is so cheap that even the full 1,000-case search finishes in well under a millisecond; the whole thing runs synchronously on every keystroke with no debounce. The formal spec lives in the GS1 General Specifications, section 7.9, if you want to roll your own.

Frequently asked questions