Processed locally
Your input stays in this browser.
A barcode scanner decodes a symbol by measuring the relative widths of bars and spaces along a scan line, then matching that pattern to the selected symbology's rules. A scan fails when module size, contrast, distance, or angle stop the sensor from measuring those widths reliably, not because the printed data itself is wrong.
What a scanner is actually measuring
A barcode scanner does not 'see' a picture of a barcode the way a person does. A laser or linear-imager scanner samples light intensity along a line crossing the bars and spaces, converts that into a sequence of measured widths, and matches the pattern of widths against the rules of the symbology it has been configured or auto-detected to expect. A 2D imager captures a small area instead of a line and locates the symbol within it before doing the same width measurement in two dimensions. In both cases the sensor is measuring geometry, not reading characters directly, so anything that distorts the measured width of a bar — smudged ink, a scratch, glare, or a printed edge that is not sharp — can turn a technically present symbol into one the decoder cannot resolve.
Laser, imager, or phone camera: different sensors, different limits
A laser scanner sweeps a single beam across the symbol and reads reflected light, which makes it fast and cheap for a flat, printed, high-contrast label at a fixed distance, but it depends on a moving element and generally expects one barcode per pass. A CCD or imager-based scanner captures a still frame instead, which lets it read a code held at an angle, a damaged code with partial redundancy, or a 2D symbol a laser cannot decode at all, at the cost of needing enough illumination to expose the frame properly. A phone camera is an imager in this sense, but it is a general-purpose camera repurposed for the job by software: it has to locate the symbol within a much larger field of view first, which is why phone-based scanning apps usually ask you to fill the frame with the code rather than shoot from a distance.
| Sensor type | Best suited to | Practical limit |
|---|---|---|
| Laser | flat, high-contrast, fixed-distance 1D labels | cannot decode 2D symbols |
| 2D imager | angled, damaged, or 2D symbols | needs adequate illumination for a still frame |
| Phone camera | 2D symbols captured close and centred | weaker at fast or angled 1D capture |
Reading distance and module size are linked, not independent
Every symbology has a minimum element width, often called the module or X-dimension, and a scanner's optics have a working range over which they can resolve that width reliably. Reading distance and code size are not independent settings: a smaller module needs the scanner closer, or needs a lens with a shorter working range and finer resolution, while a larger module can be read from farther away but takes up more label space. Cognex's documentation for its DataMan readers frames this directly through field-of-view and reading-distance diagrams that pair a code's physical size with a supported distance range for a given lens, noting that depth of field is limited by the minimum narrow-bar width for 1D codes and the minimum cell size for 2D codes. Choosing a scanner and a label size without checking that pairing is a common reason a working sample fails once it moves to the real distance on a production line.
Worked example: why the same label reads at 15 cm but not at 60 cm
Take an asset label printed with a module width suited to a handheld scanner used at roughly 15 cm. Moved to a fixed-mount reader positioned 60 cm above a conveyor, the same physical module now occupies a much smaller angle in the sensor's field of view, effectively asking the optics to resolve a narrower element than they were configured for at that distance. The label has not changed; the geometry between label and sensor has. The practical fix is not to make the barcode blurrier by scaling it in a page-layout tool, but to either increase the module width for the new working distance or select a lens and reading-distance combination, following the reader manufacturer's field-of-view documentation, that matches the label as printed. Treat reading distance as a design input decided before the label is finalized, not a variable discovered after installation.
Why a phone camera struggles more with 1D barcodes than QR codes
A phone camera generally decodes a QR code faster and more reliably than a 1D barcode of similar print quality, because a QR code's finder patterns give the software an unambiguous way to locate and orient the symbol from almost any angle, while a linear barcode has no equivalent built-in locator and must be captured close to parallel with a clear sweep across every bar. Motion blur, a shaking hand, or a barcode photographed at a steep angle affects a 1D symbol's readability more than a 2D one at the same distance and light level, because a small rotation changes which pixels fall on which bar in a way the decoding software has to work harder to correct. This is a genuine capability difference, not a preference: an application built around 1D capture on a phone usually adds an on-screen guide rectangle specifically to compensate for the missing locator pattern.
Common scanning mistakes that look like a broken barcode
A frequent cause of a 'scanner is broken' report is not a broken scanner but a code presented at the wrong angle, too close for the lens to focus, or partly outside the reader's field of view. Glare from glossy laminate or a screen is another common cause, since it reduces the contrast the decoder needs between dark and light elements rather than damaging the data itself. A third is symbology mismatch: pointing a scanner configured only for a specific 1D format at a 2D symbol, or vice versa, produces silence rather than an error, which looks identical to a hardware fault from the operator's side. Before assuming a scanner needs repair or replacement, test it against a known-good printed sample at the documented working distance and confirm which symbologies it is actually configured to decode.
What a scanner cannot tell you
A successful decode tells you that the sensor measured a pattern matching a valid symbol; it does not tell you that the decoded value is correct for the item in front of the scanner, that the receiving software will accept the string it produces, or that the same code will read reliably under different lighting or at a different distance tomorrow. It also cannot compensate indefinitely for print quality: a module printed narrower than the format's minimum, or ink spread that merges two adjacent bars, will eventually defeat even a well-specified reader regardless of its reading-distance range. Match the reader's documented field of view and reading distance to the label as printed, following the manufacturer's own diagrams for that pairing, rather than treating one successful test scan as proof the deployment will hold up.
Configuring a scanner for more than one symbology at once
Most configurable scanners can be set to auto-discriminate between several symbologies in one deployment, trying each enabled format's decoding rules against the captured pattern until one matches. This is convenient when a site genuinely receives a mix of EAN-13 retail labels and internal Code 128 asset tags, but every symbology left enabled that is not actually in use adds a small chance of a rare false-positive match, where a damaged or unrelated pattern happens to satisfy a different format's checksum by coincidence. A scanner restricted to only the symbologies a site actually uses is both faster, because it has fewer rule sets to try, and safer, because it cannot misreport a stray pattern as a valid code in a format nobody printed. Review the enabled symbology list on a shared or handed-down scanner rather than assuming its factory defaults match the current deployment. This matters more than it sounds, because a scanner purchased secondhand or reassigned from another department often keeps its previous owner's configuration until someone deliberately opens its settings and checks, and a factory-default configuration frequently ships with every symbology the hardware supports switched on, on the assumption that a purchaser will narrow it down for their own use case. A quick way to audit this without digging through a menu system is to print a small set of control symbols in every format the site genuinely uses, scan each one, and confirm the reader both accepts it and reports the correct symbology identifier alongside the decoded text; any format that reports successfully but was not printed deliberately signals a configuration broader than the deployment actually needs. Cognex: DataMan Field of View and Reading Distance Diagrams is the named source for the current external rule or product behaviour.