Keyboard Reaction Time Test
Wait for the green signal, then press any key — this measures your reaction time, which bundles your display, your perception, your hand and the browser input path into one number, and is not a measurement of keyboard latency.
Reaction time test
Idle. Choose how many attempts you want, then start the run.
Results
Reaction time by attempt: no data yet. Run the test to draw this chart.
Distribution of all attempts this session: needs at least 8 valid attempts before a distribution is worth drawing.
Advanced: every attempt, and how much of it was the browser
Each row is one attempt. Browser input path is the gap between the timestamp the browser wrote on the key event and the moment our JavaScript handler actually ran — the same browser-side quantity the keyboard latency test measures. It is shown here so you can see how small a slice of your reaction time it really is.
| # | Reaction (ms) | vs best | Browser input path (ms) | Key | Status |
|---|---|---|---|---|---|
| No attempts yet. | |||||
Method: the signal colour is applied in one requestAnimationFrame
callback and the reference timestamp is taken in the next one, so the stopwatch starts at
the frame that carried the green fill to the compositor rather than at the moment JavaScript
decided to change it. Presses are timed from KeyboardEvent.timeStamp where the browser
provides a usable one, normalised onto the performance.now() timeline.
Measurement environment
Timer resolution: — High-resolution timing: — Browser: — Platform: — Frame interval: —
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. The frame interval is measured from this browser's animation frame callbacks and is the smallest step in which the signal can appear on screen. How we measure.
What this test cannot tell you
This is a measurement of you, not of your keyboard. The number it produces is one combined figure covering your display's refresh interval and pixel response, your visual perception and decision, your hand and finger movement, and finally the keyboard and browser input path. There is no way to separate those terms from inside a web page.
So it cannot rank keyboards, cannot detect a slow switch, and cannot be used to prove that one board is faster than another — the human term is one to two orders of magnitude larger than anything the hardware contributes, and it varies more between two of your own attempts than any two keyboards differ from each other. It also cannot measure switch actuation, firmware, matrix scanning, USB or Bluetooth transmission, or OS scheduling.
For the part that a browser genuinely can measure, use the keyboard latency test, which times the browser input pipeline directly. Read the full methodology and limitations
What the number actually contains
When the stage turns green and you press a key, the elapsed time is a chain of separate delays stacked end to end. Roughly, in order:
- Display — the change can only appear on a refresh boundary, then the panel's pixels need time to actually change.
- Perception — light reaches your retina, the signal travels to visual cortex, and you recognise it as the cue.
- Decision and motor command — the largest and most variable term.
- Mechanical travel — your finger moves and the switch actuates.
- Input path — keyboard firmware, transmission, the operating system, then the browser creating and dispatching the key event.
Only that last item has anything to do with your keyboard, and in a typical result it is a single-digit millisecond slice of a total in the hundreds. The advanced table above shows the browser-side portion explicitly so you can see the proportion for yourself.
Why this is not a keyboard latency test
People often reach for a reaction time test to compare two keyboards, and it cannot do that job. The variation between your own attempts — blinking, attention drifting, one hand more tense than the other — is far bigger than the difference any two keyboards would introduce. Swapping keyboards mid-run would change the total by an amount smaller than the noise floor of the human measurement, so any difference you saw would be your own variance, not the hardware.
The honest comparison is to measure the pipeline segment a browser can actually observe, and to do it many times. That is what the keyboard latency test does, and the difference between the two ideas is unpacked in keyboard latency vs reaction time.
How the stopwatch is started
Most reaction time tests read their start timestamp immediately after setting a CSS colour. That is wrong by roughly one frame: at that instant nothing has been rendered, composited or scanned out, so a whole frame of the browser's own rendering work gets charged to your reflexes.
This page applies the colour change inside one animation frame callback, then takes the reference timestamp inside the next callback — the frame after the green fill was handed to the compositor. That is the closest a web page can get to "the moment it became visible". It still cannot account for your display's own scan-out and pixel response, which no browser API exposes.
What a typical result looks like
Simple visual reaction times measured this way commonly land somewhere around 200–300 ms. Treat that as a rough orientation rather than a grade: it moves with age, sleep, time of day, caffeine, how many times you have practised this exact test, and how fast your display is. We deliberately do not publish a percentile table or a leaderboard, because we have no measured population to build one from and inventing one would be worse than useless.
What is worth paying attention to is your own spread. A tight cluster across five attempts means you were attending consistently; a wide one usually means attention wandered or you were guessing at the timing. That is why the page reports standard deviation and a consistency label alongside the median, and always prints the coefficient of variation that produced the label.
Getting a result you can trust
- Use the median, not your best. One lucky attempt is a sample of one.
- Run at least five attempts, ideally ten, and do a throwaway run first — almost everyone improves over their first few presses purely through familiarity.
- Do not try to anticipate. The wait is randomised between 1.5 and 4.5 seconds specifically to defeat rhythm. Presses under 100 ms after the signal are set aside as anticipation, and presses before the signal are discarded entirely.
- Keep the conditions fixed if you are comparing runs: same display, same refresh rate, same seating distance, same finger resting in the same place.
- Close what you can. A busy main thread delays both the signal frame and the handler; the frame interval readout in the measurement environment panel will show it.
Related keyboard tests
Frequently asked questions
Does this test measure my keyboard's latency?
No. It measures your reaction time, which is a human measurement. The number includes the time your monitor took to show the signal, the time your eyes and brain took to notice it, the time your hand took to move, and only then the keyboard and browser input path. The keyboard's share is a small and unknown fraction of the total, so two keyboards cannot be compared this way. The keyboard latency test measures the browser input pipeline directly instead.
What is a good reaction time?
Simple visual reaction times measured this way commonly land somewhere in the 200 to 300 millisecond range, but that band is a rough orientation and not a grade. Age, alertness, time of day, caffeine, practice with this specific test, the input device and your display hardware all move the number, and a single fast attempt says far less than the median of a full series. We do not publish a percentile table because we have no measured population to build one from.
Why do I keep getting "Too early"?
A press that arrives before the stage turns green is a false start. The delay before the signal is randomised between 1.5 and 4.5 seconds precisely so it cannot be anticipated, and false starts are discarded rather than recorded so they cannot flatter your statistics. Presses that land under 100 milliseconds after the signal are also set aside as anticipation, because that is faster than simple visual reaction is generally believed to be possible.
Does my monitor's refresh rate affect the result?
Yes, and it is one of the larger hidden variables. The signal can only appear on a refresh boundary, so on a 60 Hz display the change waits up to about 16.7 milliseconds before any pixel changes, plus the panel's own response time. On a 144 Hz display that wait is up to about 6.9 milliseconds. The measurement environment panel on this page shows the frame interval your browser is actually running at, so you can see the size of that term for your own setup.
Why does the timer start inside a requestAnimationFrame callback?
Because the moment JavaScript decides to change a colour is not the moment the colour exists. A naive implementation reads its start timestamp right after setting the style, which counts one whole frame of rendering work as part of your reaction. This page applies the colour change in one animation frame callback and takes the reference timestamp in the next one, so the stopwatch starts at the frame that carried the green fill to the compositor. That removes roughly one frame of systematic error.
Are my results sent anywhere?
No. The test runs entirely in your browser. Nothing about your keystrokes or your results is transmitted, and there is no analytics or advertising script on this site. Saving a result stores it in your own browser's local storage only, and you can clear it at any time from the privacy page.