DeviceBenchFree online mouse rate checker
Polling rate test that counts every report your mouse sends
A mouse sends its position on a fixed interval, and this box counts those reports: keep the pointer moving inside it and the total settles onto the ladder it is nearest — 125, 500 or 1000 Hz on most mice, and up to 8,000 Hz on the newest ones. The number is a floor rather than a specification, because your browser delivers one pointer event per screen redraw and packs everything that arrived since the last one inside it; this page opens the bundle and shows both counts at once. Stop moving and the reading falls to zero, since a mouse that has not moved has nothing to report.
- 100% free
- No signup
- 125 – 8000 Hz
- Interval histogram
- Bundled reports unpacked
Keep the pointer moving inside this box — a mouse that is not moving sends nothing at all.
—
Sweep the pointer in circles in here for five seconds without stopping.
0 reports in the last second · 0 positions counted
Why counting events gives the wrong answer
- Events the browser delivered
- 0 · 0 in the last second
- Screen redraws per second
- —
- Positions inside each event
- —
No bundle has arrived yet. Either you have not moved fast enough to produce two reports in one frame, or this browser hands over every report on its own.
Where the intervals landed
- 125 Hz8.0 ms0
- 250 Hz4.0 ms0
- 500 Hz2.0 ms0
- 1000 Hz1.0 ms0
- 2000 Hz0.50 ms0
- 4000 Hz0.25 ms0
- 8000 Hz0.13 ms0
- pause> 11.3 ms0
One tall bar is a mouse holding its rate. Two bars means it is dropping to half rate under load, and the amber row is you slowing down, not the hardware.
0 intervals binned out of 0 positions. The figure above is a floor: a browser that misses its own deadline loses reports before this page can count them, so a 1,000 Hz mouse on a busy machine measures somewhere in the 800s and never the other way round. A phone has nothing to measure here — a finger produces reports only while it is touching the glass, at whatever rate the digitizer scans.
How to check a mouse polling rate
One continuous sweep, then two numbers: the peak, and the shape of the histogram behind it.
Sweep the pointer around inside the box for five seconds
A mouse that is standing still has nothing to report, so the rate falls to zero the moment you stop and that is not a fault. Circles work better than straight lines because they keep the sensor moving without running out of box, and five seconds is enough for a few thousand positions on any mouse above 125 Hz.
Quote the peak, not the figure showing at this instant
The live number is a one-second window, so it drops every time your hand slows at the end of a stroke, and the average across a whole session says more about your wrist than about the hardware. The peak is the closest thing to the rate the mouse was configured with, because it is the second in which nothing got in the way.
Check where the intervals actually landed
One tall bar on the ladder means the mouse held its rate for the whole run. Two bars means it spent part of the time at half rate, which is what a wireless mouse does when the link degrades and what some drivers do when a power-saving mode engages. The amber row at the bottom counts gaps longer than 11.3 ms, and those are almost always you pausing rather than the mouse dropping out.
Technical specifications
| What is counted | Uncoalesced pointer samples recovered with getCoalescedEvents(), not the pointermove events the browser delivered |
|---|---|
| Rate ladder | 125, 250, 500, 1000, 2000, 4000 and 8000 Hz, matched in log space so 707 Hz is the boundary between the 500 and 1000 bins |
| Reading reported | Peak samples per second over any one-second window, snapped to a ladder rate when it lands within 15% |
| Median interval | Taken over the last 2,048 intervals, so a pause part way through a run does not drag the middle |
| Pause bin | Every interval longer than 11.3 ms, which is a hand stopping rather than a rate |
| Direction of error | One way only — a late browser loses samples, so the figure understates a mouse and never flatters it |
| Screen refresh | Measured separately through requestAnimationFrame, so the delivered-event rate can be held up against it |
| Data kept | Intervals only, in a 2,048-slot buffer that overwrites itself; the positions they carried are counted and dropped |
Frequently asked questions
Why do other rate checkers tell me my mouse is 60 Hz?
Because they count the events the browser handed them instead of the reports inside those events. A browser fires at most one pointermove per screen redraw and stores every position that arrived since the last one in a list attached to it, so a page that counts events measures the monitor and gets the refresh rate back for every mouse on the market. Reading that list is what separates the number on this page from the one on theirs, and the panel beside the histogram shows both counts so you can watch the difference for yourself.
My 1000 Hz mouse reads 850. Is something wrong with it?
Almost certainly not: this measurement can only ever be a floor. Every stage between the sensor and this page — the USB stack, the operating system's input thread, the browser's main thread — can be late, and anything that is late loses samples that were never replaced. That makes the error one-directional, so a reading below the rate you configured is normal and a reading above it would be the suspicious one. Anything within 15% of a ladder rate is reported as that rate here for exactly this reason.
The number falls to zero the second I stop moving. Why?
A mouse only produces a browser event when the position it reports has changed. The sensor is still being polled on its interval and the reports are still going down the cable, but a report saying the mouse is exactly where it was does not become a pointermove, so there is nothing to count. This is also why the peak matters more than the average: any pause you take is a stretch of the run with no data in it at all.
Is a higher polling rate worth paying for?
The jump from 125 Hz to 1000 Hz is worth it and the jumps above that are mostly not. At 125 Hz a position can be up to 8 ms old before your computer hears about it, which is more than a whole frame at 120 Hz; at 1000 Hz that worst case is 1 ms and has stopped being the limiting factor in anything. Going to 4,000 or 8,000 Hz shaves fractions of a millisecond off a delay that is already the smallest part of the chain, and it costs CPU time every second the mouse is moving.
Why does 8,000 Hz make my game stutter?
Because every report costs the CPU something, and at 8,000 Hz there are eight thousand of them a second to pay for. The interrupt handling, the driver work and any per-report processing a game does all scale with the rate, so on a machine that was already close to its limit the frame-time graph starts spiking as soon as you move the mouse. If your frame times get worse when you swing the view and better when you hold still, drop the mouse to 1,000 Hz and compare — that single change is often the entire difference.
Does this work with a wireless or Bluetooth mouse?
Yes, and wireless is where the result is most likely to surprise you. A 2.4 GHz dongle normally holds the rate it advertises, but it shares its band with Wi-Fi and with USB 3 ports, and a degraded link shows up here as a second bar on the ladder rather than as an obvious dropout. Bluetooth is different by design: the connection interval is negotiated with the host and mice usually end up near 125 Hz, so a Bluetooth mouse measuring 125 is behaving exactly as intended.
Does my 60 Hz monitor limit what my mouse can do?
No — it limits only how often you see the result, not how often the mouse reports. Every position that arrived between two frames is still delivered with its own timestamp, which is why this page can measure 1,000 Hz on a 60 Hz screen and why the count of positions per delivered event climbs as the mouse gets faster. A game engine reads the same list a browser does, so a fast mouse keeps its advantage on a slow display, and the two numbers being different is the normal, correct state of affairs.
About polling rate and the reports a browser hides
Polling rate is how often a mouse is asked for its position, and it is set by the USB interrupt interval the device negotiates when it is plugged in: 8 ms between reports is 125 Hz, 2 ms is 500 Hz, 1 ms is 1000 Hz, and the 8,000 Hz mice that arrived with USB high-speed polling report every 125 microseconds. It is not the DPI, which is how far one count of surface movement travels; it is not the sensor’s internal frame rate, which runs in the thousands and never leaves the mouse; and it is not related to the frame rate of anything on screen. It is one number: how often the position leaving the mouse is allowed to be updated.
Everything difficult about measuring it from a browser comes from one optimisation. Delivering a thousand events a second to JavaScript would flood a page, so browsers deliver at most one pointermove per screen redraw and attach every position that arrived since the previous one to it, retrievable through getCoalescedEvents() with the original timestamps intact. A page that counts events therefore measures the display, and every mouse it tests comes back at 60, 120 or 144 — which is where the folklore about browsers being unable to measure a polling rate comes from. Open the bundle instead and the resolution is as fine as the timestamps, which is why the panel here prints the delivered count, the redraw rate and the number of positions inside each event together: the three of them are the argument.
What the figure is worth knowing for is the age of the position your computer is acting on. At 125 Hz a movement can be up to 8 ms old before anything downstream has heard about it, and 8 ms is a whole frame at 120 Hz — real, and worth fixing. At 1000 Hz the same worst case is 1 ms, at which point the report rate has stopped being the largest delay in the chain and the input lag test is the better place to look for the rest of it. Two neighboring questions are worth keeping separate from this one: whether the cursor moves a consistent distance for a consistent hand movement is acceleration, measured on the cursor test, and how far one count of movement carries is resolution, approximated on the mouse DPI test. A mouse can be perfect on all three and still have a switch that no longer closes, which is what the mouse test checks.
What the counter keeps
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
The only thing stored here is time: a rolling buffer of 2,048 intervals, in milliseconds, that overwrites its oldest entry once it is full. The coordinates those reports carried are used to bin an interval and then dropped in the same step, so nothing on this page could describe where your pointer went even while the test is running.