Mouse Polling Rate in the Browser: What This Test Measures (and What It Doesn’t)
Web-based mouse polling tests measure browser-delivered pointer event frequency, not raw USB polling. Learn why ~125Hz appears, why high polling rates are indistinguishable on the web, and how to interpret results.
Mouse Polling Rate in the Browser: What This Test Measures (and What It Doesn’t)
If you found our mouse polling rate tool via Reddit, welcome. This post explains what a browser can measure, why you may see ~125Hz, and how to interpret the results responsibly.
TL;DR
- This test measures browser-delivered pointer event frequency, not raw USB/HID polling.
- On many systems, events are coalesced or frame-paced, which can cap results (often ~125Hz).
- For 1000Hz+, the web is not a precise measurement tool.
- The test is still useful to detect low caps, stability, and jitter.
Community discussion
This post responds to the community thread on r/pcmasterrace:
https://www.reddit.com/r/pcmasterrace/comments/1pv2gyu/i_got_tired_of_installing_500mb_of_driver/
What This Test Actually Measures
Browsers do not expose raw USB/HID polling data. The web can only observe pointer events delivered by the browser. Those events are influenced by:
- the OS input pipeline
- the browser event loop
- the compositor (and sometimes the monitor refresh rate)
- power/energy saving policies
So the test reflects input dispatch frequency in the browser, not true hardware polling.
Why You Might See ~125Hz (Especially on Linux/Flatpak)
Common reasons include:
- Wayland/compositor throttling or event coalescing
- Flatpak sandboxed browsers with limited input event frequency
- Power-saving modes that reduce input sampling
- Bluetooth modes that default to lower polling
This is why users on Fedora + Flatpak often report a steady ~125Hz even with 1000–8000Hz mice.
Why High Polling Rates Are Indistinguishable on the Web
At 1000Hz, events arrive every ~1ms. At 8000Hz, that is ~0.125ms. The browser and compositor do not reliably deliver events at that granularity, and they may combine multiple events into one callback.
As a result, 1000/2000/4000/8000Hz cannot be precisely measured in a browser. Any number above ~1000Hz is mostly a byproduct of scheduling and coalescing.
How to Interpret Results Correctly
This tool is still helpful if you use it for what the web can measure:
- Spotting low caps (e.g., stuck around 125Hz)
- Comparing stability between setups
- Monitoring jitter and distribution spread
Useful metrics
- Median: a reliable baseline for browser-delivered events
- Peak: can jump with short bursts, not a reliable hardware number
- Stability: helps compare consistency between environments
Troubleshooting Checklist
If you always see ~125Hz:
- Use wired or receiver mode (avoid Bluetooth).
- Try a non-Flatpak browser build.
- Switch to X11 (Wayland can be more aggressive).
- Close heavy background apps.
- Test with a higher refresh rate monitor if possible.
When You Should Use Native Tools
If you need true USB polling rate, you should use a native tool or vendor software. The browser simply cannot access low-level HID data.
FAQ
Is this the real USB polling rate?
No. It is the browser-delivered pointer event frequency.
Why does changing my monitor refresh rate change the result?
Because some systems synchronize input delivery to the compositor/refresh cycle.
Why do different browsers show different peaks?
Each browser has its own event scheduling and coalescing behavior.
Is the test still useful?
Yes — it can still detect low caps and compare stability across setups.
Run the Test
Ready to try it?
Open the Mouse Polling Rate Test.
Ready to Test Your Mouse Polling Rate?
Use our mouse polling rate test to measure browser event Hz with distribution, median, peak, and stability checks (helpful to spot ~125Hz limits).
Start Polling Rate Test