By Eric, BlinkBench Founder · Last reviewed: September 2026
A score on this site is never just you. It is a compound of four things stacked together — your display, your input device, your own trial-to-trial variance, and, where one exists, a reference range drawn from a study that used none of your equipment. This page puts all four in one place, in roughly the order they matter, so a single reading tells you how much of the number is a measurement of you and how much is a measurement of your hardware.
Every other guide on this site works out one of these four in detail. This one is the map, not the territory — read it first, then follow whichever link goes deeper than you need.
| Source of uncertainty | What it does to a score | Covered in full |
|---|---|---|
| Your display | Adds a fixed, computable delay before any stimulus can appear | Screen refresh rate |
| Your input device | Adds delay a browser can't measure, and changes by device type | Input device cost · touch vs. keyboard |
| Your own trial-to-trial spread | Usually larger than the gap between you and the next person | Within-person variability |
| The comparison population | Decides whether a percentile means anything at all | Reaction time percentiles · chance level |
1. What your display contributes
A monitor can only change what it shows once per refresh. A stimulus “shown” at an arbitrary instant actually appears somewhere in the next frame, uniformly between 0 ms and one full frame period — so on average it costs half a frame, computed directly from the refresh rate your own browser reports:
| Refresh rate | Average display contribution |
|---|---|
| 60 Hz | 8.3 ms |
| 75 Hz | 6.7 ms |
| 120 Hz | 4.2 ms |
| 144 Hz | 3.5 ms |
| 240 Hz | 2.1 ms |
Computed by displayUncertaintyMs() in lib/apparatus.js — the same function every timed test on this site calls to print its own apparatus statement.
This is the one source of uncertainty a web page actually can measure, because the refresh rate is a fact the browser reports rather than a guess. Everything below this line is real and larger, but not directly measurable from here — which is also why it gets a caveat rather than a number.
2. What your input device contributes
Polling rate, transport (USB, Bluetooth, a touchscreen digitizer) and OS event delivery add more delay on top of the display, and this site deliberately does not invent a figure for it — a browser has no API that reports it. What can be said is the shape of the effect: it is real enough to change which reference range applies. On the typing speed test, one- and two-finger phone typists reach roughly 70% of the speed the same people show on a full keyboard — the reason that page cites two reference ranges, one per input type, instead of one adjusted number. The full arithmetic for the cost of a specific device is in how much your input device really costs you, and the mobile-versus-desktop gap generally is in why your phone and your keyboard don't give the same score.
3. What you contribute, trial to trial
Even holding equipment constant, a single person's reaction time is not a fixed number — it is the output of a process competing with everything else the brain is doing at that instant. In the Woods et al. reference range this site cites, the mean simple reaction time of 231 ms carries a standard deviation of 27 ms within the sample — and trial-to-trial spread inside one person's own session runs on a similar order. That is frequently larger than the gap you'd see between two different people's single trials, which is the whole reason a one-off comparison between you and a friend is close to meaningless while a comparison between your own sessions is genuinely informative.
It is also why every timed test here reports the median of a trial set rather than the mean or the fastest run — a median resists the one lucky near-anticipation and the one slow lapse that would otherwise drag a single number around. The full reasoning is in why every timed test here reports the median, not the average, and the mechanics of trial-to-trial noise specifically are in why reaction time varies more within you than between you and someone else.
4. What the comparison itself is worth
A percentile needs a described population, measured on comparable equipment, filtered by a stated rule, on the same task. Ask those four questions of most percentiles shown on a reaction-time or memory site and the answer to at least one is “unknown” — which is why this site shows one only where a published study can answer all four, and says so plainly where it can't. The four questions, worked through in full, are in why reaction time percentiles are usually made up.
Where no defensible range exists at all — as on visual memory, whose published norms sit in a printed manual that wouldn't transfer to a browser if we had it — the honest substitute is a chance level: the exact odds a blind guess would have produced your score, computed from the rules of the test rather than borrowed from a crowd. It needs no population at all. What it is and isn't good for is in what “chance level” means, and why it beats a percentile.
Does retaking a test change any of this?
Retaking a test moves you along axis 3 above, not axis 4 — a second attempt narrows your own trial-to-trial noise around your true median, it doesn't make you a different person being compared against a different crowd. Whether repetition also raises the underlying number, and by how much, is its own question with a real answer: see can you practise your way to a better score? This site will never claim a retake makes you faster or sharper — only that it gives a cleaner read on the number you already had.
The short version
Display and input device set a floor under the number that has nothing to do with you. Your own trial-to-trial variance is usually the largest single source of spread, and it's why a median of several trials beats any one reading. And a comparison to other people is only as good as the population, equipment and filtering behind it — which is most of the time worse than it looks, and sometimes doesn't exist at all. None of that makes the number meaningless. It makes it a reading with a band around it, not a verdict, which is the whole idea behind this site.
Frequently asked questions
Why doesn't BlinkBench show a percentile on every test?
Because a percentile is only as good as the population, equipment and filtering rule behind it, and most of the time at least one of those three is unknown or unstated. Where a published study supplies all three, this site cites it. Where none does, it says so rather than computing one from its own visitor traffic — an unvetted, self-selected, hardware-mixed sample that would produce a number with the appearance of precision and none of the substance.
Is a slower score on my phone a worse score?
Not necessarily — it's often a different apparatus, not a worse performance. Touch input and keyboard input measure through different hardware with different latency profiles, which is why tests whose result depends on input type cite a separate reference range per device rather than one shared number.
How much of my score is really the equipment?
The display's share is computable and shown above. The input device's share is real but not measurable from a browser, so this site states that it adds more without inventing a figure for it — see the apparatus note under whichever test you ran for the exact display number your own hardware produced.
Can I compare my score to a published study directly?
With caution, and only where one is cited. A laboratory study's equipment and recruitment are never identical to a browser test taken on your own hardware, which is why this site shows the range as context beside your score rather than converting it into a rank.
Sources
- Woods, D. L., Wyma, J. M., Yund, E. W., Herron, T. J., & Reed, B. (2015). Factors influencing the latency of simple reaction time. Frontiers in Human Neuroscience, 9, 131.
- Palin, K., Feit, A. M., Kim, S., Kristensson, P. O., & Oulasvirta, A. (2019). How do People Type on Mobile Devices? Observations from a Study with 37,000 Volunteers. MobileHCI '19.