The 30-second version

A mouse’s polling rate is how often the computer asks it “anything new?” — measured in hertz, times per second. The mouse doesn’t push data whenever it likes over USB; the host polls the device on a fixed schedule, and the mouse answers with whatever it accumulated since last time.

• 125Hz — a report every 8ms (the USB HID default)
• 500Hz — every 2ms
• 1000Hz — every 1ms (the modern gaming standard)
• 4000Hz / 8000Hz — every 0.25ms / 0.125ms (flagship territory)

Since a report can land anywhere inside the interval, the average wait is half the interval: ~4ms at 125Hz, ~0.5ms at 1000Hz, ~0.0625ms at 8000Hz.

What the number actually changes

Two things, and only two things:

1. Cursor/report smoothness. More reports per second means finer-grained updates to whatever consumes them — the OS cursor, the game’s input loop. At 125Hz the cursor moves in 8ms steps; on a 60Hz display (16.7ms frames) that’s still several reports per frame, which is why casual use never noticed 125Hz for decades.
2. Report freshness. The newest movement can’t be older than one interval. At 1000Hz a click or flick reaches the host within ~1ms; at 125Hz it can sit for up to 8ms.

That’s the entire mechanism. Polling rate doesn’t change DPI, sensor accuracy, or lift-off — it only changes how often the data leaves the mouse.

What it doesn’t change (and what people confuse it with)

• It’s not DPI. CPI/DPI is how much motion each physical millimeter produces; polling is how often motion is reported. A 1600-DPI mouse at 125Hz is still precise, just chunkier in time.
• It doesn’t fix a bad sensor. A noisy sensor at 8000Hz delivers noise faster.
• It isn’t display refresh rate. Hz on your monitor and Hz on your mouse are different clocks — but they interact: a 60Hz display can only show 60 updates a second, which is also roughly the rate a browser can observe. That interaction is exactly what the tester’s honesty note is about.

Where the browser fits in — and where it stops

When you move a mouse, the chain is: sensor → MCU → USB report → OS HID stack → windowing system → browser event delivery → this page. The last hop is the only one a website can see, and it’s capped: browsers deliver pointermove aligned to the frame loop, coalescing everything that accumulated since the last frame into one event. Chrome/Edge keep the sub-frame timestamps reachable via getCoalescedEvents (~1kHz of recoverable detail); Firefox and Safari don’t.

So a page can honestly report a browser-observed event rate — useful for sanity-checking the event path and comparing browsers — and must admit the wire-level number needs hardware-level methods. If you’re choosing a setting rather than measuring one, the 1000Hz vs 8000Hz comparison has the honest math.

Frequently asked questions

Is 1000Hz polling rate good for gaming?

Yes — 1000Hz is the community-standard setting for competitive play: a 1ms report interval, so the host hears about movement within ~1ms worst case and ~0.5ms on average. It costs almost no CPU on modern machines and every current gaming mouse supports it. Anything higher returns fractions of a millisecond against real overhead — see the 1k vs 8k breakdown.

Does a higher polling rate reduce input lag?

A little, with a hard floor. Going 125→1000Hz cuts average report wait from ~4ms to ~0.5ms — real and measurable. Going 1000→8000Hz cuts ~0.44ms more — present but small next to the rest of the input lag chain, where display and compositor time dominate.

What polling rate should I set my mouse to?

1000Hz if it's available — it's the default sweet spot. Drop to 500Hz only if a specific game or old PC shows stutter under load. Wireless mice: 1000Hz on the 2.4GHz dongle is fine; Bluetooth may cap lower. 4000/8000Hz: only worthwhile paired with a high-refresh monitor and a PC with CPU headroom.

Can a browser measure my polling rate?

Only partially — that's the point of the honesty note under our tester. A page sees delivered pointer events, capped by the frame loop (~display refresh) and by coalescing. Chrome/Edge expose sub-frame samples up to roughly ~1kHz. True USB polling needs desktop or hardware tools — the methods are here.