Mouse polling rate test
The polling rate is how many times a second the mouse reports its position to the computer, in Hz. 1000 Hz means a report about every 1 ms, and the higher the number the more closely the cursor tracks. Press the button below to start, then hold and draw fast circles anywhere on this page — the faster you draw, the closer the reading gets to the truth.
Live polling rate
Each bar is the measured rate for one 200 ms window, with time along the horizontal axis. A steady mouse should give a row of bars of about the same height; orange bars mean that window fell clearly below the nominal tier — usually you just drew slower for that instant, not a fault in the mouse.
Reference values
These are the common tiers. The interval is 1000 ÷ Hz — how many milliseconds apart the mouse will report its position.
| Rate | Interval | Typical use | Notes |
|---|---|---|---|
| 125 Hz | 8 ms | Office / basic mice | Stepping is visible in cursor movement |
| 250 Hz | 4 ms | Entry gaming | Noticeably smoother than 125 Hz |
| 500 Hz | 2 ms | Gaming | The value sweet spot for most players |
| 1000 Hz | 1 ms | Pro esports | The mainstream high-end tier today |
| 2000 Hz | 0.5 ms | High-end esports | Needs a 144 Hz or faster screen to show any difference |
| 4000 Hz | 0.25 ms | Top-tier esports | CPU usage starts to become noticeable |
| 8000 Hz | 0.125 ms | Flagship | The refresh rate becomes the bottleneck first |
How to read the result
- Current polling rate uses the counting method: over the longest continuous movement, take the sample count divided by the duration. The browser delays when events are dispatched but never drops reports, so the total event count and the total duration are both exact, and the division cancels the dispatch jitter. This is the only unbiased algorithm available in a browser.
- Tier matching snaps the measured value to the nearest nominal tier, within ±8%. Outside that tolerance it reads "unrecognised" rather than forcing a fit — 880 Hz will not be rounded up to 1000 Hz for you.
- Peak cuts the movement into 200 ms windows and takes the highest one: the most this mouse can do. It always runs a little above the true value — the maximum of a noisy set comes back as "true value + positive noise". The good news is the per-window noise is small: over 3 seconds of data it typically overshoots by about 1%, so read it as an upper bound.
- Window spread is how much the per-window rates scatter — how steady the reading is. Like the peak it is built on counts and never touches intervals, so it is trustworthy in a browser. Under 5% is normally steady.
- Move speed — this is the first number to look at when the reading is low. A mouse only sends a report when it has moved somewhere new, so reports per second ≈ pixels moved per second. This is not a bug, but at too low a speed the value it measures means nothing.
Releasing the mouse mid-run does not change the result
The moment you let go or change direction produces no pointer events, leaving a gap of a few hundred milliseconds in the buffer. What this page does is cut the sequence into segments at those gaps, and work only on the longest continuous segment. That is also the root of "it measures differently every time": count the gaps in and a 500 ms pause mixed into 2000 one-millisecond intervals drags the average from 1 ms to 1.25 ms, and the reading falls from 1000 Hz to 800 Hz — and how far it falls depends entirely on when you let go.
This page gives no "jitter" or "packet loss"
That is deliberate, and it was forced by measurement. These metrics all have to be computed from the interval between adjacent events, and the interval is precisely the least trustworthy thing in a browser: the timestamp is the moment the browser got around to that message, not the moment the hardware reported it, and the measured batching smear is 0.3–0.6 ms (a native driver interface is within ±2 µs). The period at 1000 Hz is 1 ms, so that smear alone is enough to push a perfectly normal interval past any "too long" threshold — and a good mouse ends up reporting a packet-loss rate of a few percent. Raising the threshold only hides the illusion, it does not fix the cause, so this page gives no such numbers. Every metric kept on the page — rate, peak, window spread — is built on counts only.
When the reading drifts
- Moving too slowly. Reports per second ≈ pixels moved per second. To saturate 1000 Hz you need to move about 1000 pixels per second on screen; to saturate 8000 Hz, 8000 pixels per second. The "Move speed" figure tells you live whether you are there. Draw with your whole arm — the whole page is the test surface, you do not have to stay inside one small area, and the smaller the circle the lower the speed and the lower the reading.
Put another way: reports per second = DPI × inches moved per second. 800 DPI needs 1.25 inches (about 3 cm) per second to reach 1000 Hz; 1600 DPI needs half that. So when the reading is low, turning the DPI up is usually far less effort than swinging faster. - Timestamps are clamped to 100 µs, so per-event intervals mean nothing. The browser only hands out 5 µs timestamps while the page is cross-origin isolated; otherwise it clamps to 100 µs. An 8000 Hz mouse reports every 125 µs, the same order of magnitude as the quantisation step, so reports landing in the same bucket get lumped together — this page tracks that share live and flags the data as "not trustworthy" once it climbs. The main reading is not bound by this: it uses "reports ÷ duration", and the quantisation touches only the first and last timestamp, a part in ten thousand over a few seconds of movement. What really pulls it down is dropped reports and the browser's own batching, so treat the number above 4000 Hz as a floor. The top of the page states the current resolution (this site restores isolation on GitHub Pages with a service worker; where the browser supports it, that reads 5 µs).
- Not HTTPS — as of Chrome 142, coalesced events are only available in a secure context. Over http this page simply stops working, and there is a notice at the top.
- Firefox — some versions set the timestamp of coalesced events to 0; then only the average rate can be given, with no peak and no window spread. That is a browser implementation difference, not your mouse.
- Wireless mice — a receiver plugged next to a USB 3.0 port can pick up interference and the reading goes unsteady. Try another port.
Common questions
The most common cause is not moving fast enough, not a faulty mouse. A mouse only sends a report when it has moved somewhere new, so reports per second ≈ pixels moved per second. To saturate 1000 Hz you need to move about 1000 pixels per second on screen; 8000 Hz means 8000 pixels per second, which is already quite fast. This page shows your move speed live — check it first when the reading is low. Second, confirm the driver really has the high polling rate mode on: some mice ship at 125 Hz by default and you cannot change it without the driver. A wireless receiver sitting next to a USB 3.0 port can also pick up interference.
Most to least likely. First, move speed — as in the previous answer: a mouse only reports when it moves somewhere new, so a slow drag simply cannot read full, and you should check whether the on-page "Move speed" is high enough. Second, the system and the driver: Windows stops non-foreground windows from receiving raw input (keep this page focused while testing), some wireless mice throttle the polling rate to save power, and a receiver next to a USB 3.0 port can suffer interference. Third, and last, the browser: dispatching pointer events has a cost of its own, and the higher the rate the bigger the discount — one browser-tool author measured 4000 Hz and up coming in one or two tenths below hardware-level tools; getting hardware-level numbers needs an operating-system-level interface (such as Windows Raw Input), which a web page cannot do. So treat anything this page gives above 4000 Hz as a floor.
The current rate is computed over the longest continuous movement, total samples divided by total duration: the steadiest figure, and the right one for telling which tier the mouse is actually running at. The peak cuts that movement into small 200 ms windows and takes the highest, showing "the most this mouse can reach". The peak always runs a little above the true value, because it is the maximum of many noisy windows; read it as an upper bound, not a typical value.
The returns diminish. 125 Hz to 500 Hz is a difference in kind; 500 Hz to 1000 Hz is obvious; above 1000 Hz most people can no longer tell at all — the screen refresh rate usually becomes the bottleneck first. Higher rates also cost CPU: an 8000 Hz mouse typically uses 1–2%.
No. The instant you release or change direction produces no pointer events, and the program cuts the data into segments at those gaps, computing only over the longest continuous one. That is exactly why this page reads steadier than similar tools: an algorithm that counts the gaps in gives a result that depends on when you happened to let go, different on every run.
Because they are too noisy to measure in a browser, and printing them would only mislead. These metrics all depend on the interval between adjacent events, and the timestamp a browser puts on an event is the moment it processed that message — the measured batching delay is 0.3–0.6 ms, while the period at 1000 Hz is only 1 ms. A perfectly normal interval can stretch to 1.6 ms from the browser's own delay alone, so any "clearly too long means packet loss" rule would have a good mouse reporting a packet-loss rate of a few percent. This page only gives counting-type conclusions.
