DeskTest.net
GitHub

Card Reader Test Guide

A reference for the DeskTest.net Card Reader Test. Covers why magnetic-stripe readers are keyboard-wedge devices, how the tool reads tracks without ever exposing card data, how to detect an encrypting (P2PE) reader, how to read the verdict, and how to fix reader configuration.

Open the Card Reader Test →

Privacy first: This test reads a real magnetic stripe, so it is built to reveal nothing. The card number is masked the instant it is read (only a leading digit and the last four are shown); the cardholder name, expiry, and service code are redacted entirely; nothing is written to storage; and the page makes no network requests at all. That is the whole point - the site's "nothing leaves your machine, view-source-provable" posture is what lets you safely test a reader with a real card. Use a test or throwaway card anyway.

What does the Card Reader Test check?

Almost every front-desk, leasing-office, and self-storage USB magnetic-stripe card reader is a keyboard-wedge device: to the operating system it looks exactly like a keyboard, and when you swipe a card it "types" the decoded stripe as a fast burst of keystrokes ending in Enter (or Tab). There is no image to sample and no driver to query - the swipe simply arrives as text framed by track sentinels. So the test is keystroke capture plus track parsing plus timing analysis, the same model this site uses for barcode scanners. No plugin, no extension, no upload. The three steps run in order:

  1. Reader sends a swipe. You click into a capture box and swipe. The tool records a performance.now() timestamp for every character keystroke and watches for an Enter or Tab terminator, then computes the average inter-key gap. A wedge reader buffers the whole read and emits it in a very tight burst - typically well under 40 ms per character - so a tight burst with a terminator is flagged as a real swipe, while slow characters are flagged as hand typing.
  2. Tracks decode cleanly (or reader is encrypting). The captured text is parsed for standard tracks - Track 1 starts with %B and ends with ?; Track 2 starts with ; and ends with ?; Track 3 is a second ;...? segment. If a track is well-formed, the reader works and the card number is shown masked. If the output is keyed and non-standard, the tool recognizes an encrypting / point-to-point-encryption (P2PE) reader as a distinct valid outcome.
  3. Reader is configured for this workstation. Confirms the swipe ended with Enter (a carriage return) so apps expecting Enter-terminated input auto-submit each swipe, and flags common keyboard-layout and terminator pitfalls. Guidance, not a pass/fail gate.

How your card data is protected

Because this tool reads real cards, privacy is enforced in code, not just promised in copy:

Still, use a test or throwaway card. You never need a live customer card to test hardware. A gift card, loyalty card, expired card, or hotel key with a magnetic stripe confirms the reader just as well. This tool checks the reader, not the account.

When should I run this?

Reading the results

The capture box shows a live readout: a chip that reads Tracks decoded (green), Encrypted (P2PE) (blue), Bad read / Looks hand-typed (yellow), or Waiting, plus the card brand, the masked Track 1 and Track 2, the terminator, and the swipe timing. Each swipe is added to a list below so you can test several in a row. The 40 ms threshold is the dividing line between a machine swipe and hand typing.

The track step reports which tracks decoded. For a clean read it names the card brand (from the leading digits it already shows), shows the masked tracks, and reports whether the card number passes the Luhn checksum - extra confidence that the decode is intact, never a requirement. For an encrypting reader it reports that no clear tracks were produced, by design.

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 swiped, or cancelled); a clean decode and an encrypting reader both pass. A dirty or partial swipe reports Partial and asks you to swipe again. The verdict panel at the top names the most likely cause and a recommended next step.

Copy Diagnostic Report copies a plain-text, fully masked report you can paste into a ticket: browser user-agent, platform, which tracks decoded, the card brand, the masked track, the Luhn result, the terminator, and the diagnosis tag from each step.

Encrypting (P2PE) readers

Many payment readers use point-to-point encryption: the card data is encrypted inside the read head, the moment the stripe passes, and is never available in the clear on the workstation. Only your payment processor holds the keys to decrypt it. When you swipe into this tool, such a reader does not emit clean %B / ; tracks - it emits a keyed, non-standard payload, often long and hex-heavy.

The tool recognizes that pattern and reports it as a distinct valid outcome: "reader works; output is encrypted, which is expected for P2PE." This is a pass, not a failure. The tool intentionally does not display or try to interpret the encrypted payload. If you see this result on a device you expected to be clear-text, that is normal for a secured payment reader - do not try to switch it into clear-text mode. If you see it on a device you expected to be a plain, unencrypted reader, check whether encryption was enabled in the reader's configuration.

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 swipe never became keystrokes the page could see.

  1. Focus was not in the box. Click directly inside the capture box first, then swipe. If focus is on the address bar or elsewhere, the keystrokes go nowhere.
  2. Partial or crooked swipe. Swipe smoothly and steadily in one pass, stripe facing the read head. A hesitant, slow, or half swipe often produces nothing at all.
  3. The reader is not in USB HID keyboard mode. Some readers default to, or were set to, USB-serial / HID-POS or a vendor SDK mode. Re-scan the "USB HID Keyboard" (keyboard-emulation) configuration barcode from the vendor manual, or set keyboard emulation in the reader's utility.
  4. It is a driver, cable, or port problem. Open a plain text editor and swipe. If no characters appear there either, the issue is below the browser: try another USB port, another cable, and confirm the device enumerates in the OS.

looks-hand-typed: characters arrived too slowly

Something reached the box, but the average inter-key gap was above the 40 ms swipe threshold, or there was no terminator, and nothing decoded. 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 reader.
  2. The swipe was slow or paced out. A very slow hand swipe, a long USB extension run, or a saturated hub can stretch the timing. Swipe more briskly and plug the reader directly into the machine.

bad-read: no clean track decoded

A burst was captured, but the characters did not form a valid Track 1 or Track 2. The reader is likely fine; the swipe or the card is the issue.

  1. Swipe again. Most misreads clear on a second, firmer swipe. Go smoothly, in one pass, stripe toward the read head.
  2. Try a different test card. A worn, scratched, or demagnetized stripe decodes intermittently. A fresh card rules the stripe out.
  3. Check track selection and sentinels. If every card fails to decode, confirm the reader is configured to send standard start/end sentinels and the tracks your app expects, and clean the read head.

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

The swipe decoded cleanly 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 swipe 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 swipe is complete. Program a CR (Enter) suffix - most vendors have a single configuration barcode or utility setting for it. Leave it off only if your app parses the raw streamed text.
  3. Wrong terminator for the app. Some web apps want Enter, some kiosk apps want Tab. Set the suffix to match the specific app, not a generic default.

For IT admins

A keyboard-wedge swipe is shaped at three layers: the reader firmware (track selection, prefix/suffix, sentinels, encryption, 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 reader model in the fleet, keep the exact configuration sequence in your runbook: USB HID Keyboard mode, US (or your local) keyboard country, CR suffix, the tracks your app expects, and encryption on or off per policy. A single "restore defaults then apply profile" sheet per model makes re-imaging a swapped unit a 20-second job.

Know which readers are encrypted. Payment readers are commonly P2PE and will never emit clear tracks; that is correct and required by your processor. Inventory which desks use encrypting readers so a "P2PE detected" result is expected, not a surprise ticket. Never downgrade a payment reader to clear-text to make it "readable."

Keyboard country vs OS layout. A wedge reader emits scancodes as if typed on the keyboard country it is programmed for. If the reader is set to US but the workstation runs a non-US layout, the sentinel and separator symbols (% ^ ; = ?) can transpose and break track parsing even though digits survive. Set both to the same layout.

Accessibility filters and remappers. Windows Filter Keys can drop keystrokes below its hold threshold, which mangles a fast wedge burst and looks exactly like a flaky reader. 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 a password-type text input, so the raw swipe is never shown in the clear. A capture-phase keydown listener records performance.now() for each character-producing key (event.key.length === 1), ignoring modifier-only events like Shift. 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, immediately clears it, parses it into a masked summary, and lets the raw string go out of scope. Nothing raw is ever pushed into the capture list or the report.

Track parsing uses the standard magnetic-stripe format. Track 1 is % + a format code + the primary account number + ^ + name + ^ + expiry, service code, and discretionary data + ?. Track 2 is ; + the account number + = + expiry, service code, and discretionary data + ?. The tool extracts only enough to confirm a well-formed track and to mask the account number; it never keeps the name, expiry, or service-code fields.

The 40 ms threshold is deliberately conservative. A magnetic-stripe reader buffers the full read and emits it as a fast HID burst, single-digit to low-double-digit milliseconds per character; even a fast typist rarely dips below ~90 ms sustained. Anything under 40 ms per character with a terminator is, in practice, a machine.

Encryption detection is a heuristic: a captured burst that produced no clean track, is substantial in length, and is either hex-heavy or lacks any track structure is reported as an encrypting (P2PE) reader. It is labeled as a best-effort recognition, and the tool never displays or interprets the encrypted payload.

Nothing leaves the browser tab. No keystroke, no card value, and no masked summary is sent anywhere, and there is no telemetry. The report is built on demand from in-memory masked state, and the page discards everything on reload. Open DevTools, Network tab, and confirm: no outbound requests while the test runs.