The short version
Every test runs in your browser, on your device. A few scored tools send us the final score for anonymous statistics, and nothing else about your run (the privacy policy lists them). 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
Left alone, a browser doesn't hand a page every report your mouse sends. On the regular cursor path it bundles moves once per frame, and Windows drops any the browser can't take in time. So the test locks your cursor for the 5-second run and asks for raw input. In Chrome and Edge on Windows, that reads each report straight from the system's raw input stream, not the cursor. Each pointer event still carries the samples merged into it. We count samples, not events.
The rate is then the sample count divided by the time those samples span, taken over a rolling one-second window. Three details matter. We time each batch by the timestamp of its last sample, not by the moment the page gets to it, so a frame that runs late can't inflate the rate. We drop the first batch in the window. A run of samples spans one fewer gap than it has samples, so counting them all would read slightly high. And we never time the gaps between single samples. A browser stamps each sample when the system hands it over, not when the mouse sent it. It also rounds the time to a tenth of a millisecond or coarser, too coarse for an 8000 Hz mouse that sends a report every 0.125 ms.
The limit: raw input depends on the browser. Our Logitech PRO X Superlight 2 DEX set to 8000 Hz read 7850 to 7980 Hz with raw input in Chrome on Windows. Over the regular cursor path the same mouse read 3300 to 3900 Hz. On that path Windows sends nothing for movement smaller than a pixel and keeps only the latest move when the browser falls behind. A browser that refuses raw input lands there too, and Firefox accepts raw input but still dropped reports from our 8000 Hz mouse. Either way the test shows an "or faster" badge, because past 1000 Hz the number is only a floor. We haven't measured a Mac, where macOS merges mouse movement before the browser sees it. Keep the mouse moving fast the whole run, too. An idle mouse sends nothing.
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 and record the gap between callbacks. The refresh rate is one second divided by the average gap over the last 120 frames. A panel that repaints every 6.94 ms is running at 144 Hz. Any gap longer than one and a half times the typical one counts as a dropped frame and stays out of that average, so one hiccup can't pull the reading down. A browser can't read a monitor's rating, so you pick it. If the reading lands within 2 percent of your pick, we call it full rate.
The limit: what we measure is what the browser presents, and that isn't always what the panel can do. 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, rule those out before you blame the screen. The frame time chart has the same limit. It shows the browser's frame pacing, not the panel's own scanout. Some overclocked panels skip refreshes on their own, and that looks clean here. Catching that takes a camera.
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.
Aim trainer
Your mouse reports movement in counts. We read them raw through the browser's pointer lock and turn the view by your game's angle per count times your sensitivity, the same rule the game applies. A shot hits when the angle between your crosshair and the center of a target is no larger than the target's radius, so a hit means the same thing at any screen size. Tracking and Switch have no shots: a target dies once your crosshair has stayed on it for one second in total in Tracking, or 0.4 seconds in Switch. Targets spawn at random spots inside a fixed field, never on top of your crosshair or each other. The score is kills in 60 seconds, and only a full run counts.
After the run we cut it into twelve 5-second parts and count the kills in each. We time each kill from the one before it, and the first from the start of the run. You see the fastest, the median and the slowest. In Flick and Gridshot, a miss within three target radii of the nearest target gets a direction. We draw a line from your previous shot to that target. A miss past the target along that line is an overshoot, and a miss short of it is an undershoot. We skip misses farther out. A stray shot says nothing about a flick. In Tracking and Switch we log the share of each 5-second part your crosshair spent on a target.
The limit: without raw input, Windows pointer acceleration changes your turn speed, and the page tells you when that happens. We redraw the view once per display frame, so on a 60 Hz screen a fast flick shows fewer in-between steps than it does on a faster panel, even though every count still lands. For most shooters, one angle per count is the whole rule. Warzone isn't one of them: it also scales aim with FOV and when you aim down sights, so we get close but not exact. There's no recoil here, and you never move. The score is your aim in this drill, not in a match. The overshoot split only checks where a miss falls along that line. A miss that's mostly off to one side still counts as one or the other, depending on whether it sits past the target or short of it. Only the landing point counts, not the path your crosshair took to get there. A kill time holds your reaction and your flick together, so it isn't a pure measure of either.
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.
Touchscreen
We cut the test area into squares about the size of a fingertip, 48 CSS pixels a side. Every touch the browser reports carries a position, and the square under it fills in. Nothing fills in between two reports: if a fast swipe jumps over a square, that square stays empty, because no touch was ever seen inside it. We also follow the path of your first finger. When that touch drops out and comes back a moment later, we note where it dropped, but the drop only counts against a square that never filled in, since lifting a finger to reposition looks the same as a dropout. For ghost touches we stop painting, run a 10-second countdown, and record every new touch that arrives while your hands are away. The finger count is the most touches we saw at once, set against the number the browser says your device supports.
The limit: a dead line thinner than one square can hide, because touches on either side of it still fill in the square it crosses. Most phones report a limit of five touches, so a count that stops at five may be that limit, not a fault. An iPhone won't let a web page take over the whole screen, so Safari keeps its toolbars and the strips under them go untested. The square size and the dropout window are starting values we haven't tuned on damaged screens yet. Treat a red square as a spot to test again. It records what this device reported during this run, nothing more.
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.