Before you start
Mouse polling rate is how often a mouse reports its state to the host, expressed in hertz. At 125 Hz a report arrives every 8 ms; at 1000 Hz, every 1 ms. That interval is the upper bound on how quickly a movement can begin to be processed — it is not, by itself, the latency you feel.
Before measuring anything, separate the question from unrelated complaints. A missing button, a duplicate click or a pointer that jumps across the screen are not polling-rate problems, and no rate measurement will diagnose them. Mouse polling rate is only about how frequently movement updates arrive.
Keep the tab in the foreground and pick a stable surface. Background tabs are throttled aggressively by every modern browser, and a poor tracking surface produces the same irregular intervals that a low report rate would.
Run the check
Open the polling rate test and move the pointer in smooth continuous circles for several seconds. Continuity matters more than speed: the estimate is built from the intervals between consecutive movement events, so pauses contaminate the sample with gaps that are not device behaviour.
The tool stores movement timestamps in a fixed-size buffer, rejects zero, negative and extreme gaps, and then derives the median interval rather than the mean. A median is the right choice here because a single scheduling hiccup would drag an average far more than it should.
Read the uncertainty band, not just the headline number. Median absolute deviation is converted into a plus-or-minus range around the estimate, and that range tells you whether the sample is worth anything. A stable 1000 Hz ± 40 is informative; 1000 Hz ± 400 means try again.
Repeat the run at least twice. Two runs that agree within their stated ranges are evidence; one run is an anecdote, and this is precisely the kind of measurement where a single number invites over-interpretation.
Read your result
Expect the browser figure to sit at or below the device setting, often noticeably below. Browsers coalesce pointer movement and frequently align event dispatch with rendering, so a 1000 Hz mouse commonly reads somewhere between 500 and 1000 Hz on a page. That is the browser working as designed, not the mouse underperforming.
If the reading pins near your display refresh rate — around 60, 120 or 144 — you are almost certainly seeing coalescing rather than the device. Comparing a second browser is the fastest way to confirm it, because coalescing behaviour differs between engines.
Compare ranges rather than integers when you change something. Moving from one USB port to another, or switching from wireless to cable, is meaningful if the two ranges do not overlap. If they overlap, you have not measured a difference.
Measurement limits
This measurement cannot read the device report rate. It measures how often pointer events reach a web page, which is the end of a chain containing the sensor, the firmware, USB transport, the operating system, the browser event loop and its coalescing policy. Any of those can lower the observed figure.
Above roughly 2000 Hz the estimate stops being trustworthy, because the interval between events approaches the resolution and scheduling noise of browser timers. Mice sold at 4000 or 8000 Hz cannot be verified here, and a tool that prints a confident number in that range is not telling you the truth.
None of this measures latency. Polling rate sets how often updates can arrive; end-to-end latency also includes rendering, compositing and display scan-out, which is why a mouse latency test reports much larger values than 1 ms.
What to do next
If the browser-observed range is stable and matches expectations, the polling question is closed — move on to whatever the actual complaint was.
If it is consistently and substantially lower across two browsers, it is worth checking the physical path: a direct port instead of a hub, a different cable, and a wireless receiver moved closer to the mouse. These change real report rates in ways that show up here.
If someone is choosing between a 1000 Hz and an 8000 Hz mouse, the honest answer is that the measurable difference is 0.875 ms per report and that most people cannot perceive it, while the extra CPU load from very high rates is real. Buy for sensor quality, shape and weight instead.
Symptom table
| Symptom | Likely layer | Next action |
|---|---|---|
| Rate jumps between bands | Short sample or scheduling variation | Move continuously and collect a longer range |
| Rate is capped near refresh | Event coalescing or rendering alignment | Compare another browser in the foreground |
| No rate appears | Too few valid intervals | Use smooth continuous movement in the stage |
Common questions
Is 1000 Hz polling actually better than 500 Hz?
The theoretical gap is one millisecond per report. It is measurable, and competitive players often prefer it, but it is far smaller than the differences produced by display refresh rate, frame pacing or your own reaction time.
Why does a browser show a lower polling rate than my software?
Because a page sees events after coalescing and after the browser has aligned input with rendering. The vendor tool reads the device directly; the browser reads the end of a much longer chain.
Does a higher polling rate reduce input lag?
Slightly, and only for the reporting stage. The rest of the chain — rendering, compositing and display scan-out — is measured in whole milliseconds and dominates what you actually feel.