Laptop keyboards fail differently
A desktop mechanical board has an individual switch per key; a laptop has a rubber-dome membrane, a scissor mechanism, and a single ribbon cable to the motherboard — all squeezed under caps with about a millimetre of travel. That construction changes both what goes wrong and what the failure looks like in a tester. Crumbs disable one key; a pinched ribbon disables a whole stripe of them; a worn dome starts double-typing ("chatter") long before it dies completely.
Symptom table: what the tester result means on a laptop
| What you see here | Most likely cause | Next step |
|---|---|---|
| One key never lights | Debris under the cap or a failed dome | Pop the cap carefully, clean with compressed air; then a keyboard/top-case replacement |
| A full row or column never lights | Matrix trace or ribbon-cable connection | External keyboard to confirm; then repair shop for reseating/replacement |
| Key lights twice per press (Chatter tab flags it) | Worn dome bouncing — common after heavy use or a spill | Confirm with the chatter test; membrane keyboards are replaced, not repaired |
| Key lights but types the wrong character | OS layout or remapping software, not hardware | Check OS language/layout settings and any remap utilities |
| F-keys send media actions | Fn-lock in media-first mode (factory default) | Toggle Fn-lock (often Fn+Esc) or change it in BIOS/vendor software |
| Key registers only with hard presses | Dome losing contact pressure | Works today, fails soon — plan a replacement |
| Random keys repeat when laptop warms up | Flex or liquid damage under the deck | Repair evaluation; document the pattern first with this tester |
Worked example: the "dead" F5 that was not dead
A user reports F5 no longer refreshes the browser. In the tester, pressing F5 alone shows
nothing in the readout — looks dead. But holding Fn and pressing the same key instantly
lights F5 and the readout shows event.code: F5. Diagnosis: the key and its
wiring are perfect; the laptop is in media-first mode, so bare F5 sends a hardware brightness/refresh
action the browser never sees, and Fn+F5 sends the real F5. The fix was Fn+Esc (Fn-lock), not a new
keyboard. This single case is why the F-row is outlined on this page: an F-key that shows
nothing is not proven dead until you have tried it with Fn held.
Worked example: spill triage with concrete numbers
After a coffee spill, a user runs the full test. Result: 101 of 104 keys light; KeyJ,
KeyK and KeyM never register — three adjacent keys in one corner of the
spill area, everything else fine. Because the three failures cluster physically but do not form a
complete matrix row, this points to local dome/contact damage rather than a severed ribbon. The
practical value: the untested-keys list (button under the readout) gives an exact, written list of
failed keys to include in a repair quote or warranty claim, instead of "some keys near J".
Testing laptop-specific keys
- Fn: invisible to any software tester — verify it indirectly via Fn+F-key combinations.
- Media/brightness keys: some send key events (they appear in the extra-keys tally with codes like
AudioVolumeUp); others are handled entirely in hardware and legitimately show nothing. - Numpad on 15-inch laptops: test with NumLock both on and off —
event.keychanges (7with NumLock on,Homewith it off) whileevent.codestaysNumpad7either way, because the code is the physical position. Both paths should work. - Power/eject keys: never testable from a browser; do not count them as failures.
If your laptop board passes everything here but gaming combos still drop keys, that is a rollover limit, not a defect — laptop matrices are often more restricted than desktop boards. Measure it on the key rollover test. And if your spacebar feels inconsistent, give it a focused run on the spacebar test. For the full-size reference board and the complete methodology, go back to the main keyboard tester.