About KeyboardLatencyTest.com
A set of free browser-based keyboard tests, built around one rule: report exactly what was measured, and say plainly what it cannot reach.
What the tools actually measure
Every timing figure on this site comes from the same source: the JavaScript
KeyboardEvent your browser hands to the page. The browser stamps each event
with a timestamp when it creates the event, and our handler reads the clock the instant it
runs. The difference between those two readings is the measurement.
That difference is real, reproducible and useful. It covers the browser's own input pipeline and its main-thread scheduling — the part of the chain a web page can legitimately see. It does not cover anything that happened before the browser was handed the input.
| Channel | What is compared | Honest name |
|---|---|---|
| A | Handler clock reading minus the event's own timestamp | Browser input event latency |
| B | Next animation frame minus the event's own timestamp | Input-to-frame time (browser-side) |
| C | One event's timestamp minus the previous event's | Browser-observed event interval |
The full formulas, the sample validation rules and the statistical definitions are written out on the measurement methodology page, including the cases where a sample is discarded and why.
What this site will not claim
Most of the editorial effort here goes into the second half of every result: the part that says what the number is not. These are standing commitments, not caveats added to individual pages.
- No hardware latency figures. A web page sees input only after the switch, the keyboard's controller, the USB or Bluetooth link and the operating system have all had their turn. Separating those stages requires physical instrumentation, so this site never presents a browser result as your keyboard's true or actual latency.
- No polling rate readings. The interval between events as the browser receives them is shaped by operating-system input handling, browser event coalescing and main-thread load. It is reported as browser-observed event cadence, never as a measured USB polling rate.
- No confusing reaction time with latency. The reaction time test measures a human responding to a visual signal. That figure is dominated by perception and motor delay and is kept deliberately separate from the latency tools.
- No invented data. There are no benchmark tables of named keyboards, no per-product millisecond figures, no ratings, no testimonials and no user counts on this site, because we have no lab that could produce them honestly.
- No verdicts on your hardware. Diagnostics describe patterns. A chatter result reads as a possible duplicate-event pattern with its timings shown, not as a declaration that a switch has failed.
Why the distinction is the whole point
A browser test that quietly labels its output "keyboard latency" is not slightly wrong; it is measuring a different thing from the one the reader thinks it is measuring. Two machines with identical keyboards can produce very different browser results because of background CPU load, browser version, refresh rate or power settings.
Keeping the boundary explicit is what makes the numbers usable. Once you know the measurement stops at the browser, a high or erratic result becomes a genuine signal about your system's input path rather than an accusation against your keyboard.
How the pages fit together
The keyboard latency test on the homepage is the main tool: it collects key presses, applies the validation rules and reports median, percentiles, jitter and a consistency figure. Everything else exists because one question kept getting buried inside it.
- Diagnostics answer yes-or-no questions about key behaviour — ghosting, rollover, chatter, stuck keys and repeat timing.
- Technical tools expose the raw material: the event tester shows every property of each event, and the comparison tool puts two saved sessions side by side.
- Calculators are models, not measurements. You supply the component values and they show the arithmetic.
- Guides explain the concepts behind the results, starting with what keyboard latency actually is.
Uncertainty is shown, not hidden
Browsers deliberately coarsen their clocks, and a clock that rounds to whole milliseconds cannot resolve sub-millisecond jitter. Each measurement page probes the timer resolution it is actually running with and displays it, so a quantised-looking result has a visible explanation.
Excluded samples are always counted and listed rather than silently dropped, and statistics that need a minimum sample size are withheld until there are enough samples instead of being estimated from too little data.
Corrections
If a technical explanation here is wrong, imprecise or out of date, we would rather fix it than defend it. Corrections are welcome through the contact page, and they are the most useful message this site receives.