Keyboard Key Test
Press one key and see exactly what your browser received from it — the key value, the physical code, the location, the repeat and trusted flags, the modifier state, and the time between keydown and keyup.
Single key inspector
No event received
Waiting for a key event
Click here (or press Tab until this area is focused), then press the key you want to check. Press Esc to leave this area.
Reset returns the display to “No event received”, so you can press a single suspect key and see whether anything arrives at all.
Event properties isTrusted —
- event.key
- —
- event.code
- —
- event.location
- —
- event.repeat
- —
- event.isTrusted
- —
- Normalized timestamp
- —
Modifier state at the moment of the event
Matched keydown / keyup pair
Both timestamps are browser event timestamps normalized onto the page's monotonic timeline. The hold duration is almost entirely how long your finger was on the key.
Counters for this key
Median event latency is the gap between the timestamp the browser put on the event and the moment this page's handler ran. It describes the browser input pipeline on this machine, not the keyboard. How we measure.
Last 20 events for this key
| Event | key | code | location | Time (ms) | Δ prev (ms) | Hold (ms) |
|---|---|---|---|---|---|---|
| No events captured yet. | ||||||
Advanced: session totals and excluded events
Key events seen: 0 Distinct codes: 0 Events ignored while locked: 0 Focus interruptions: 0
No samples excluded.
Excluded events are never thrown away silently. Auto-repeat events are routed to the repeat counter rather than counted as presses, and events that arrive while the window is not focused or the tab is hidden are listed here instead of being mixed into the timing figures.
Measurement environment
Timer resolution: — High-resolution timing: — Browser: — Platform: —
These conditions affect your result. A browser that rounds its clock to 1 ms cannot resolve sub-millisecond differences, so jitter will look artificially quantised. How we measure.
What this test cannot tell you
This runs in a web browser, so it only sees a key event after the switch, the keyboard's controller, the cable or wireless link, the operating system and the browser have all already handled it. If a key produces no event here, this page cannot tell you which of those stages dropped it. It cannot measure switch actuation force or travel, it cannot read your keyboard's firmware, and it cannot confirm that a key is physically faulty.
The browser also does not show you every key. Some combinations are consumed by the operating system or by the
browser itself before a page ever sees them, and a remapping utility can change event.key or suppress
a key entirely without the browser knowing.
How to check one key with this page
- Click the test area above so it has focus. While it is focused it swallows key presses, which is what lets you test Tab, Space and arrow keys without the page scrolling or focus moving away.
- Press Reset watch. The display returns to “No event received”.
- Press only the key you are checking. If the readout stays empty, your browser received nothing from that key. If it fills in, the key is registering and every property it reported is listed.
- Press Lock to this key so other keys stop replacing the readout, then press the key ten or twenty times. Watch the press and release counters stay equal, and watch the hold durations.
Two counters that drift apart are the interesting signal. More keydowns than keyups usually means presses were delivered without a matching release; more than one keydown for a single physical press is the pattern the keyboard chatter test is built to quantify.
What each field in the readout means
| Field | What it tells you |
|---|---|
event.key | The character or named value the key produced after your active keyboard layout and modifier state were applied. This is what an application would actually type. |
event.code | The physical key position, independent of layout. KeyQ is the key where Q sits on a US QWERTY board, whatever it prints for you. |
event.location | Which instance of a duplicated key fired: standard, left, right or numpad. |
event.repeat | true when the event came from your operating system's auto-repeat rather than a fresh press. |
event.isTrusted | true for real user input. false means a script generated the event — an automation tool, an extension, or a macro utility. |
| Normalized timestamp | The browser's own timestamp for the event, converted onto this page's monotonic timeline so two events can be subtracted safely. |
event.location: telling left and right keys apart
Several keys exist twice on a keyboard, and event.key cannot distinguish them: both Shift keys
report Shift, both Control keys report Control. event.location is the field
that separates them.
- 0 — Standard. The key exists only once, or the browser could not place it.
- 1 — Left. Left Shift, Control, Alt or Meta.
- 2 — Right. Right Shift, Control, Alt or Meta, including the AltGr key on many layouts.
- 3 — Numpad. The numeric keypad copy of a digit, Enter or an operator.
If you suspect the right Shift key is dead, press left Shift and then right Shift here and compare. Two events
that both report location 1 and ShiftLeft mean the right key never reached the browser as its own key
— often because a remapping tool has merged them.
Why event.key changes with your layout but event.code does not
Your operating system, not the keyboard, decides what a key means. The keyboard reports a scan code for a
position; the OS applies the active layout and produces a character. The browser exposes both halves: the position
as event.code, the resulting character as event.key.
So the key next to Tab reports event.code: KeyQ on every layout, while
event.key is q on QWERTY, a on AZERTY and ' on Dvorak. Nothing
is wrong in that case — the layout is doing its job. A key that prints the wrong character but reports the
expected code is a layout or remapping issue, not a hardware one, and switching the input language back
usually fixes it.
What keydown-to-keyup hold duration does and does not show
The hold duration on this page is the difference between the two browser event timestamps for one press. It is dominated by how long you held the key, so it is a measure of your finger, not your hardware. It is still useful for two things: confirming that a release event arrives at all, and spotting a key that reports absurdly short holds when you know you pressed it normally.
A press that produces a keydown and no keyup leaves the key logically held as far as the browser is concerned, which is exactly the pattern the stuck key test looks for. A press that produces several keydown events in a few milliseconds is the pattern behind keyboard chatter. Neither result identifies a faulty switch on its own — both are worth reproducing on a second computer before drawing a conclusion.
Key test, keyboard tester or event tester — which page to use
- This page when one key feels wrong. It follows a single key at a time and shows every property, both counters and the hold timing for that key alone.
- Keyboard tester when you want to sweep the whole board. It draws a full layout and marks every key that registers, so you can find which keys are missing.
- Keyboard event tester when you are writing code. It streams every event with the complete property set and no per-key filtering, which is what you want when debugging a shortcut handler.
If your question is about timing rather than detection, start at the keyboard latency test, which measures browser-observed input timing with full statistics.
Related keyboard tests
Frequently asked questions
What is the difference between event.key and event.code?
event.key is the character or name the key produces after your operating system has applied the active keyboard layout, so one physical key can report q on a QWERTY layout and a on AZERTY. event.code names the physical key position instead and stays KeyQ in both cases. If a key prints the wrong character, event.code is usually still correct and the layout is the thing to check.
Why do left Shift and right Shift show the same key value?
Both report Shift for event.key because both produce the same modifier. They are still distinguishable: event.code reports ShiftLeft or ShiftRight, and event.location reports 1 for left and 2 for right. This page shows all three values, so you can confirm your browser is telling the two apart.
Can this test tell me whether a key is physically broken?
No. It can only tell you whether your browser received an event. If a key produces no event at all, something between the switch and the browser is not passing it on — the switch itself, the keyboard controller, the cable or wireless link, a driver, or a remapping tool. Narrowing that down means retesting the same key on another computer or with different software.
Why does holding a key produce a stream of events?
After an initial delay your operating system repeats the keydown event for as long as the key stays held, and every repeated event has event.repeat set to true. That cadence is an operating-system setting rather than a property of the keyboard. The keyboard repeat rate test measures the initial delay and the repeat interval directly.
Does the hold duration show my keyboard's latency?
No. Hold duration is the gap between the keydown and keyup events as your browser received them, which is mostly a measure of how long you held the key down. It cannot isolate switch actuation, firmware, transmission or operating-system delay. The keyboard latency test explains what a browser can and cannot see.
Should I use this page or the full keyboard tester?
Use this page when one key feels wrong and you want every detail about that single key. Use the keyboard tester when you want to sweep the whole board and see which keys register at all, and the keyboard event tester when you want a raw, unfiltered event stream for development work.