Key takeaways
- How to check mouse polling rate with a desktop tool, why browser pages under-report, how to read interval graphs, plus a printable record template.
The most dependable way to check mouse polling rate is to capture raw mouse reports with a desktop utility and read the time between them: about 1 ms between reports means 1000Hz, about 2 ms means 500Hz, about 0.125 ms means 8000Hz. A browser page can give a rough hint, but it often reports a number lower than the real one, so use it for a first glance only.
This guide explains the difference between the number printed on the box and what your PC actually receives, why web tests undercount, how a desktop capture works, how to read the graph, and how to keep a simple record so you can compare before and after a change. Nobody on the team has run these steps on your hardware, so the numbers in the examples are arithmetic from the definition of Hertz, not results from a bench.
Advertised setting versus what the PC receives
Three different numbers get mixed up. The first is the maximum on the specification page. The second is the value selected in the maker’s software or on a switch. The third is the interval the operating system actually observes over USB or the wireless link. They can match, but nothing forces them to. A mouse set to 1000Hz can deliver less when it sits behind a flaky hub, drops into a power-saving state or runs in a mode with a lower cap.
Only the third number tells you what the game can use. If you are still choosing between settings, start with our explainer on the best polling rate for gaming, then come back here to confirm that the choice took hold.
| Number | Where you find it | What it proves |
|---|---|---|
| Maximum rate | Specification page | What the hardware can do in its best mode |
| Selected rate | Maker app or on-mouse switch | What you asked the mouse to do |
| Observed interval | Raw-input capture tool | What the PC receives right now |
Why browser tests tend to under-report
Web-based polling rate tests listen to pointer events. Browsers decide when to hand those events to a page, and many align delivery with screen refresh or merge several hardware samples into one event. A mouse reporting 1000 times a second may therefore show a count near the display refresh rate, or something in between, depending on the browser and settings. Some pages try to read the merged events to recover the extra detail, but results vary by browser version and operating system.
So a low number on a web page does not prove the mouse is misconfigured. It is a prompt to confirm with a tool that reads raw input. Equally, a web page showing a high number is a good sign but not a certificate.
Capturing reports with a desktop tool
A free Windows utility called MouseTester is a common choice. It listens for raw mouse input, timestamps each report, and plots the interval between them. Download it only from the project’s official page, and follow its current instructions because the layout may change between versions.
- Plug the mouse straight into a USB port on the PC. If you want to check a wireless mode, make sure the receiver is in a port close to the mouse.
- Close the maker’s software if it overlays the pointer, then open the tool.
- Start a capture, and move the mouse in smooth, steady circles for ten to twenty seconds.
- Stop the capture and read the average interval, the counts of reports and the interval graph.
- Convert: rate in Hz equals 1000 divided by the interval in milliseconds.
A hand that pauses will leave gaps in the data, so do not judge the rate from a capture that included stops.
Motion requirements and sensor idle behavior
Most mice send reports while the sensor sees motion and quiet down when it does not. That means polling rate readings only make sense during sustained movement. A slow crawl at low DPI can produce reports that carry tiny or zero counts, and some tools drop those from the plot, which makes the average look worse than the true interval. Moving faster, or raising DPI for the capture, gives each report something to carry.
Here is a worked example with stated assumptions. You capture for 10 seconds of continuous circular motion and your tool counts the reports. At 1000Hz, expect close to 10,000 reports. At 500Hz, expect close to 5,000. At 125Hz, close to 1,250. At 8000Hz, close to 80,000. If your capture shows half the expected count with the mouse set to 1000Hz, either the hand paused for about half the time or the link is delivering 500Hz.
Connection modes and interface bottlenecks
The interface can cap the rate before the sensor does. Common culprits:
- Bluetooth mode. Many wireless mice offer a Bluetooth mode that runs slower than their dongle mode. The maker’s manual lists the rates for each mode.
- Hubs and extensions. A shared hub, a long cable or a front-panel header can introduce jitter or a lower negotiated rate. Move to a rear motherboard port to check.
- Power saving. USB selective suspend and similar options can change behavior. Check the Windows power plan only if you are seeing odd gaps, and note what you changed so you can revert it.
- Software caps. A profile can be set below the maximum, and a different profile may load per game.
- Receiver position. A dongle behind a monitor or a tower can lose packets, which shows up as irregular intervals.
Faster rates on any interface also need the PC to keep up. If the CPU is hot or heavily loaded, jitter can appear. Our walkthrough on lowering CPU temperatures is relevant if your captures are fine at idle and rough under load.
Report interval is not click-to-photon latency
A fast report interval shortens one link in a long chain: switch, sensor, firmware, radio or cable, USB stack, game logic, render, display scan-out. Doubling the polling rate does not halve total delay. At 1000Hz a new position can wait up to about a millisecond before it is sent, while a display at 60Hz updates every 16.7 milliseconds. That is why gains show up mainly on high-refresh displays and with high frame rates.
Reading the interval graph
| What you see | Likely meaning | First thing to try |
|---|---|---|
| Flat line near 1 ms | Healthy 1000Hz delivery | Nothing, record it |
| Flat line near 2 ms | 500Hz selected or capped | Check software profile and connection mode |
| Flat line near 8 ms | 125Hz mode or basic mouse | Check the model’s specification page |
| Bands at 1 ms and 2 ms | Occasional missed slots | Move to a rear port, shorten the path |
| Spikes of many milliseconds | Pauses, power state changes, CPU stalls | Keep moving, then check load and power settings |
| Cluster near 0.125 ms | High-rate mode, if hardware supports it | Confirm tool timing resolution, then compare against 1000Hz |
Polling rate test record template
Copy this into a note so you can compare runs. Fill one column per test and keep the same motion each time.
| Field | Run 1 | Run 2 |
|---|---|---|
| Mouse model and firmware | ||
| Connection (cable, dongle, Bluetooth) | ||
| USB port used | ||
| Selected rate in software | ||
| DPI during capture | ||
| Capture length (seconds) | ||
| Reports counted | ||
| Average interval (ms) | ||
| Notes (pauses, background apps) |
Common mistakes when reading a capture
- Judging from a slow, short run. Two seconds of cautious movement gives you too few reports and too many gaps. Use ten seconds or more.
- Changing two things at once. Swapping the USB port and the rate in the same step leaves you unable to say which mattered.
- Trusting the screen refresh as the mouse rate. If a web page shows a number close to your monitor’s refresh rate, the page is probably counting display frames rather than hardware reports.
- Ignoring the connection mode. A dongle capture and a Bluetooth capture are separate runs, so label them as such in your record.
- Forgetting background software. Overlays, macro tools and capture programs can add load that shows up as irregular spacing.
Verification checklist
- The mouse is on a direct port, with no hub in the path.
- The software shows the rate you intended, and the profile is saved.
- The capture used continuous motion for at least ten seconds.
- The count matches the expected number within a reasonable margin, or the gap has an explanation.
- You repeated the run once, and the second result agrees with the first.
- You wrote down the numbers before changing anything else.
If you are comparing models, the rate still matters less than sensor and shape. For those other angles, see the MMO mouse picks and the DeathAdder V3 versus Superlight 2 comparison.
Frequently asked questions
What is the most reliable way to check mouse polling rate?
A desktop utility that reads raw mouse input and plots the time between reports, such as the free MouseTester, is more dependable than a web page. Move the mouse steadily for several seconds, then look at the average interval and the spread. One millisecond between reports corresponds to 1000Hz.
Why does an online polling rate test show a lower number than my mouse advertises?
Browsers deliver pointer events on their own schedule, often aligned with screen refresh, and may merge several hardware reports into one event. A page can therefore show a number well under the true rate. Use it as a rough hint only, and confirm with a desktop tool that reads raw input.
Why does my reading jump around or drop to zero?
A mouse generally sends reports while it moves, so a pause, a slow drift or a lifted sensor produces gaps. Keep moving in smooth circles at a steady pace. If readings stay low during continuous motion, suspect a USB hub, power saving, a wireless mode with a lower cap or a different rate selected in software.
Does polling rate equal input lag?
No. Polling rate is how often the mouse reports. Click-to-screen delay also includes switch debounce, wireless transmission, game engine processing, GPU render time and display response. A faster report interval can trim a small part of that chain but never describes the whole delay.
Can the rate differ from what the software shows?
Yes. The software shows what was requested, and the mouse or its connection may settle on something else. A hub, a cable problem, a low-power state or a mode switch can change the result. That gap is the reason to check the observed interval instead of trusting the setting alone.
