Mouse Polling Rate Test
This test counts pointer movement samples the browser delivers and reports a live polling rate with a stability graph. It runs entirely in your browser tab — no installation required, no data sent anywhere, no account needed to use it.
Run polling rate test
Move your mouse inside the pad. The browser measures pointer delivery frequency in real time.
Move mouse rapidly in circles here
Mice send position updates when moving. Continuous sweeping motions generate the steadiest readings.
What this measures
- Pointer movement samples the browser delivers (coalesced events via getCoalescedEvents and, where available, pointerrawupdate).
- Live rate from a rolling 1-second window, updated continuously as you move.
- Session summary: median, mean, minimum, and maximum of the 1-second windows.
- Stability over the session shown as a line graph with drops and spikes shaded.
- Variation percentage (coefficient of variation across windows).
- Nearest standard class label (125, 250, 500, 1000, 2000, 4000, 8000 Hz) only when the median stays within ±10% of that class for at least 3 seconds.
What this cannot measure
- The hardware or firmware polling rate directly.
- USB traffic or controller-level timing.
- Any rate above the browser ceiling for your browser and display.
- What vendor software on the operating system reports.
- Wireless link quality, battery state, or receiver distance.
How to get a steady reading
- Plug in the mouse or ensure it is fully charged.
- Close heavy background applications that may compete for CPU.
- Move the mouse in smooth, continuous circles for the full 30 seconds.
- Keep the cursor inside the test area the entire time.
- Use the same display refresh rate when comparing different mice.
- Compare mice on the same browser for consistent results.
How to read the results
| Metric | What it means |
|---|---|
| Median | The middle 1-second window value — the number to quote when comparing mice. |
| Mean | Average of all 1-second windows. |
| Min / Max window | The lowest and highest 1-second window rates observed (the spread). |
| Variation % | Coefficient of variation across windows. Lower is steadier; above ~10% suggests interference or a low battery. |
| Class label | Shown only when the median holds within ±10% of a standard class for at least 3 seconds. |
| Duration | Total test time in seconds. |
| Browser | Browser name — part of the honest context for the reading. |
How the live reading works
The test reads pointermove events and calls getCoalescedEvents() on each one. This returns every intermediate sample the browser recorded since the last frame, each with its own timestamp. On Chromium-based browsers, the test also listens for pointerrawupdate, which delivers samples that are not aligned to display frames. All timestamps are deduplicated, the first 300 milliseconds are discarded as warm-up, and unique samples are counted in consecutive 1-second windows aligned to the session start.
The live number you see is the unique sample count inside the trailing 1-second window. The session statistics (median, mean, min, max, variation) are computed from the completed windows only.
Reading the stability graph
The graph plots each 1-second window rate across the session. Windows that fall below 80% of the session median are shaded as drops. Windows that exceed 120% of the median are shaded as spikes. A flat line near the median means the browser delivered samples at a steady pace. Frequent drops often point to wireless interference, a low battery, or CPU contention. Spikes can appear when the browser catches up after a brief pause.
Below the graph, the variation percentage summarizes the same information in a single number. Lower variation means the browser observed a more consistent delivery rate.
Why your number may read below the spec
Browsers align pointer event delivery to display frames by default. A 1000 Hz mouse on a 144 Hz display produces batched samples unless the page reads coalesced events. Even with coalesced events, the browser receives input after the operating system processes it, so the observed rate can be lower than the hardware rate — especially above 1000 Hz. The browser guide explains this in detail and lists per-browser ceilings measured during validation.
What the browser-limited banner means
If the observed rate reaches the measured ceiling for your browser, a banner appears: "Browser-limited: the real rate may be higher than shown." This means the browser cannot deliver samples any faster. The mouse may be running at its advertised rate, but the browser cannot confirm it. The banner is not an error — it is an honest limit notice.
Comparing two mice fairly
Use the same browser, the same display refresh rate, and the same test duration (30 seconds). Move both mice in the same smooth circular pattern. Close the same background apps. Compare the median and variation numbers, not just the live peak. Copy the plain-text summary for each mouse and paste them side by side.
Copying results
The "Copy result as text" button writes a plain-text summary to your clipboard. The text includes the browser-observed label, median, mean, min, max, variation, class label (if any), duration, and browser name. No raw timestamps, coordinates, or individual window values are included.
What the class label means
The class label (125, 250, 500, 1000, 2000, 4000, 8000 Hz) appears only when the session median stays within ±10% of that class for at least 3 continuous seconds. If the rate wobbles or the test is too short, no label is shown — only the observed number. This prevents a momentary spike from being mistaken for a stable class.
Warm-up and deduplication
The first 300 milliseconds of each test are ignored to let the browser settle after the start click. Identical consecutive timestamps are dropped before bucketing into windows. This prevents double-counting when the browser fires duplicate events.
Frequently asked questions
Why does my 1000 Hz mouse read lower than 1000?
Browsers deliver pointer events on display frames by default. Even with coalesced events, the browser receives input after the OS processes it, so the observed rate is often below the hardware spec — especially above 1000 Hz. The browser guide has per-browser ceilings and explains why this is normal.
Why is my polling rate unstable?
Drops in the graph usually mean the browser delivered fewer samples in that second. Common causes: wireless interference, low battery, receiver too far or blocked, heavy background CPU load, or power-saving features on the mouse. Try a wired connection, a fresh battery, or moving the receiver closer.
Is wired or wireless steadier?
A wired mouse removes the wireless link as a variable, so it typically shows lower variation. A modern 2.4 GHz wireless mouse with a good battery and clear line of sight can be nearly as steady. Bluetooth mice often show higher variation because of the protocol's lower report rate and duty cycling.
Is the reading the same as what vendor software shows?
No. Vendor software reads the hardware or USB controller directly. The browser observes what the OS delivers to the page. The two numbers measure different things. Treat the browser number as "the browser observed about X Hz" — not a hardware measurement.
What does "browser-limited" mean?
It means the observed rate hit the measured ceiling for your browser and display combination. The browser cannot deliver samples faster than that ceiling. The mouse may be running faster, but the browser cannot confirm it. The banner appears automatically when the ceiling is reached.
Related tests
Mouse Click Test
Test 5 buttons and inspect rapid activations for switch bounce timing.
What Is Polling Rate
Plain-language explanation of polling rate, DPI, and why higher is not always better.
Browser Guide for Polling Tests
Per-browser ceilings, why readings differ from vendor software, and how to get steady results.
How We Measure
The measurement method, validation setup, and the math behind the live rate and stability graph.
Last reviewed 2026-10-12