Polling rate is the one number on a mouse box that people argue about without agreeing what it measures. It is not DPI and it is not the refresh rate of your screen, though it gets confused with both. It is how many times per second the mouse tells the computer where it is.
This is what the number means, what the standard settings translate to in milliseconds, why an 8000 Hz mouse can read as 144 Hz in a browser, and what a higher rate does and does not change — with the caveat the makers of 8000 Hz mice print themselves. Sources were read on 15 September 2026; where a claim is somebody else's, we say whose.
What Polling Rate Is
Razer, which sells the fastest-polling mice on the market, defines it in one sentence: “Polling rate is the frequency at which data is communicated from your device to your PC.” A mouse at 1000 Hz sends a report a thousand times a second; each report carries how far the sensor moved since the last one and the state of the buttons. The computer does not ask in between. Whatever you do with the mouse in the gap between two reports arrives with the next one.
That makes the interval between reports the real unit. Divide 1000 milliseconds by the rate and you have it:
- 125 Hz — a report every 8 ms. The bottom of the ladder, and the rate many non-gaming mice report at.
- 250 Hz — every 4 ms.
- 500 Hz — every 2 ms. Common on older gaming mice and on wireless mice saving power.
- 1000 Hz — every 1 ms. The setting most gaming mice ship at.
- 2000 Hz and 4000 Hz — every 0.5 ms and 0.25 ms. Intermediate steps that 8000 Hz mice typically also offer.
- 8000 Hz — every 0.125 ms. The current ceiling on consumer mice.
Two things follow from the arithmetic. The step from 125 Hz to 1000 Hz cuts the wait between reports by 7 ms; the step from 1000 Hz to 8000 Hz cuts it by 0.875 ms. And the rate is a ceiling, not a promise: a mouse that is not moving sends nothing.
Polling Rate Is Not Refresh Rate
A 144 Hz monitor draws 144 frames a second. A 1000 Hz mouse reports a thousand times a second. The two numbers share a unit and nothing else: between two frames on a 144 Hz screen, a 1000 Hz mouse has reported about seven times, and the game has read all seven and drawn the result once.
The confusion is understandable, because browsers fold the two together. A web page listening for mouse movement does not receive every report. MDN's documentation for the pointer event API explains why:
“Instead of a stream of many pointermove events, user agents coalesce multiple updates into a single event. This helps with performance as the user agent has less event handling to perform, but there is a reduction in the granularity and accuracy when tracking, especially with fast and large movements.”
In practice the browser hands the page one movement event per screen frame and folds the reports in between into it. Time the gaps between those events and you get the refresh rate of the monitor — 144, 165, 240 — not the rate of the mouse. A checker that does not unfold the events is measuring the screen and calling it the mouse.
The API to unfold them is getCoalescedEvents(), which returns the reports the browser merged into each event. MDN's compatibility data lists it in Chrome from version 58, Firefox from 59 and Safari from 18.2; we have used it on desktop Chrome, Edge and Firefox and have not tested Safari ourselves. Without it, the highest rate any web page can see is your refresh rate.
Does a Higher Polling Rate Make You Aim Better?
We have not measured that, and we are not going to claim it. What we can say is what a higher rate changes and what it costs, using the numbers of the company that sells it.
Razer's own page puts the gain from 1000 Hz to 8000 Hz as “a huge input delay reduction from 1 to 0.125 ms” — the maximum wait between a movement and the report that carries it, shrinking by under a millisecond. Eight times as many reports means eight times as many for the computer to process, and the same page carries the line most marketing leaves out:
“In some instances, your PC may not be powerful enough to support Razer HyperPolling. For CPU-bound cases, the computer might lack the resources needed to process 8,000 reports a second.”
The same page asks for the mouse to be on a native USB port, not a hub, and for the wireless dongle to be within 30 cm and in line of sight. Those are the conditions under which 8000 Hz holds; outside them the mouse drops back.
So the honest summary is this. Going from 125 Hz to 1000 Hz removes 7 ms of wait, on the order of a frame at 144 Hz. Going from 1000 Hz to 8000 Hz removes under 1 ms and costs CPU time in a game that is often already CPU-bound. Whether that last millisecond is felt depends on the game, the screen and the hand — and anybody who gives you a number for how much it improves your aim has measured something we have not seen.
Why a 1000 Hz Mouse Reads 500 Hz
The setting in the mouse software is what the mouse is asked to do. What it actually holds is another matter, and a measurement below the setting usually has one of a few causes:
- Power saving. Wireless mice commonly lower the rate on battery, at range, or after a period of idling, and some do so without saying. The cable is the quickest way to rule this out.
- The path to the PC. A hub, a monitor's USB port or an extension cable sits between the mouse and the controller that reads it. Razer's instruction to use a native port is there for a reason.
- The mouse standing still. No motion, no reports. A checker that counts the pauses as slow polls will report a rate that is too low; one that drops them will not.
- The browser folding reports — the case above. If the result equals your refresh rate to the digit, it is the screen.
Where the Setting Lives
On most gaming mice the rate is set in the maker's software, usually as a drop-down of the same standard values listed above. Some mice carry a button on the underside that cycles through them, and some wireless mice need a specific dongle for anything above 1000 Hz. The mouse keeps the setting across computers, which is why a second-hand mouse can arrive at 125 Hz with nobody knowing.
There is no setting for it in CS2. The game reads whatever the operating system hands it, at whatever rate the mouse reports. Polling rate is one of three numbers behind how the mouse feels in the game; the other two, DPI and in-game sensitivity, combine into eDPI, which is a separate calculation.
Measure Your Own, and Read Three Numbers
Our Mouse Polling Rate Test runs for five seconds in the browser: click the pad, keep the mouse moving in circles at a normal speed, and it timestamps every report it receives. Gaps longer than 100 ms are treated as your hand stopping and dropped, not counted as slow polls, and the run needs at least 200 usable intervals before it will say anything — a mouse that sat still for most of the five seconds is reported as too short a run, not as a low rate.
The result is three numbers rather than one, because one number hides the tail:
- Median — the rate the mouse held for most of the run, snapped to the nearest standard setting so you can compare it with the drop-down in your software.
- Fastest 5 % — the ceiling. When it sits far above the median, the browser let bursts through that the mouse did not sustain.
- Jitter — how far the gaps wander from the median, in milliseconds. A 1000 Hz mouse reports every 1 ms; a few tenths of a millisecond of wander is normal, and a clean cable or a good dongle sits under 0.3 ms.
Before you start, the page reads whether your browser exposes the folded reports. If it does, rates up to 8000 Hz can be measured. If it does not, the test still runs and the result is marked in amber with the sentence that matters: this is your screen, not your mouse. Nothing is sent anywhere; the timestamps stay in the tab and are gone when you close it.
