Barcode Scanner Emulator
How Barcode Scanners Work
A barcode scan looks instant, but it involves four distinct stages between the physical barcode and the character that lands in your application. Understanding each stage makes scanner-related bugs much easier to diagnose.
The four stages of a barcode scan
1. Illumination and image capture
Laser scanners sweep a beam across the barcode and measure reflected light intensity. Imager-based scanners (most modern handheld and phone-camera scanners) capture a 2D image of the barcode using a small CMOS sensor, similar to a low-resolution camera.
2. Decoding
Onboard firmware analyzes the bar widths (or the 2D image, for QR/Data Matrix codes) and decodes them into the original digital payload, using the algorithm for the specific symbology — Code 128, Code 39, EAN-13, QR, and so on. This all happens inside the scanner itself, before any data reaches your computer.
3. Communication
The decoded payload is transmitted to the host computer. The transport is usually USB, and the vast majority of consumer and industrial scanners present themselves to the OS as a USB HID keyboard device rather than a custom USB class. Some scanners support alternate modes such as USB serial (COM port emulation) or Bluetooth HID, but keyboard-emulation mode is the default on nearly every scanner sold today.
4. Application input
Because the scanner is acting as a keyboard, the operating system delivers the payload as a sequence of key events to whatever application currently has keyboard focus. Your application never talks to the scanner directly — it just receives keystrokes, exactly as if someone had typed them very quickly.
Why most scanners behave like keyboards
HID keyboard mode is the default configuration on almost all commercial barcode scanners because it requires zero driver installation. Any OS that supports a USB keyboard supports the scanner out of the box.
USB keyboard emulation means the scanner's firmware maps each decoded character to the USB HID keycode a keyboard would send for that character, then transmits standard HID keyboard reports over the USB interrupt endpoint.
Why this matters for testing: since the scanner is indistinguishable from a keyboard at the application layer, you can test a large part of scanner-driven behavior just by typing quickly into a focused field, or by using a browser tool that inspects keyboard events (see the tools linked below).
ENTER and TAB suffixes
Most scanners are configured to append a suffix keystroke after the decoded payload, most commonly ENTER (carriage return, 0x0D) but sometimes TAB (0x09) or a custom sequence. This exists so the receiving application can tell where the scanned value ends without needing a timeout — the suffix acts as a submit signal, similar to pressing Enter after typing into a text field.
Scanner timing
A scanner transmits an entire barcode payload in well under a second, often with gaps of a few milliseconds between characters. A human typing the same string usually has gaps of 100–300ms or more between keystrokes. This timing difference is the basis for "scanner detection" logic in many POS and inventory applications, which watch for unusually fast input bursts followed immediately by a suffix key.
For your application, this means: if you want to differentiate scanner input from manual typing, measure the time between keystrokes rather than trying to inspect any special flag, because standard browser keyboard events carry no information indicating the input source.
Try it yourself
Use the Barcode Input Tester to scan a real barcode and see the captured value, timing, and suffix detection in real time. For a deeper dive into keyboard wedge behavior specifically, continue to HID Keyboard Wedge Explained.