Before you start
Decide which of three questions you are actually asking. Does one physical key never register? Does a key register but never release? Or does a combination drop a key when several are held at once? Each has a different cause and a different test, and mixing them produces an inconclusive run every time.
Choose the layout that matches your physical board before you press anything. A key test that identifies keys by printed character will mislabel every non-QWERTY board, which is why serious testing uses KeyboardEvent.code — the physical position — instead. On a remapped keyboard, the position lights up, not the letter you typed.
Then close anything that captures keys globally: screen recorders, macro tools, streaming overlays and remote-desktop clients all intercept input before the browser sees it. A key that works everywhere except this page is usually being swallowed by one of these.
Run the check
Open the keyboard test and work across the board in blocks rather than hunting for the suspect key first. Cover the alphanumeric block, then modifiers, then the function row, then the navigation cluster and numeric pad. Working systematically catches the second fault you did not know about, which is common on boards with liquid damage.
Watch the four states the map distinguishes: untested, proven, currently held and stuck. Each uses a different border and background as well as a text label, so it reads correctly without colour vision. A key becomes stuck only when a keydown has gone three seconds without a matching keyup, which is a genuine signal rather than a rendering artefact.
For the rollover question, hold combinations deliberately. Press and hold three ordinary keys in the same region of the board, then a fourth, and watch whether the newest key appears or the oldest disappears. The tool records the largest simultaneous held set for the run, which is the number you actually want.
For a stuck-key complaint, press and release the key normally, then click back into the page and repeat. Losing window focus mid-press produces an unmatched keydown that looks exactly like a physical fault, so this second run separates the two.
Read your result
Read proven positions, held keys, stuck timers and the maximum simultaneous set as four separate results. A board can have a perfect proven map and still fail rollover, and it can pass rollover while one key sticks intermittently.
Any combination that never arrives is inconclusive if the operating system reserves it. Cmd+Tab, Alt+Tab, Ctrl+Alt+Delete, PrintScreen and most Windows-key combinations are intercepted before a browser gets a chance. Rebuild the same test with ordinary letter keys and see whether the drop follows the keys or the shortcut.
Repeated characters when you press once are usually a key-repeat setting or a debounce problem rather than a broken switch. Check whether the extra characters arrive at a steady interval matching your system repeat rate; if they do, the setting is the cause.
Measurement limits
A browser cannot see the keyboard matrix, the scan rate, the switch type or the firmware. It sees key events after the operating system has finished with them, which is exactly why reserved shortcuts vanish and why remapping software changes what the page receives.
Key repeat is a system setting, not a hardware property. The delay before repetition starts and the rate at which it continues are both configured in your operating system, so any browser measurement of repetition describes that configuration first and the keyboard second.
Rollover limits are a property of the board's matrix and its USB descriptor. A page can observe that a fourth simultaneous key disappears, but it cannot tell you whether the limit is 6-key rollover over standard USB HID or a genuine matrix collision, and those have different fixes.
What to do next
One physical position that stays dead across layouts, across applications and after a reboot deserves a hardware response: reseat or replace the switch if the board is serviceable, or start a warranty conversation if it is not.
A dropped fourth key in ordinary combinations is a rollover limit, not a fault. Most membrane and budget boards are specified this way. If the combination matters for how you work or play, the fix is a board with N-key rollover, not a repair.
A key that only fails in one application, or only while a particular tool is running, is a software interception problem. Close the capturing application and retest before anything else; this resolves a large share of reported keyboard faults at no cost.
Symptom table
| Symptom | Likely layer | Next action |
|---|---|---|
| A key stays untested | Reserved shortcut, layout mismatch or missing event | Try an ordinary key and compare event.code |
| A key remains held | Missing keyup or physical return problem | Release, clear and repeat for three seconds |
| A combination drops | Matrix rollover or platform interception | Use the rollover check with ordinary keys |
Common questions
How can I test a keyboard without typing into a document?
A browser-based key test captures events on the page itself, so nothing you press is inserted anywhere. That also means you can safely test modifier keys and combinations that would otherwise trigger actions in an editor.
Why does my keyboard drop keys when I hold three at once?
That is rollover, a matrix limitation rather than a fault. Many keyboards guarantee only a handful of simultaneous keys, and which ones collide depends on their position in the matrix. Boards advertised as NKRO avoid it.
One key types two characters. Is the keyboard broken?
Check the interval first. Repeats spaced at your system's key-repeat rate point at a settings problem, while two characters arriving within a few milliseconds point at switch bounce, which is a hardware issue.