A Shopify barcode that will not scan: the five causes

1. The check digit does not match

The last digit of an EAN-13, EAN-8, UPC-A or UPC-E is not part of the number — it is computed from the digits before it. A scanner recomputes it and rejects the read when it disagrees. A code with a wrong check digit will scan on nothing, reliably, forever.

It usually means the code was mistyped, or that it was truncated somewhere on the way in. Worth knowing: a lost leading zero always produces a wrong check digit too, so if you see both, fix the front and the back fixes itself.

2. The value is the wrong length for its symbology

EAN-13 wants thirteen digits, EAN-8 wants eight, UPC-A twelve, ITF an even number. A twelve-digit "EAN-13" is not a short EAN-13, it is not an EAN-13 at all, and most encoders will refuse it rather than pad it. Some apps pad it anyway and print something a scanner reads as a different product.

3. There is a character in it you cannot see

This is the one that wastes the most time, because the code looks perfect on screen. The usual suspects, in the order they show up:

• A non-breaking space (U+00A0) pasted in from a web page or a PDF.
• A zero-width character (U+200B) from a spreadsheet or a CMS.
• A Unicode dash (U+2013) where a hyphen was meant, courtesy of autocorrect.
• Full-width digits from a CJK keyboard layout.
• A Cyrillic or Greek letter that is visually identical to a Latin one — А is not A.

A numeric symbology cannot encode any of them, so either the encoder refuses the code or it silently drops the character and prints a different number than the one in your catalog. Markio names the offending character by its Unicode code point, because printing it would just show you the same invisible thing again.

4. The symbology cannot carry that value

Not every code fits every format. A value with letters in it cannot be an EAN. A GS1-128 with an application identifier that is not a real GS1 AI will encode, and will then be rejected by anything that validates it. And past about 48 characters a linear symbol is simply wider than any label you would print it on — the bars get narrower until the scanner cannot resolve them.

5. The bars are printed too narrow

The first four causes are in the data. This one is in the print, and it is the one people reach for first, usually too soon.

Every linear barcode has a narrow bar width — the width of its thinnest element. A scanner needs that element to be a couple of its own pixels wide. Shrink a EAN-13 to fit a 25 × 15 mm label and the narrow bar drops below what a cheap scanner resolves; the code is correct, the print is legible to a human, and nothing reads it.

Three practical rules:

• Never let the printer scale. "Fit to page" in the print dialog is the single most common cause of an unreadable label. Print at 100%, at the exact size of the stock in your printer.
• Give it quiet zones. The blank margin either side of the symbol is part of the symbol. Crowding it with text breaks the read.
• Print darker, not smaller. On a thermal printer, bars that bleed into each other read as badly as bars that are too thin.

Markio warns you at design time when a barcode element's narrow bar falls below a safe width for the label size you chose, rather than letting you find out at the counter.

How to tell which one you have, in two minutes

1. Does it scan anywhere? Point the scanner at the same code printed from another source — a phone screen, a test print at double size. If it reads there, the data is fine and the cause is number five.
2. Does anything read it? If no scanner reads it at any size, the data is wrong: causes one to four.
3. Run the audit. Markio checks every code in the catalog against its symbology and names which of the four it is, per variant, with the exact character or digit at fault.
4. Scan the printed label back. Scan verification tells you which variant the printed code really identifies — which also catches the case where the label scans perfectly and points at the wrong product.