Keyboardtest Logo

How We Test Keyboards: Methods and Limitations

Updated

Keyboardtest observes keyboard events delivered to a web page. It can show which keys the browser received, their press and release order, and selected timing intervals. It does not inspect the keyboard's electrical matrix or certify a hardware fault.

From a physical press to a page event

A press passes through the keyboard's sensing and firmware, its connection, the operating system and the browser before page code receives it. Remapping, accessibility features, system shortcuts and focus can affect that path. A result describes the input that reached this page under those conditions.

Start with the keyboard test. Press and release keys individually, then compare suspicious behavior in another application or device before changing parts.

Keyboard event reference

FieldMeaningExample or limitation
codeA standardized key-position identifier.KeyQ can produce a different character on another layout.
keyThe interpreted character or key name.a, A, Enter or Dead, depending on input state.
locationA location category where available.Can distinguish left/right modifiers and keypad input.
repeatWhether the browser marks a keydown as automatic repeat.Useful for separating a held key from a fresh event.
Modifier flagsReported Shift, Control, Alt and Meta state.These are event state, not a measurement of switch position.
timeStampEvent time in the browser's timing system.Precision can be reduced; it is not a physical-actuation timestamp.

The inspector may show legacy keyCode values for compatibility reference. New integrations should use key and code; legacy numbers are not a universal hardware scan-code map.

For examples you can compare directly with the inspector, use the keyboard event and code reference.

What the diagnostics count

Individual keys and releases

A tested key records an observed press. A held key records a press for which the tool has not yet received a release. A persistent held state can result from missing events or software behavior as well as a physical problem. Held state is cleared when the window loses focus to avoid treating a lost release as a continuing physical hold.

A layout progress count covers the displayed testable keys. It does not verify Fn, every media control, a fingerprint reader or keys absent from that layout. Pointer previews of virtual keys are not evidence that a physical switch worked.

Double typing and chatter

The double typing test compares successive non-repeat keydown events for the same code against a selected threshold. A flagged pair deserves a controlled retest with deliberate, separate taps. It can reflect chatter, intentional fast input, firmware or software duplication; no interval alone proves the cause. A run with no flags means no qualifying pair was observed in that run.

Ghosting and rollover

The ghosting test helps you compare physically held combinations with events received. Only you know which physical keys you intended to hold, so the page cannot automatically certify that a missing key is blocked.

The rollover test tracks simultaneous registration. Ordinary-key counts matter when comparing 6KRO with a mode that reports more keys, because the USB boot report handles modifiers separately. Passing seven ordinary keys demonstrates that combination; it does not establish unrestricted NKRO across every possible group and connection mode.

Browser timing and physical latency

The key timing tool reports press duration from matching keydown/keyup timestamps and intervals between successive non-repeat keydowns. Its inter-key interval is measured down-to-down; some research uses “flight time” for up-to-down instead, so compare definitions before comparing results.

These values describe observed input timing, including how you press keys. They do not measure switch actuation delay, scan rate, USB polling rate or total press-to-pixel latency. Browser code lacks an independent timestamp for the physical start. We do not derive a hardware polling-rate claim from human tapping or auto-repeat.

Limits to keep in view

  • Fn, media actions and reserved shortcuts may be handled outside the page.
  • Touch keyboards and accessibility input can produce different event sequences from physical keyboards.
  • The browser cannot identify which connected keyboard produced an ordinary event.
  • Firmware layers, macros and remapping can change reported keys.
  • Background tabs, workload and privacy settings affect event delivery or timer precision.
  • Short tests can miss intermittent faults. Passing once does not predict remaining switch life.

Local processing and third-party services

Test state and calculations stay in browser memory in the diagnostic application. There is no diagnostic upload endpoint, and the configured analytics calls do not include typed text, key-event arrays or timing results. Event histories are bounded; refreshing the page starts a new session.

The site still loads network resources. Google Analytics and AdSense are configured. These services can process request information and use cookies; see the privacy policy and storage disclosures. Do not enter passwords or private correspondence into a test.

Editorial approach

Keyboardtest is the organizational publisher of the guides. That byline does not claim a laboratory, expert credential or independent product certification. Articles distinguish observations from possible causes, name their relevant tool, retain publication dates and display the date of substantive revision. Manufacturer instructions and primary technical documentation support claims where needed.

Our diagnostic workflows start with reversible comparisons before repairs or resets. We do not publish invented ratings, usage counts or promised outcomes. To suggest a correction, send the page URL and a reproducible example or primary reference through Contact.

Primary technical references

All diagnostic tools · Troubleshooting guides