Mouse Reaction Time Test
Five trials. Each trial waits a random 1.5–4 seconds, then flashes a "Click!" signal. Click as fast as you can. The test measures the time between the on-screen signal and your pointerdown event — browser-observed, including display pixel latency, browser event loop delay, and OS input processing. A native desktop tool with a locked display can measure lower. Treat it as a comparison number, not a lab result. Runs locally, no data leaves your device.
Run the test
Five trials. Each trial: wait for the Click! signal, then click as fast as you can. The test measures the time between the on-screen signal and your pointerdown event —browser-observed, including display, browser, and OS pipeline latency. A native desktop tool with a locked display can measure lower. Treat it as a comparison number, not a lab result.
Nothing you click leaves this tab. No storage, no network requests. Refresh clears the session.
How this works (keyboard-accessible explanation)
The measurement itself is pointer-only: the test records the time between the visual "Click!" signal appearing on screen and your mouse button pressing down (pointerdown). Keyboard users can read this explanation and the results, but cannot trigger the measurement — the test requires a mouse click.
Each trial waits a random 1.5–4 seconds before showing the signal. Clicking during the wait counts as a false start and restarts that trial.
Browser-limited label: The number includes display pixel latency, browser event loop delay, and OS input processing. A native desktop tool bypassing the browser measures lower. Compare runs in the same browser on the same display for fair comparison.
Wait…
Trial 1 of 5
Wait for the green "Click!" signal. Clicking early restarts the trial.
What this measures
- Click latency from on-screen "Click!" signal to pointerdown, as the browser observed it, for each of 5 trials.
- Median reaction time across the 5 trials (primary result).
- Mean, best (fastest), and worst (slowest) trial times.
What this cannot measure
- True physiological reaction time — the number includes display pixel latency, browser compositing and event loop delay, and OS input processing. A native desktop tool bypassing the browser measures lower.
- Display pixel response time below the browser's observation — the signal timestamp is taken when the browser paints the frame, not when pixels actually change.
- Keyboard reaction time — the measurement is pointer-only (mouse click). Keyboard users can read the method and results but cannot trigger the measurement.
- Whether a slow trial is due to attention lapse, motor delay, or pipeline latency — the test only reports the total observed interval.
How to get a steady reading
- Use the same mouse and surface for every run you want to compare.
- Close background applications that might add system latency.
- Do all 5 trials in one session — the median of 5 is more stable than a single trial.
- Do not pre-move the mouse or tense your finger before the signal — wait naturally.
- Run in the same browser on the same display for fair comparison. Different browsers and displays add different pipeline latency.
How to read the results
| Metric | What it means |
|---|---|
| Median | The middle value of the 5 trials when sorted. The primary result — less affected by a single outlier than the mean. |
| Mean | Arithmetic average of the 5 trials. Useful alongside the median; a large gap suggests an outlier trial. |
| Best | Fastest single trial. Shows your peak performance but may be a lucky guess or anticipation. |
| Worst | Slowest single trial. Often an attention lapse or a delayed signal paint. The browser-limited caveat applies to all four numbers. |
What the number actually contains — display + browser + OS + hand
When the test flips to "Click!", several things happen before your click registers: the browser paints the new frame (display pixel response time), the display shows it (refresh cycle timing), your visual system processes it, your motor system initiates a click, the mouse sends the signal, the OS processes the interrupt, the browser receives the pointerdown event, and the test records the timestamp. The measured interval includes all of it.
This is why the test is labeled "browser-observed." A native desktop tool that writes directly to the display hardware and reads raw mouse input from the OS kernel bypasses the browser compositing and event loop layers. It can measure lower — sometimes significantly lower. Our number is not "wrong"; it is a different layer of the stack.
The random 1.5–4 second wait prevents anticipation. Clicking during the wait counts as a false start and restarts that trial. This keeps the measurement honest — you must react to the signal, not guess the timing.
Why native desktop tools measure lower
A browser is a general-purpose application. Input events travel: hardware → OS kernel → OS input subsystem → browser process → browser event loop → JavaScript callback → performance.now(). Each hop adds microseconds to milliseconds. Display compositing adds another frame of latency (typically 1–2 frames at 60–144 Hz).
A native tool can: use a real-time OS thread, lock the display refresh (flip at a known scanline), read raw input directly from the kernel (bypassing OS windowing), and timestamp at the interrupt handler. The gap varies by system but is real. This does not make the browser test "useless" — it makes it a browser-layer measurement. Compare browser-to-browser, not browser-to-native.
Comparing runs fairly
To track improvement or compare mice: same browser, same display, same refresh rate setting, same time of day (background load), same mouse and surface. Change one variable at a time.
The median of 5 trials is the most stable single number. A single trial can be an outlier — an attention lapse, a GC pause, a display frame alignment quirk. The median filters that.
If you switch browsers, expect different baselines. Chrome, Firefox, and Safari have different event loop scheduling and compositing pipelines. The test is honest about this: the label says "browser-observed" for a reason.
The browser-limited label explained
Every result screen shows: "Browser-observed: this includes display, browser, and OS pipeline latency. A native desktop tool with a locked display can measure lower. Treat it as a comparison number, not a lab result." This is not a disclaimer to dismiss the result — it is context so you know what you are comparing.
If you use this test to compare two mice in the same browser on the same display, the difference is real and meaningful. If you compare your number to a native-tool result from a review site, the gap is expected and does not mean your mouse or browser is "slow."
Clinical studies of human visual reaction time commonly cite roughly 200–300 ms under controlled lab conditions (fixed display, simple stimulus, no browser). In a browser, expect higher numbers. The test does not claim to measure the clinical number — it measures what the browser observes.
Frequently asked questions
What is a good reaction time?
Clinical settings commonly cite roughly 200–300 ms for human visual reaction time under controlled lab conditions. In a browser, expect higher numbers due to display, browser, and OS pipeline latency. The test shows your browser-observed median — compare it to your own past runs in the same browser, not to clinical benchmarks.
Why is my number higher than other testers show?
Different testers measure at different layers. Some native desktop tools report lower numbers because they bypass the browser. Browser-based testers vary by how they timestamp the signal (some use requestAnimationFrame, some use performance.now() at paint, some use CSS animation events). This test uses performance.now() at the moment the "Click!" state is applied to the DOM — a conservative, honest timestamp. Compare runs within this test only.
Can I test keyboard reaction time?
No — the measurement is pointer-only (mouse click). The test requires a pointerdown event to stop the timer. Keyboard users can read the full method explanation and results on this page, but cannot trigger the measurement itself. This is stated honestly in the copy above the test.
Does it save results?
No. The test runs entirely in your browser tab. No data is sent to any server. No history is saved. Refreshing the page clears the session completely.
Related tests
Mouse Polling Rate Test
Live Hz, stability graph, and variation — browser-observed, not a hardware measurement.
Mouse Click & Double-Click Test
Five-button registration, press counts, and possible-bounce detection — no fault verdict.
Mouse Drift Test
Hand off the mouse for 15 seconds — counts browser-reported movement events and total pixels.
Mouse Tests Hub
Overview of all mouse tests: polling rate, click/double-click, scroll, drift, and reaction time.
Last reviewed 2026-10-12