How to read the three values
A key press hands the browser three identifiers, and knowing which one to trust saves a lot of false
diagnoses. event.code is the physical position — it never changes with
keyboard language. event.key is what that position produces under your
current OS layout. keyCode is a deprecated numeric ID that old software
still uses. The tester shows all three for every press:
| You press | event.key | event.code | legacy keyCode |
|---|---|---|---|
| A on a US layout | a (A with Shift) | KeyA | 65 |
| The QWERTY-Q position on French AZERTY | a | KeyQ | 65 (follows the letter, not the position) |
| Left Shift | Shift | ShiftLeft | 16 |
| Numpad 7 with NumLock on | 7 | Numpad7 | 103 |
| Spacebar | " " (a space character) | Space | 32 |
The practical rule: hardware problems live in event.code, layout problems live in
event.key. A key that produces no event at all is a hardware or driver issue; a key
that produces the right code but the wrong character is an OS keyboard-layout setting.
Keyboard sizes: what your board should have
Before declaring keys "dead", check they exist on your form factor. The tester draws a full-size ANSI board; if you own a tenkeyless or 60% keyboard, whole blocks will stay grey — that is correct, not a failure. Use the Show untested keys button to see exactly what has not registered, and ignore the sections your board physically lacks.
| Size | Typical keys | What is missing vs full-size | Expect grey in the tester |
|---|---|---|---|
| Full-size (100%) | 104 | Nothing | Nothing — every key should light |
| Tenkeyless (TKL / 80%) | 87 | Numpad (17 keys) | The right-hand numpad block |
| 75% | 80–84 | Numpad; nav cluster squeezed into one column | Numpad + a few nav keys, model-dependent |
| 65% | 66–68 | Numpad and F-row; keeps arrows and a few nav keys | Numpad, F1–F12, most nav |
| 60% | 61 | Numpad, F-row, arrows and nav — all reached via Fn layers | Everything right of Enter plus the F-row |
On compact boards, keys reached through an Fn layer report the code of the key they emulate: on a 60%
board, Fn+1 sends F1, so the F1 cell lights even though there is no physical F1 key. That
is how you verify Fn layers actually work.
Three worked examples
1. Finding a dead key
You suspect the E key. Press W, E, R in order: W lights, R lights, E stays grey and the readout shows
no event for it. That is a hardware-side failure — switch, solder joint or matrix trace — because the
browser received literally nothing. Counter-case: E lights up green and the readout says
event.code: KeyE, but nothing appears in your text editor. Then the keyboard is fine and
the culprit is software: a remapping tool, a language setting, or the editor itself.
2. Measuring rollover
In the Rollover tab, hold W, then add A, S, D, Space and K one at a time — six normal keys, no modifiers. The "held now" count climbs 1 → 2 → 3 → 4 → 5 → 6. Now add J while everything stays down: if the count refuses to pass 6 no matter which extra key you choose, the board is operating as 6-key rollover — normal for the standard USB protocol. Keep modifiers out of that count: Shift, Ctrl, Alt and Win travel in a separate bitmask of the USB report, so the same 6KRO board still reaches 8 when you add two of them on top of the six — expected, not proof of NKRO. If some specific trios (often three keys forming an L-shape on the board) cap the count at 2 while other trios reach 3, that is a matrix limitation, the thing gamers call ghosting or blocking — full explainer here.
3. Catching a chattering switch
Your document sometimes shows "tthe" when you typed "the". In the Chatter tab with the default 80 ms
threshold, type a few normal sentences. A healthy board produces zero flags because even fast typing
leaves >100 ms between repeats of the same letter. A worn switch produces flags like
KeyT — 28 ms: no human intent fires the same key twice in 28 ms, so that is contact
bounce escaping the firmware's debounce. Details and fixes on the
keyboard chatter test page.
What this test can and cannot tell you
- It can prove a key's full path works: switch → controller → USB/Bluetooth → OS → browser.
- It can distinguish hardware failures (no event) from layout problems (wrong character, right code).
- It can catch chatter and measure real rollover as delivered to applications.
- It cannot see the Fn key, power/eject keys, or anything the keyboard controller keeps to itself.
- It cannot block reserved shortcuts (Ctrl+W, Win-key combos) — those keys register first, then the OS acts.
- It cannot tell whether a fault is the keyboard or the port — swap USB ports or test the same board on another machine to split that.
Common uses
- Pre-purchase / warranty checks: run every key on a second-hand or newly delivered keyboard in under two minutes.
- After a spill: find exactly which keys stopped registering instead of guessing while typing.
- Laptop diagnostics: separate a dead row (ribbon cable) from single dead keys — the laptop keyboard test covers laptop-specific quirks like Fn lock and media rows.
- Gaming setups: verify your movement-plus-ability combos all register with the rollover test.
- Double-typing complaints: confirm chatter objectively with the chatter detector before opening a switch or filing an RMA.
- Spacebar wear: the space key takes more presses than any letter — give it a dedicated run on the spacebar test.