DeskTest.net
GitHub

Barcode Scanner Test Guide

A reference for the DeskTest.net Barcode Scanner Test. Covers why most scanners are keyboard-wedge devices, how inter-key timing tells a scanner from typing, how to read the symbology and check-digit results, and how to fix scanner configuration.

Open the Barcode Scanner Test →

What does the Barcode Scanner Test check?

Almost every front-desk and retail barcode or QR scanner is a USB keyboard-wedge device: to the operating system it looks exactly like a keyboard, and it "types" the decoded barcode as a fast burst of keystrokes ending in Enter (or Tab). There is no camera feed to sample and no driver to query - the scan simply arrives as text. So the primary test here is keystroke capture plus timing analysis, the same model this site already uses for magnetic-stripe card readers. No plugin, no extension, no upload. The three steps run in order:

  1. Scanner types a barcode. You click into a capture box and scan. The tool records a performance.now() timestamp for every character keystroke and watches for an Enter or Tab terminator. It then computes the average inter-key gap. A wedge scanner delivers characters in a very tight burst - typically under 30 ms per character - so a tight burst with a terminator is flagged as a real scanner, while slow characters are flagged as hand typing. It shows the captured value, character count, total time, and average gap.
  2. Barcode format looks valid. From the captured text alone, the tool recognizes common symbologies by pattern and length: UPC-A (12 digits), EAN-13 (13 digits), EAN-8/UPC-E (8 digits), ITF-14/GTIN-14 (14 digits), alphanumeric Code 128 or Code 39, and longer 2D payloads (QR, Data Matrix, PDF417). For UPC/EAN it validates the GTIN check digit. This step is informational and never a hard failure; an unrecognized format is reported cleanly.
  3. Scanner is configured for this workstation. Confirms the burst ended with Enter (a carriage return) so apps expecting Enter-terminated input auto-submit each scan, and flags common keyboard-layout and leading-zero pitfalls. Guidance, not a pass/fail gate.
Keyboard-wedge is the primary path. If your browser supports the on-device BarcodeDetector API, an optional "Scan with camera instead" button appears as a clearly-secondary fallback for when you do not have a USB scanner handy. It runs entirely on-device; no image or video ever leaves the tab.

When should I run this?

Reading the results

The capture box shows a live readout: the last captured value, a chip that reads Scanner burst (green), Looks hand-typed (yellow), or Waiting, plus character count, total time, average inter-key gap, and the terminator. Each completed scan is added to a list below so you can capture several in a row. The 30 ms threshold is the dividing line: below it with a terminator is a scanner; above it, or with no terminator, is treated as typing.

The symbology step names the most likely format and its dimension (1D or 2D). For UPC-A, EAN-13, EAN-8, and GTIN-14 it computes the GTIN check digit and reports Valid or Invalid. For alphanumeric or 2D codes there is no fixed check digit to verify, so it reports Not applicable. Because a wedge scan hides the underlying bar pattern, symbology is a best-effort guess from the text and never fails the test.

Each row has a status badge: Pending (gray), Running (yellow), Pass (green), Partial (yellow), or Fail (red). Only the capture step can hard-fail (nothing scanned, or cancelled); the format and config steps top out at Partial because they are informational. On fail or partial the row expands with a diagnosis and a numbered checklist. The verdict panel at the top names the most likely cause and a recommended next step.

Copy Diagnostic Report copies a plain-text report: browser user-agent, platform, every captured value with its timing and terminator, the detected symbology and check-digit result, and the diagnosis tag from each step. Paste it into a ticket.

Common failures and fixes

The tool produces a named diagnosis for every path. Each maps to a fix. In step order:

no-capture: nothing reached the capture box

You clicked Done without any characters being captured. The scan never became keystrokes the page could see.

  1. Focus was not in the box. Click directly inside the capture box first, then pull the scanner trigger. If focus is on the address bar or elsewhere, the keystrokes go nowhere.
  2. The scanner is not in USB HID keyboard mode. Many scanners default to, or were set to, USB-COM/serial, SNAPI, or IBM Hand-held mode. Re-scan the "USB HID Keyboard" (or "USB Keyboard Wedge") configuration barcode from the vendor manual. Honeywell, Zebra, and Datalogic each print this in the quick-start sheet.
  3. It is a driver, cable, or port problem. Open a plain text editor and scan. If no text appears there either, the issue is below the browser: try another USB port, another cable, and confirm the device enumerates in the OS.
  4. Bluetooth scanner not paired. Confirm it shows as a connected keyboard in the OS Bluetooth settings before scanning.

looks-hand-typed: characters arrived too slowly

Something reached the box, but the average inter-key gap was above the 30 ms scanner threshold, or there was no Enter/Tab terminator. Two cases:

  1. You typed it. The tool is doing its job - human typing is far slower than a wedge burst. Rerun and use the actual scanner.
  2. The scanner has an inter-character delay set. Some scanners ship with a "typewriter" or inter-character delay (5-20 ms per character) so slow legacy apps do not drop characters. That delay pushes the gap over the threshold. Scan the vendor barcode to set inter-character delay to 0 ms, then retest. Also plug the scanner directly into the machine - long USB extension runs or a saturated hub can pace out HID reports.

check-digit-fail: GTIN check digit did not validate

The value was recognized as a UPC/EAN/GTIN by length, but the last digit did not match the computed check digit. The scan itself was clean; the digits are the issue.

  1. Leading-zero conversion. UPC-A is 12 digits and EAN-13 is 13. Scanners can add or strip a leading zero when converting between them, which shifts the check-digit math. Match the scanner's "UPC-A to EAN-13 / add leading zero" setting to what your app's product lookup expects.
  2. Check digit transmitted separately or stripped. Some profiles omit the check digit from the transmitted text or send it as a separate field. Enable "transmit check digit" if your app validates it.
  3. Bad label. A hand-printed or damaged label can decode to invalid digits. Scan a known-good retail barcode to rule the label out.

tab-terminated / no-terminator: suffix is not Enter

The scan was clean but did not end with Enter. Whether that matters depends entirely on the receiving app.

  1. Tab terminator. Fine for multi-field data entry, where each scan should advance to the next field. But an app expecting Enter will not auto-submit. Reprogram the suffix to CR (Enter) if needed.
  2. No terminator. Many apps need a terminator to know a scan is complete. Program a CR (Enter) suffix - most vendors have a single "Add CR Suffix" configuration barcode. Leave it off only if your app parses raw streamed text.
  3. Wrong terminator for the app. Some web apps want Enter, some kiosk apps want Tab, a few want CR+LF. Set the suffix to match the specific app, not a generic default.

For IT admins

A keyboard-wedge scan is shaped at three layers: the scanner firmware (symbologies, prefix/suffix, inter-character delay, keyboard-country profile), the OS (keyboard layout, HID driver, accessibility filters), and the app (focus, field mapping, terminator expectation). This tool sees the app layer's view of the text, but the pattern tells you which lower layer to adjust.

Standardize the wedge profile. For each scanner model in the fleet, keep the exact configuration-barcode sequence in your runbook: USB HID Keyboard mode, US (or your local) keyboard country, CR suffix, inter-character delay 0 ms, and the specific symbologies you use enabled (disable the rest to cut misreads). A single "restore factory defaults then apply profile" sheet per model makes re-imaging a swapped unit a 20-second job.

Keyboard country vs OS layout. A wedge scanner emits scancodes as if typed on the keyboard country it is programmed for. If the scanner is set to US but the workstation runs a non-US layout (or vice versa), digits usually survive but symbols and letters in Code 39/128 can transpose. Set both to the same layout. For multi-region deployments, prefer scanners set to the workstation's layout rather than assuming US everywhere.

Leading zeros and GTIN normalization. Decide once whether your product database keys on GTIN-13 or GTIN-14 and set every scanner's UPC-A/EAN conversion the same way. Mismatched leading-zero handling is the single most common cause of "scans but the lookup misses" tickets. This tool's check-digit result surfaces the mismatch immediately.

Accessibility filters. Windows Filter Keys can drop keystrokes below its hold threshold, which mangles a fast wedge burst and looks exactly like a flaky scanner. Push Sticky Keys, Filter Keys, and Toggle Keys off on shared workstations via Group Policy. A remapper (PowerToys Keyboard Manager, AutoHotkey, SharpKeys) can also swallow or rewrite characters mid-burst; keep shared tills free of them.

Behind the scenes

The capture box is an ordinary text input. A capture-phase keydown listener records performance.now() for each character-producing key (event.key.length === 1), ignoring modifier-only events like Shift so a Shift+digit symbol counts once. When Enter or Tab arrives, the handler calls preventDefault() (so Tab does not move focus off the box and Enter does not submit any form), reads the input value as the barcode, and finalizes the scan. The average inter-key gap is the total span from first to last character divided by the number of gaps.

The 30 ms threshold is deliberately conservative. Real wedge scanners emit characters single-digit milliseconds apart; even a very fast typist rarely dips below ~90 ms sustained. Anything under 30 ms per character with a terminator is, in practice, a machine. A scanner with a configured inter-character delay can cross above the line - that is a real configuration finding, not a false negative, and the tool names it as such.

Symbology recognition works only from the decoded text, because a keyboard wedge never exposes the bar pattern. Length and character set map to the likely 1D symbology; the GTIN check digit is computed with the standard alternating 3-1 weighting (rightmost data digit weighted 3), which unifies UPC-A, EAN-8, EAN-13, and GTIN-14. Longer or non-numeric payloads are reported as alphanumeric 1D or 2D. Because two different symbologies can encode the same characters, this is labeled a best guess and never fails the run.

The optional camera path uses the browser's on-device BarcodeDetector with getUserMedia, polls a video frame a few times a second, and stops the camera on the first detection (a one-shot to avoid duplicates), with a hard 60-second safety cap. Every MediaStream track is stopped on completion, on reset, and on page unload.

Nothing leaves the browser tab. No keystroke, no captured value, and no camera frame is logged to a server, and there is no telemetry. The report is built on Copy from in-memory state, and the page discards everything on reload. Open DevTools, Network tab, and confirm: no outbound requests while the test runs.