Barcode Prints But Won’t Scan: The 12 Causes, In the Order You Should Check Them
A barcode that prints but will not scan has a finite set of causes. This is the diagnostic order that finds the fault fastest — from bad data and missing quiet zones to print contrast and scanner config.

A barcode that prints perfectly but will not scan is one of the most common — and most frustrating — problems in labeling. The good news is that the causes are finite, and they fail in a predictable order. If you check them in the right sequence, you will usually find the fault in under ten minutes instead of re-printing labels three times.
This is the diagnostic order I use, arranged so that the cheapest and most common causes come first and the expensive hardware questions come last. Each cause links to the deeper guide where one exists.
The diagnostic order that saves hours
Every "prints but won't scan" failure lands in one of eight layers. Working top-to-bottom means you check the things that cost nothing to fix before the things that cost money:
- Data — is the encoded value even correct?
- Symbology — is the scanner reading the same barcode type you think it is?
- Quiet zone — is there blank space around the symbol?
- Contrast — are the bars dark enough against the background?
- Size — is the symbol large enough to resolve?
- Print — did the printer actually render the bars cleanly?
- Surface — is the label or product reflecting or distorting the symbol?
- Scanner — is the reader configured and pointed correctly?
The moment you frame it this way, most people realize they have been testing layer 8 (buying a new scanner) while the fault was on layer 1 (a stray leading zero).
The 12 causes at a glance
| # | Cause | Symptom | Fastest fix |
|---|---|---|---|
| 1 | Wrong or truncated data | Scans, but shows the wrong number | Re-check the source column and value |
| 2 | Leading zeros eaten | UPC/EAN reads one digit short | Format the cell as text (see below) |
| 3 | Symbology mismatch | Scanner beeps for other codes, not yours | Turn on the correct symbology |
| 4 | Bad check digit | Symbol looks right, never decodes | Recalculate the check digit |
| 5 | Quiet zone too small | Intermittent or angle-dependent reads | Add blank margin (10× X-dimension) |
| 6 | Low print contrast | Washes out under the scanner | Darken bars, lighten background |
| 7 | Symbol too small | Reads up close only, or not at all | Increase the magnification |
| 8 | Dirty or worn print head | Vertical white streaks through bars | Clean or replace the print head |
| 9 | Print speed too high | Fuzzy or smeared bar edges | Reduce print speed |
| 10 | Reflective or curved surface | Scans flat, fails on the product | Laminate, or re-orient the symbol |
| 11 | Truncated, stretched, or scaled symbol | Scans the original, not the copy | Regenerate at true size, no stretch |
| 12 | Scanner misconfiguration | Nothing scans reliably | Check symbology, prefix/suffix, mode |
Each of these deserves more than a one-liner, so let me walk through the layers that cause the most real-world failures.
Layer 1 — Data: the value is wrong before it is ever printed
The most common cause of "won't scan" is, surprisingly, not a printing problem at all — it is that the barcode encodes the wrong value, or a value the scanner correctly reads but your system then rejects.
Three data faults dominate:
- Leading zeros lost. A UPC-A or EAN-13 code like
012345678905gets stored in a spreadsheet as the number12345678905, and the leading zero is silently dropped. The symbol now encodes an 11- or 12-digit string that is not a valid retail code. This is so common it has its own guide: see Excel/CSV leading zeros. - Scientific notation. Long numbers in Excel (anything over 11 digits) get stored in scientific notation and then rounded, which corrupts the value beyond repair.
- Wrong column or field. The label pulls from a spreadsheet where the UPC, SKU, and FNSKU columns are adjacent and someone mapped the wrong one.
The tell-tale sign: the barcode does scan, but the system rejects it, or it scans to a value that looks almost right. If your scanner beeps and shows a number, the problem is in the data layer, not the print layer. There is a dedicated guide for the "scans but rejected" case — scans but rejected: encoded value vs database — for when the symbol reads correctly but the system will not accept it.
Layer 2 — Symbology and check digit
A scanner is not a universal reader. Most retail scanners default to a specific set of enabled symbologies (UPC-A, EAN-13, Code 128, Code 39, and a few others). If you generated a Data Matrix, PDF417, or Code 93 symbol and the scanner has that symbology switched off, it will simply ignore the code.
Two quick checks:
- Does the scanner read a known-good barcode of the same type? If it reads a printed Code 128 label but not your Code 128 label, the problem is in your symbol. If it reads neither, the symbology may be disabled in the scanner.
- Is the check digit correct? Linear symbologies like UPC/EAN and Code 128 use a computed check digit that the scanner verifies on every read. A hand-entered check digit that is off by one produces a symbol that looks perfect and never decodes. Most generators compute it automatically, which is why hand-crafting a barcode from bar patterns is almost always the mistake. See the check-digit glossary entry.
Layer 3 — Quiet zone: the blank space is part of the code
If the symbol scans intermittently, or only when you hold the scanner at exactly the right angle, the most likely cause is a quiet zone that is too small.
The quiet zone is the blank margin on each side of the bars. The scanner uses it to find the start and end of the symbol. If a label border, some text, or the edge of the label crowds it, the scanner either cannot find the start bar or reads the surrounding graphics as part of the code. The fix is trivial and free: add blank space. The rule is 10× the X-dimension on each side for most linear symbologies (9× for UPC/EAN). The full widths are in the quiet-zone guide.
Layer 4 — Contrast: the scanner sees red differently than you do
This is where color becomes a trap. A barcode scanner does not "look" at the symbol the way your eye does — most laser scanners emit red light at about 630–670 nm, and they measure the reflected light. A bar printed in red or orange reflects the red laser almost as well as white paper does, so the scanner effectively cannot see it.
The rule is simple and non-negotiable: dark bars on a light background. Black bars on white are ideal; very dark blue or green can work, but red, orange, yellow, and pink bars generally will not. And the reverse — light bars on a dark background, sometimes called "reversed" or "inverted" — fails on most linear scanners outright. The full explanation, including the print-contrast signal (PCS) that verifiers measure, is in the barcode color guide and the print-contrast glossary entry.
Layer 5 — Size: small is not a virtue here
Every symbology has a minimum practical size, driven by the scanner's aperture (the spot it samples) and the print resolution. A symbol that is too small produces bars that blur together at the scanner, and it fails even though it looks crisp to the naked eye.
The two numbers that matter:
- X-dimension (the width of the narrowest bar) — for most linear symbologies this must stay above roughly 0.19 mm (7.5 mil) for handheld scanners, and above 0.33 mm (13 mil) for many long-range or fixed readers. GS1's General Specifications set a minimum of 0.25 mm (10 mil) for retail.
- Magnification — UPC-A at 100% is 1.469 inches wide; shrinking below 80% is where older scanners start to fail. See the X-dimension and magnification guide.
If you enlarged a barcode in a graphics editor, you may have also degraded it — more on that in layer 6 and in the scaling section below.
Layer 6 — Print quality: the head, the speed, and the resolution
Three printer-level faults account for most of the remaining failures:
- Dirty or worn print head. A single dead pixel or a line of dried ink produces a vertical white streak that cuts through the bars. In thermal printers this shows up as a missing element every few millimetres. Clean the head first; if the streak persists, the head element is dead and the head (or the printer) needs replacing.
- Print speed too high. Thermal transfer printers, especially, smear the bar edges when the speed is cranked up to maximize throughput. Reducing the speed is the single cheapest fix for a barcode that "looks okay but won't verify." There is a dedicated print-speed guide for this.
- Resolution too low. A 203 dpi printer cannot resolve the narrowest bars at small magnifications. If your X-dimension is below the printer's dot pitch, the bars come out irregular. The fix is a higher-DPI printer or a larger symbol.
The definitive way to know whether the print — rather than the data or the design — is the problem is the "screen test" in the scans-on-screen-not-on-print guide: if the same symbol scans from a bright phone screen but not from paper, the printer is the fault.
Layer 7 — Surface: reflectivity, curvature, and lamination
The label is only half the story; what it is stuck to matters just as much.
- Reflective surfaces. A glossy laminate, shrink wrap, or bare metal reflects the scanner's light straight back into the sensor and effectively blinds it. Matte finishes and non-reflective over-lamination fix this.
- Curved surfaces. Wrapping a barcode around a cylinder stretches the bars at the edges, so the scanner reads a distorted width. On a tight radius, orient the bars so they run around the cylinder (the "ladder" orientation) rather than along it.
- Uneven or textured surfaces. Corrugated cardboard, fabric, and rough plastic break up the bars. Use a flat, smooth area or a label with a smooth top layer.
If the symbol verifies on a flat test print but fails on the product, you are in layer 7.
Layer 8 — The scanner itself
Only after you have ruled out layers 1–7 should you blame the reader. Even then, most scanner problems are configuration, not hardware:
- Symbology disabled. As in layer 2 — confirm the scanner is set to read the symbology you are printing.
- 1D-only scanner. A laser scanner reads linear codes but cannot read QR, Data Matrix, or other 2D symbols. If you switched to a QR code and the old laser gun no longer reads it, that is expected.
- Autodiscrimination in noisy environments. Some scanners can be configured to try every symbology, which is slower and, in a mixed-label environment, can produce occasional misreads. Locking the scanner to the one or two symbologies you actually use often improves reliability.
- Prefix/suffix or firmware settings. A scanner configured to append a carriage return, or one running old firmware with a symbology bug, can fail to deliver the value to the host even when it "reads" the code.
For the full matrix of what a phone, laser gun, and imager can and cannot read, see the scanner capability guide.
The three tests that isolate the fault fast
When you are in front of a stubborn label, run these three in order — each one eliminates half the remaining possibilities:
- The screen test. Open the same barcode on a bright phone screen and scan it with a phone app. If it scans, the data and symbology are correct and the fault is in print or surface (layers 6–7). If it does not scan, the fault is in data, symbology, quiet zone, contrast, or size (layers 1–5).
- The known-good test. Scan a barcode you know works — a retail product from your desk, or a professionally printed label. If the scanner reads that but not yours, the problem is your symbol, not the scanner.
- The verifier test. If you print at any volume, a barcode verifier (not a scanner — a verifier) gives you an ISO/IEC grade against the GS1 barcode quality standards. A symbol that grades C or lower will be unreliable in the field; most retailers require Grade B or better. See the verification-grade glossary entry.
