Keyboard tester
Press any key. It lights up on the on-screen keyboard below, mapped to its physical position rather than the character it types, so this works correctly on any keyboard layout. Release it and it stays marked as tested. Hold several keys at once to check for ghosting and see how much rollover your keyboard actually has.
How it works
Every keypress in a browser fires two events, keydown and keyup, and each one carries several ways to identify which key it was. This tool listens for both events on the whole page and reads the one property that stays reliable no matter what language or layout is active: event.code.
event.key vs event.code vs event.keyCode
These three answer different questions, and mixing them up is the single most common bug in keyboard-handling code.
| Property | Answers | Layout-independent? | Example (this key, US QWERTY) |
|---|---|---|---|
event.code | Which physical key, by position | Yes | "KeyQ" |
event.key | What character it produced | No — depends on layout & Shift/AltGr | "q" (or "Q" with Shift) |
event.keyCode | A legacy numeric code | Partially, and deprecated | 81 |
Because this tool is testing physical switches — not typing — it maps every on-screen key by event.code. Match by event.key instead and a visitor on an AZERTY or Dvorak layout would press the key physically to the left of "1" and see a completely different key light up, because that position types a different character on their layout. event.keyCode is included in the live readout only because it's still common in older code and worth recognising, not because it should be used in anything new — the MDN documentation for it opens with a deprecation notice.
The on-screen keyboard
The board renders every key of a full-size keyboard: the function row, the number and QWERTY rows, the navigation cluster (Insert/Home/Page Up and friends), the arrow cluster, and the full numpad. Toggle ANSI (104 keys, the common US layout with one large Enter key) or ISO (105 keys, common outside the US, with an L-shaped Enter and an extra key next to the left Shift) to match your own keyboard's physical shape.
Ghosting, rollover and NKRO — what they mean and why they happen
Most keyboards don't give every key its own wire back to the controller. Instead, keys are wired into a grid — a matrix — and the controller scans it row by row, column by column, dozens of times a second, to work out which keys are currently down.
That scan is unambiguous for one or two keys held together. It stops being unambiguous once a specific combination of three or more keys shares rows and columns in a way the matrix can't tell apart from a different combination — the controller can end up reporting a key that isn't actually pressed. That phantom keystroke is ghosting. A related failure is blocking (sometimes called masking): rather than inventing a phantom key, the controller simply refuses to report one of the real presses, so nothing happens instead of something wrong happening.
Rollover is how many keys a keyboard can report correctly held down at the same time before it hits one of these failures. N-key rollover (NKRO) means every key can be held simultaneously with none dropped or ghosted — the practical requirement for, say, a fighting-game input needing four face buttons and a direction all held at once. Cheaper membrane keyboards typically manage clean 2-key rollover and unreliable behaviour beyond that; many claim "6-key rollover" over USB, which covers ordinary typing but not fast simultaneous game inputs. Keyboards marketed as full NKRO put a diode behind every single switch, which electrically isolates each key from every other and removes the ambiguity that causes ghosting in the first place — that's the hardware difference between "cheap membrane" and "mechanical with per-key diodes" that this section's heading points at.
What this tool can actually show you. The "Currently held" and "Max held this session" counters are the practical rollover test: hold down more and more keys — start with a realistic combination for what you actually do, like WASD plus Space plus a mouse-button-adjacent key — and watch where the count either keeps climbing honestly or stalls. What no browser-based tool can do is prove a phantom key was invented, because the browser only ever sees what the keyboard controller decided to report; a true ghost key looks, from JavaScript's side, exactly like a real one. NKRO also frequently depends on the connection: the same keyboard can be full NKRO over its own USB cable and drop to 6-key rollover through a cheap hub or over Bluetooth, so test on the setup you actually use.
Troubleshooting: dead key vs. dead switch vs. stuck modifier
These three look similar from the outside — "the keyboard isn't doing what I expect" — but they need different fixes.
A dead key
Press it and nothing happens anywhere — no event fires here, and no character appears in a plain text field either. This points to the key itself: on a mechanical board, dust or a failed switch; on a laptop, a keycap that has popped off its scissor or butterfly hinge, or a worn membrane contact underneath. If the same key also does nothing in every other application, the fault is almost certainly hardware, not this page.
A dead switch that only sometimes registers
Press it and it works, but inconsistently — sometimes needing a second press, or typing a double character when you meant one. That intermittent behaviour is usually switch chatter: an ageing or dirty contact bouncing as it closes or opens. Testing the key once here can easily look fine while typing under it repeatedly reveals the pattern — try tapping the same key rapidly ten or twenty times and watch whether "tested" ever flickers oddly, or whether a text field shows doubled characters that a single clean press here didn't.
A stuck modifier
Shift, Ctrl, Alt or the Windows/Command key appears to be permanently "held" — everything you type comes out capitalised, or ordinary letters trigger shortcuts. Before assuming a hardware fault, check your operating system's Sticky Keys accessibility feature, which is designed to hold a modifier down after a single tap and is easy to enable by accident (Windows toggles it after five Shift presses in a row). If Sticky Keys is off and the modifier still won't release here — the key never shows as un-highlighted after you lift your finger — that does point to a physically stuck key or switch.
Use cases & limitations
Where this is genuinely useful
- Buying a used keyboard. Before agreeing to a second-hand mechanical board, run every key and confirm none are dead, and hold a realistic combination to sanity-check rollover claims the seller made.
- Diagnosing a stuck or unresponsive key after a spill, a dropped object, or ordinary wear — see exactly which physical position is affected, independent of what layout or language your OS is set to.
- Checking an NKRO or anti-ghosting claim on a gaming keyboard, on the actual cable, hub, or wireless connection you plan to use it on.
- Verifying a new or replacement keycap/switch after doing your own repair, before closing the case back up.
What this tool cannot tell you
- It cannot prove a phantom key was invented. A browser only ever receives the events the keyboard controller decided to send; true ghosting is invisible from JavaScript by definition.
- It sees keys after any OS-level remapping. Tools like Windows PowerToys Keyboard Manager or macOS's Karabiner-Elements rewrite the key signal before it reaches any web page, this one included — if a key has been remapped, this tool (correctly) reports the remapped result, not the original physical key.
- Fn never reaches the browser. It's handled entirely inside the keyboard's own controller before the operating system sees it.
- It doesn't measure switch feel, actuation force, or debounce timing — only whether a clean keydown/keyup pair was received.
- It isn't meaningful for an on-screen mobile keyboard, which doesn't generate the same physical key events this tool listens for.
Frequently asked questions
What is the difference between event.key, event.code and event.keyCode?
event.code identifies the physical key by its position on the keyboard — "KeyQ" is always the key one right of Tab, no matter what layout is active or what character it types. event.key gives the character that key actually produces given the current layout and modifiers, so the same physical key reports "q" under QWERTY and "a" under AZERTY. event.keyCode is an older, numeric identifier from before event.code existed; it is deprecated, inconsistent across browsers for some keys, and does not distinguish left/right modifier keys or the numpad — event.code and event.key replaced it for a reason.
Why does this tester use event.code and not event.key to light up keys?
Because the goal is to test the physical switches, not the characters they type. If the tester matched on event.key, a visitor on an AZERTY or Dvorak layout would press the key physically labelled "A" and see a completely different key light up on screen, because that position produces a different character on their layout. Mapping by event.code keeps the on-screen key in the same physical position as the key the visitor actually pressed, regardless of layout, language, or remapping software.
What is ghosting, and what is NKRO / rollover?
Most keyboards wire their switches into a grid (a matrix) and scan it row by column to figure out which keys are down, rather than giving every key its own wire. Press the right combination of three or more keys on a matrix with no protection and the electrical scan can't tell that combination apart from a fourth key that isn't actually pressed — that phantom extra keystroke is "ghosting". Rollover (n-key rollover, or NKRO) is how many keys a keyboard can register correctly held down at once; a keyboard advertised as full NKRO has anti-ghosting protection (typically a diode per switch) so every key combination registers cleanly no matter how many are held. This tool's "currently held" and "max held this session" counters are the practical way to probe that: hold down more and more keys and see where the count stops climbing honestly.
Why do membrane and mechanical keyboards behave differently for rollover?
It comes down to whether each switch is electrically isolated. Cheap membrane keyboards usually have no per-key diode, so certain three-or-more-key combinations are genuinely ambiguous to the scanning matrix and either ghost (report a key that wasn't pressed) or block (silently drop one of the real presses). Mechanical keyboards marketed as full NKRO put a diode on every switch, which lets the controller tell any combination apart from any other, so all keys can be held at once with no ghosting or blocking. Many keyboards are only NKRO over USB and drop back to 6-key rollover over a Bluetooth connection or a cheap USB hub — worth testing on the exact connection you actually use.
A key doesn't light up at all when I press it — is the key broken or the whole keyboard?
First confirm the key does nothing anywhere else either — open a plain text field and try typing that character. If nothing appears there too, it points to the key itself: dust or debris under a mechanical switch, a worn membrane contact, or (on a laptop) a keycap that has come loose from its scissor or butterfly mechanism. If the key works in a text field but never lights up here, check that a browser extension, an OS-level remapping tool, or a game overlay isn't intercepting or remapping that specific key before it reaches the page — remapping software can rewrite event.code as well as event.key, which would point the highlight at a different key than the one you pressed.
Can this tool tell me a switch is about to fail, or only that it currently works?
Only that it currently works. A single clean keydown/keyup pair proves the switch makes contact right now; it can't predict wear, and it can't catch intermittent chatter that only shows up under real typing pressure or humidity. If a key registers a double character while typing normally but tests fine here, that's chatter — an ageing switch or a dirty contact bouncing on release — and it's a hardware symptom this or any other software tool can describe but not fix.
Why does the Fn key never seem to do anything on this page?
Fn is handled entirely inside the keyboard's own controller, before the signal ever reaches the operating system, let alone the browser — it's how one physical key can mean "brightness" on one press and "F5" on another depending on what else is held. No web page can see Fn being pressed on its own, and this is true of every browser-based keyboard tester, not a limitation specific to this one.
Does this work on a laptop keyboard, or only external ones?
It works on any physical keyboard the operating system reports events for, laptop keyboards included. A laptop's compact layout typically omits a numpad and dedicated navigation cluster, so those sections of the on-screen board simply won't light up — that's expected, not a fault. A software keyboard on a phone or tablet screen is a different case: it doesn't fire the same key events a physical keyboard does, so this tool isn't meaningful for testing an on-screen mobile keyboard.
Do you store or upload anything I type here?
No. Every key event is read and discarded entirely inside your browser — nothing is written to a server, logged, or kept after you close or reload the page. Because ordinary keypresses can include anything you'd type into a password field, the tool reads only which physical key changed state (its code, and its layout-mapped character for the readout), never the contents of any other page or field.