Keyboard Tester

What a keyboard tester actually checks

When a key feels dead, types the wrong character, or fires twice, the question is whether the fault is the hardware, the layout mapping, or a stuck modifier. A keyboard tester answers that by listening to the raw KeyboardEvent your browser receives and showing you exactly what arrived. Press a key and it lights up green on an on-screen QWERTY layout; the event's properties appear in a details panel; and a running log records every press and release with a timestamp. If a physical key produces no event at all, you've found a hardware problem. If it produces the wrong key value, you've found a layout or remapping issue. The tester separates those cases cleanly.

How it tracks tested keys

Here's the design detail that matters: the tester highlights keys by their physical position, using the event's code property, not the character produced. code identifies the key on the board — KeyA, Digit1, ShiftLeft — independent of your keyboard layout or whether Shift is held. The key property, by contrast, is the character that results: pressing the same physical key gives a or A depending on Shift. By keying the green highlight on code, the tester correctly marks a physical key as "tested" no matter which character it emitted, which is exactly what you want when checking that every switch on the board works. A counter shows how many of the layout's keys you've covered.

The event properties, and which ones still matter

The details panel exposes nine fields straight from the KeyboardEvent:

The split between key/code and the legacy keyCode family is worth internalising. If you write keyboard-handling code, the deprecated trio (keyCode, charCode, which) can return inconsistent values across browsers; event.key and event.code are the reliable, standardised replacements. Seeing all of them at once makes the difference concrete.

A worked example

Click the capture area to give it focus, then press Shift + A. The details panel reports key = "A" (uppercase, because Shift is down), code = "KeyA" (the physical key, unchanged), and shiftKey = true. On the visual layout, both the A key and the left Shift key turn green and stay green. The event log records a keydown for Shift, a keydown for A tagged "Shift", then keyup events as you release — each with a clock timestamp. Release everything and the keys remain green, because they've been marked as tested. This is how you confirm a chord like Ctrl+Alt+Delete registers all three modifiers.

Practical use cases

• Buying a used or mechanical keyboard — press every key to confirm none are dead before the return window closes.
• Diagnosing a sticky or chattering key that registers twice; the timestamped log shows duplicate keydowns.
• Checking modifier keys after a spill or repair — verify both Shifts, both Ctrls, and the Windows/Command key all fire.
• Web development — look up the exact key and code strings to handle in your event listeners.

Tips for accurate testing

• Click the capture area first. The tester only receives key events when that area has focus; if nothing lights up, you haven't clicked in yet.
• Test modifiers in combination. A key that works alone but not in a chord points to a specific switch or rollover limit.
• Use Reset All between sessions to clear the green highlights and the log so a fresh test isn't confused by old data.
• Watch the log for keyup. A missing keyup after a keydown can indicate a key that physically stuck down.

Common mistakes and limitations

• Expecting every F-key and shortcut to register. The tester calls preventDefault() to stop the browser acting on keys, but some combinations — F5 refresh in certain browsers, the OS-level Command+Tab or the Windows key — are intercepted before the page ever sees them. That's a browser/OS limitation, not a broken key.
• Confusing layout mismatches with hardware faults. If a key produces the wrong character but still fires an event, the switch works — your software keyboard layout is mapping it differently.
• Reading too much into the legacy codes. keyCode and friends are deprecated; prefer key and code when interpreting results.
• Forgetting n-key rollover limits. Cheaper keyboards can't report many simultaneous presses; if a third or fourth key in a chord doesn't appear, the keyboard's hardware — not the tester — is the bottleneck.

Privacy

Every keystroke is read and displayed entirely within your browser. Despite the "key logger" style display, nothing you press is transmitted or stored anywhere — the log lives only in the page and disappears when you reset it or close the tab.