Stuck Key Test
See which keys your browser currently registers as held, and flag the ones that never send a release event.
Stuck key detector
The test engine did not load. The measurement scripts on this page are unavailable, so the live detector cannot run. The explanations below still apply.
Currently held
Nothing is held right now.
Hands-off check
Anything still held once your hands are off the keyboard is the signal that matters. Start the check with your mouse, let go of every key, and wait for the countdown.
No check run yet. Press Release everything and check when your hands are clear of the keyboard.
Focus changed while keys were held
Browsers usually do not deliver a keyup for a key that was down when the page
lost focus, so those keys stay logically held forever. That looks exactly like a stuck key
but is not one. Those keys are marked release event may never arrive below and are
excluded from the hands-off verdict. Click into the test area, then press and release each of
them once to clear it.
Patterns detected
No abnormal event patterns detected yet.
Keyboard map
The keyboard map loads with the page scripts.
Held now Held past the threshold Release event may never arrive Registered at least once
Advanced: settings and full event log
A key that reappears within 50 ms of its own release is flagged separately as an immediate re-assert. Holding a key deliberately trips the hold threshold too — that is expected, and it is why the hands-off check exists.
| # | Type | Key | Code | Time (ms) | Gap (ms) | Note |
|---|---|---|---|---|---|---|
| No events yet. Press a key. | ||||||
Measurement environment
Timer resolution: — High-resolution timing: — Browser: — Platform: — Focus interruptions: 0
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. Hold durations on this page are seconds long, so clock coarseness barely matters here — but focus interruptions matter a great deal. How we measure.
What this test cannot tell you
This runs in a web browser, so it only sees keyboard events after your operating system has already delivered them. It cannot see the switch itself, the keyboard's firmware or its matrix scan, so it cannot tell you whether a key is physically not returning, whether a contact is dirty, or whether a stabiliser is binding. It also cannot see a key that sends nothing at all — a key with no event is invisible here.
A key that this page reports as held may be held by something other than your keyboard: remapping or macro software, an accessibility feature such as sticky keys, another application that captured a key before you switched to this tab, or a browser extension that synthesises key events. This test reports a pattern, not a diagnosis.
What a stuck key looks like to a browser
A browser does not know whether a key is physically down. It knows only that it received a
keydown and has not yet received the matching keyup. Everything on
this page is built on that pair.
A normal press produces one keydown, then one keyup a few tens of
milliseconds later. Hold the key and your operating system starts generating repeat events,
which arrive as further keydown events with the repeat flag set; the release still
ends with exactly one keyup. The classic stuck-key signature is the missing half of
that pair: the press arrives, the release never does, and the key stays logically held until
something else clears it.
Why a lost release is not the same as a stuck key
This is the trap that makes most stuck-key checkers unreliable. If a page loses focus while a key is down — you alt-tabbed, a notification stole focus, you clicked another window, or the browser opened its own dialog — the release almost never reaches the page. The key remains held in the page's model forever, and a naive checker reports a stuck key that does not exist.
This test watches for that moment. When focus or tab visibility is lost while keys are down, every key that was held is marked release event may never arrive, a notice appears saying so, and those keys are excluded from the hands-off verdict. The same marking is applied to any key pressed while the page was already unfocused or hidden. Press and release each of them once with the page focused and the flag clears. If it clears, you did not have a stuck key — you had a focus change.
The patterns this test flags
| Pattern | What was observed | What it usually means |
|---|---|---|
| Held with no release | A keydown, then no keyup for longer than the threshold, with focus kept the whole time. | Either you are holding the key on purpose, or it is not returning. The hands-off check separates the two. |
| Repeated press with no release | A second non-repeat keydown for a key that never sent a keyup. | Often a lost keyup earlier in the session. Sometimes remapping software re-asserting a key. |
| Release with no press | A keyup for a key this page never saw pressed. | Normal right after a focus change or page load. Harmless on its own. |
| Immediate re-assert | The same key sends a fresh keydown within 50 ms of its own keyup. | Worth a second look. A duplicate press-and-release pair from one physical press is chatter, not a stuck key. |
| Focus lost while held | The page lost focus or visibility while one or more keys were down. | Not a fault. It explains held keys that will never release, and it invalidates the current snapshot. |
Telling a hardware stuck key from a software one
The browser cannot distinguish them, but three quick comparisons can. Change one variable at a time and see whether the symptom follows it.
- Test in another application. Open a plain text editor and hold nothing. If characters keep appearing, or a modifier behaves as though it is down, the problem is not this page or this browser.
- Test another keyboard. Plug in a second keyboard on the same machine. If the symptom disappears, it belongs to the first keyboard. If it stays, it belongs to the machine — usually software.
- Test the same keyboard on another machine. If it follows the keyboard, it is the keyboard or its firmware. If it stays behind, it is the original computer's software or drivers.
A stuck modifier is the most common of all and is almost always software. If everything you type arrives in capitals or triggers shortcuts, tap each Shift, Ctrl, Alt and the Windows or Command key once on both sides of the keyboard, then re-run the hands-off check here.
Common causes and what to try
- Debris under the keycap. Crumbs, dust and dried liquid stop a keycap or stem returning cleanly. Power down, remove the keycap if the design allows it, and clear the switch housing with compressed air before anything wetter.
- Switch or dome wear. A worn switch or a torn rubber dome can hold contact after the finger leaves. This usually affects one key that is used far more than the rest, such as a spacebar, a WASD key or Enter.
- A modifier held by another application. Applications that grab keys globally — games, remote-desktop clients, screen readers, virtual machines — can leave a modifier asserted when you switch away from them. Tap the modifier on both sides to clear it.
- Remapping and macro software. Layer tools, key remappers, gaming macro suites and vendor configuration apps can hold a key down deliberately. Quit them and re-test.
- Accessibility features. Sticky keys, filter keys and slow keys change how long a key counts as held. They are easy to enable by accident with five taps of Shift.
- A binding stabiliser. On large keys the cap can catch on the plate. This feels mechanical rather than electrical — the key returns if you nudge it.
If the pattern survives all of that, the next step is a firmware or driver update from the keyboard's manufacturer, and after that a hardware repair. For a longer walkthrough, read how to test for and fix a stuck key.
Related keyboard tests
Frequently asked questions
Why does the test say a key is still held after I let go?
The most common reason is a focus change. If this page loses focus while a key is down — you alt-tabbed, clicked another window, or the browser opened a dialog — the release event is usually never delivered to the page, so the key stays logically held forever. This test detects that moment and labels those keys separately instead of reporting them as stuck. The other reasons are a key that is physically not returning, or software that is holding a key down on your behalf.
Can this test tell me whether my keyboard is broken?
No. It can only tell you what your browser is being told about the keyboard. A key that still registers as held with your hands off the keyboard is a real signal worth investigating, but remapping software, macro tools, accessibility sticky-keys features, another application that grabbed a key, and browser extensions that synthesise key events all produce the same pattern. Confirm it in a second application and with a second keyboard before blaming the hardware.
What exactly counts as a stuck key in this test?
A key whose keydown event arrived, which then never produced a matching keyup, while this page kept focus the whole time. The hold threshold is adjustable and defaults to 5 seconds. Holding a key on purpose triggers the same flag, which is why the reliable check is the release-everything snapshot: take your hands off the keyboard and see what is still held.
Why do Fn, some media keys and a few laptop keys never appear?
Several keys are handled entirely inside the keyboard or by the operating system and never reach the browser as key events. Fn is the usual example: it changes what the other keys send rather than sending anything itself. Some media, brightness and vendor hotkeys are intercepted the same way. If a key produces no event at all, this test cannot see it, and the keyboard tester is the better tool for checking key coverage.
Does a repeated keydown mean the key is chattering?
Not by itself. Holding a key down makes the operating system generate auto-repeat keydown events, and those are marked as repeats and logged separately here. What is abnormal is a fresh non-repeat keydown for a key that never sent a keyup, or a key that reappears within a few milliseconds of releasing. A duplicate press-and-release pair from one physical press is chatter, and the chatter test measures that specifically.