The short version
Nothing is uploaded. Every test runs in your browser, on your device, and the result never leaves it. That also sets the limit of what we can honestly claim: a web page reads what the browser hands it, and a browser is not an oscilloscope. Where that matters, we say so below instead of quietly rounding the problem away.
Polling rate
A browser does not deliver every report your mouse sends. It bundles them up and hands them over once per frame, so on a 60 Hz screen a naive test would see a 1000 Hz mouse as a 60 Hz mouse. We avoid that by reading the raw stream underneath: each pointer event carries the sub-frame samples that were merged into it, and we count those instead of counting events.
The rate is then the sample count divided by the wall-clock time those samples span, taken over a rolling one second window. Two details matter. We drop the first entry in the window, because a run of samples spans one fewer gap than it has samples, and counting them all would report a rate slightly higher than the truth. And we never time the gaps between the samples themselves, because some browsers report a timestamp of zero on merged events, which would produce a spectacular and entirely fictional reading.
The limit: this works because Chromium hands over the full sample stream. Browsers that expose only one sample per frame cap the reading at your display refresh rate. If a 1000 Hz mouse reads as 60 or 144, that is the browser, not the mouse. The number also needs continuous motion to exist at all, which is why the tool keeps your peak reading on screen after you stop moving.
DPI
Windows and macOS both massage mouse input before an application sees it, so pointer acceleration would otherwise contaminate the result and force you to disable it first. We ask the browser for locked, unadjusted movement instead, which is the raw sensor travel with the operating system's curve taken back out. On browsers that refuse that request we fall back to a plain pointer lock, which still measures, but is subject to whatever acceleration you have configured.
You tell us the physical distance you moved, we convert it to inches, and real DPI is the counts the sensor reported divided by those inches. We sum the absolute movement rather than the net displacement: if your hand drifts back a few millimetres mid swipe, net displacement would silently understate the count, while absolute travel does not. Accuracy is your measured DPI against your configured DPI, and we treat anything within five percent as correct.
The limit: the weakest part of this measurement is the ruler, not the code. Your reading is only as good as the distance you typed in, so a sloppy 10 cm is a sloppy result. Measure carefully and run it more than once.
Refresh rate
We ask the browser to call us back before each screen repaint, record the gap between those callbacks, and take the average. The refresh rate is one second divided by that mean gap. A panel that repaints every 6.94 ms is running at 144 Hz.
The limit: this measures what the browser is presenting, which is not always what the panel is capable of. A background tab, a laptop on battery saver, a browser throttling frames, or a display running below its rated mode will all read low. If the number looks wrong, check the setting before you blame the screen.
Reaction time
We wait a random interval, change the screen, and record the time until your click. We keep every attempt and report both your best and your average, because a single lucky attempt is not a reaction time. Clicking before the change is caught and thrown out rather than rewarded.
The limit: what you are measuring is you plus your whole chain of hardware. Display latency, refresh interval, mouse polling, and browser scheduling all sit between the pixel changing and your click landing. The number is real and it is comparable against itself over time, but it is not a laboratory measurement of human reflex, and no browser test can be one.
Click speed
Clicks divided by seconds. That is genuinely all it is. During a run we divide by the time elapsed so the rate updates live, and at the end we divide by the full test duration.
Why we tell you this
Every hardware test on the web claims accuracy. Very few of them tell you what their number cannot see. Knowing the shape of a measurement's error is what separates a diagnosis from a guess, and if you are trying to work out whether a mouse is failing or a screen is dropping frames, you deserve the real shape.
If you think a measurement here is wrong, tell me and show your working. Email contact@rigpolice.com, or read more about who built this and why. Measurements get corrected, and being wrong in public beats being quietly inaccurate.