How it works

Measurement methodology

Most online reaction time tests tell you a number and nothing about where it came from. This page documents exactly what this site measures, what it corrects for, and — just as importantly — where a browser measurement stops being meaningful. Every constant quoted here is the one the code actually uses.

If you only take one thing from this page: a browser reaction time is a real elapsed time, but it is not a laboratory measurement. Published work comparing two apparatuses on an identical task found the same participants roughly 65 ms slower on a computerized battery than on a falling ruler (Eckner et al. 2010). That gap is larger than most of the differences people come here to investigate.

1. The clock

Every reaction time on this site is an elapsed-time reading fromperformance.now(), the browser high-resolution timer defined by theW3C High Resolution Time specification. It is monotonic and unaffected by wall-clock changes, so a tab that was backgrounded or a clock adjustment mid-attempt will not corrupt a result.

Date.now() is used in this codebase for exactly one purpose: stamping when a record was written. It is never used to measure anything. That distinction matters, because Date.now()can jump backwards if the system clock is corrected mid-session.

2. What is actually being timed

The interval starts at stimulus onset — the single point in each mode where the signal is committed, not where a frame is painted — and ends at the input event. Onset is recorded once per mode and cannot be double-counted: until it is set, any input is treated as unmeasurable and discarded rather than being turned into a suspiciously low result.

Input is read from pointerdownand keydown. The site deliberately does not wait for click, which fires after release and would add the time you spent lifting your finger. Auto-repeat from a held key is rejected.

The reported number

A raw measurement is never shown directly. It is rounded to a whole millisecond, has the measured device latency subtracted when compensation is enabled, and is floored at 1 ms. The floor is there to make an impossible value visibly impossible rather than to display a zero.

3. Why you cannot predict the signal

The wait before each stimulus is a uniformly distributed integer between 1000 and 3000 ms inclusive, drawn fresh for every attempt. Two consequences follow from that being genuinely uniform rather than roughly uniform:

There is no rhythm to learn. Because the interval is redrawn each attempt, no strategy of counting or tapping to a pattern helps. This is the single most important property of the test.
Calibration cannot distort it. The draw takes no calibration argument at all, so enabling latency compensation or screen-scale correction provably cannot change the delay distribution.

Responses during the wait are caught as too early and never recorded, so pressing in anticipation cannot inflate a history. After a response window of 2000 ms elapses the attempt is recorded as missed rather than silently discarded, because an incomplete run should be visible.

Fixed constants used by the five-mode console
Constant	Value	Why
Pre-stimulus delay	1000–3000 ms, uniform integer	Blocks rhythmic anticipation
Response window	2000 ms	Long enough for a real response, short enough to stay honest
Re-arm guard	250 ms	Debounces a terminal state so one attempt cannot score twice
Reported floor	1 ms	Makes an impossible value visibly impossible
Latency probe range	0–150 ms, median of ≥3 samples	Rejects absurd readings instead of subtracting them
History cap per mode	100 records	Bounds local storage growth
Sanity ceiling	60 000 ms	Rejects values from a tab left open

4. Latency compensation, and what it cannot fix

Your keyboard, mouse, or touchscreen adds delay between the physical action and the browser hearing about it. The probe measures this by timing five real interactions againstperformance.now() minus the event's own timeStamp, discards samples outside 0–150 ms, and takes the median of what remains. Fewer than three accepted samples means no compensation is applied at all, rather than a guess.

Three limits are worth stating plainly:

It measures input delay, not display delay. The time your screen takes to show the stimulus after the code decides to show it is invisible to this probe. On a high-latency display, part of what it adds is not something this site can subtract.
A median is robust, not exact. It discards the jitter that makes Bluetooth devices unreliable, but it will not track drift within a session.
It is off by default. Every mode works immediately with no setup, and a result is never silently adjusted.

Hardware latency breakdown diagram illustrating monitor refresh frame intervals (60Hz, 144Hz, 240Hz), USB polling lag, and browser render pipeline latency — **Input Latency Stack:** Hardware display frame pacing (16.7ms on 60Hz vs 4.2ms on 240Hz) and USB polling intervals add external latency that exists outside human biological reaction.

Screen-scale calibration

This one applies to Ruler Drop only. You measure your display's diagonal in inches, and the ruler's centimetre markings are redrawn at true physical pitch for that size. The reason it matters: the ruler's centimetre value is derived from your measured time using the falling-body relation below, not read off the screen. Correcting the pitch means the displayed ruler is honest about its own scale, so the centimetre figure next to your time is not misleading. It does not change your reaction time at all.

Ready gate

With the ready gate on, the stimulus waits for you to press a ready button instead of starting on a timer. This removes anticipatory presses, which matters most for people who test repeatedly and have learned to pre-move.

5. Why the ruler is a timer, not a falling object

A real ruler-drop test measures the distance the ruler fell and converts it to a time usingd = ½gt². This site does the opposite, and deliberately so.

The ruler on screen is animated by the same high-resolution timer that records your response, with the fall eased quadratically rather than linearly. Your score is the elapsed time between onset and your input. The centimetre figure shown alongside is thencomputed from your time usingd = ½gt² withg = 981 cm/s².

Why this direction matters: because the on-screen fall is eased rather than physical, pixel position is not convertible back into elapsed time. A person cannot measure the ruler with a screen ruler and recover the correct time, and no measurement shortcut can forge a result from the animation. The score comes only from the timer.

6. Where the percentile comes from

A result's rank is computed, not looked up. Each mode has an assumed mean and standard deviation; the score is converted to a z-score and the upper tail of a normal distribution is evaluated with an error-function approximation (Abramowitz & Stegun 7.1.26, maximum absolute error about 1.5×10⁻⁷), then clamped to 1–99.

Assumed baselines per mode — a model, not a measured sample
Mode	Assumed mean	Assumed SD
Ruler Drop	250 ms	50 ms
Colour Change	250 ms	50 ms
Fake-Out	300 ms	60 ms
Speed Click	150 ms	40 ms
5-Trial Challenge	250 ms	40 ms

These numbers are assumptions baked into the scoring model. They are not derived from this site's users, because your scores are never collected. Speed Click's figure is milliseconds per tap, not a reaction time, so it is not comparable with the others.

Human reaction time distribution bell curve chart showing benchmark tiers from pro gamer to average human response — **Theoretical and Empirical Distribution:** Standard normal distribution model used to translate raw millisecond scores into population percentiles.

7. How your results are stored

Every attempt is written to localStorageunder a per-mode key, capped at 100 records, with a 60-second sanity ceiling on any stored value. No score is transmitted anywhere. The statistics panel shows your latest result, your best, the arithmetic mean across all stored records for that mode, and a sparkline over the most recent 20.

Because storage is per-browser, clearing site data erases your history permanently and your figures will not follow you to another device. That is a feature of not having a server, and it is also a real limitation.

8. Limits you should design your reading around

Compare your results to your own results. The measurement that matters is the change in your own number under controlled conditions. Comparing a browser score to a published laboratory figure compares two different apparatuses.
Discard the first attempt. Repeated measurement produces a real but front-loaded improvement that plateaus quickly — about 13 ms across ten sessions, nearly all of it in the first two (Del Rossi et al. 2014).
Use a wired input. Bluetooth peripherals add variable delay that the probe can only partly remove, and they are the single most common cause of an unexpectedly slow score.
Close the tab between sessions. A backgrounded tab is throttled, and the first attempt after returning is not comparable to one taken with the page in the foreground.
Do not read a single outlier as signal. Individual attempts vary substantially. The mean over at least five attempts is the meaningful figure, which is why the site records a mean alongside your best.
This is not a clinical instrument. Nothing on this site assesses a health condition, and no result should be interpreted as one.

Reference values

Laboratory reference figures for simple reaction, fromKosinski (2013): roughly190 ms for light stimuli and160 ms for sound in college-age adults — the long-standing consensus of about 120 years of work. Age-graded values follow the meta-analysis inDer & Deary (2006). Expect browser scores to sit slower than the laboratory figures, for the reasons above.

Measure your own

Pick a test and run it. If you want the most comparable number, use the five-mode console, discard your first attempt, enable latency compensation, and stay on a wired input.