Skip to content
Lizely

Reaction Time Test

Measure the interval between a browser's visual go signal and your press, with exact recent, best, and average millisecond results.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Select Start test, keep the panel visible, and wait without pressing while it displays the waiting message.
  2. 2.Press the panel, Enter, or Space as soon as the panel turns green and displays PRESS NOW.
  3. 3.Repeat under the same device conditions to compare the last five, best, and average values, then Reset all.

About Reaction Time Test

Reaction Time Test measures one narrow interval inside the browser: the time from the moment the page changes its test panel to the ready state until the browser receives your press. Select Start test, wait while the panel says to wait, and press only after it turns green and displays PRESS NOW. The latest result appears in milliseconds. The page also retains the last five completed trials and calculates a best and rounded average for that short local session. Reset all cancels a pending trial and clears every result.

Each trial uses a fresh randomized waiting period from 1,500 through 4,000 milliseconds. The changing delay makes it harder to anticipate the signal from a fixed rhythm. The page records the signal with performance.now at the same callback that changes the ready state, then records the press with another performance.now reading. The displayed result is the non-negative difference rounded to the nearest whole millisecond. A deterministic test fixture proves an exact 234 millisecond case instead of relying only on self-consistent timing code.

Pressing before the green signal is a false start. The pending timer is cancelled, no reaction result is added, and the panel reports Too soon. Start another try to continue. A false start does not erase previous completed trials. The control accepts pointer presses and the Enter or Space key while focused, so the workflow can compare different browser-delivered input paths, but it does not claim those paths are physically equivalent.

The score contains more than human decision time. Display refresh, compositor scheduling, browser task timing, operating-system input handling, mouse or keyboard transport, wireless conditions, and event dispatch can all contribute. A faster or slower number on another device can therefore reflect the system as well as the person. Background tabs, power saving, high CPU load, remote desktop software, and variable refresh behavior can change results. Keep the browser foregrounded and repeat under similar conditions when comparing attempts.

Best is the smallest value among the five retained completed trials. Average is their arithmetic mean rounded to the nearest millisecond. Older results fall out after the fifth completed trial, so the summary describes only the visible recent window. The tool does not apply age tables, percentile rankings, pass or fail labels, sports benchmarks, medical thresholds, or claims about alertness. Those interpretations require controlled protocols and appropriate expertise that this general browser utility does not provide.

For a practical comparison, use the same device, input method, browser, window position, and display mode. Complete several trials rather than treating one outlier as a conclusion. If testing mouse and keyboard responses, reset between groups and label the conditions outside the page because the widget deliberately stores no experiment notes. Avoid comparing a foreground local browser with a streamed or remote session unless end-to-end system delay is the intended subject.

This is not a calibrated hardware latency meter. JavaScript cannot observe the physical instant a finger moved, a switch closed, a wireless packet left a device, or a display pixel emitted green light. The page also does not test hearing, diagnose neurological conditions, assess fitness to drive, recommend training, or certify competitive performance. If safety, health, employment, accessibility, or purchasing decisions depend on reaction measurement, use an appropriate controlled instrument and qualified guidance.

All timing state remains in the current tab. The widget does not request a login, upload presses, identify input hardware, save a leaderboard, or persist history after reload. Its contract is intentionally limited: choose a bounded randomized wait, reject early presses, time browser signal-to-event intervals with a monotonic clock, retain five non-negative integer results, and disclose the software and hardware layers included in the number.

Methodology & sources

Generate an integer wait from 1,500 through 4,000 milliseconds with Math.random. Record start, signal, and press using performance.now. A press during waiting cancels the trial as too early; a press after the signal stores max(0, round(press-signal)). Retain only the latest five completed integer results, compute best as the minimum and average as the rounded arithmetic mean, and keep all state in the current tab. Tests cover both delay endpoints, invalid random inputs, false starts, an exact 234 ms golden path, bounded history, and summary validation.

Frequently asked questions

What exactly does the millisecond result measure?
It measures the browser interval from its ready-state callback to the pointer or keyboard event it receives. Display, browser, operating system, and input-device delay can all contribute.
What happens if I press too early?
The pending trial is cancelled and marked Too soon. No result is added, and earlier completed history remains available.
Is this a medical or hardware diagnostic?
No. It is an informal browser timing utility and cannot isolate human response, display latency, device transport, switch behavior, or health conditions.

Related tools

Device & Productivity guides

View all