๐Ÿ“กWhat rate is your mouse really reporting at?

โœ“ Tested & verified Updated: How the test works

Polling rate test

Move the pointer around inside this box, quickly and without stopping, until the countdown ends.

Reports per second

0Hz

This is how often the mouse told the browser it had moved. It can never read higher than your screen refreshes, so a 1000 Hz mouse on a 60 Hz panel often measures low.

  • Typical gapโ€”
  • Fastest gapโ€”
  • Reports countedโ€”
  • Screen refreshโ€”

One gear check a month

Monthly

One thing a month worth measuring before it fails properly โ€” a mic that reset itself, a stick that drifts, a switch sending two clicks. Two sentences and the test.

Free, no account. One click unsubscribes and deletes your address.

Try also

How is mouse polling rate measured in a browser?

The polling rate test takes the median gap between the movement reports your browser receives and converts it to hertz: a 1 ms median is 1000 Hz, 2 ms is 500 Hz, 8 ms is 125 Hz. Move the mouse in steady circles for the full three seconds, because slow or intermittent movement produces too few reports to measure anything.

Two layers sit between the sensor and that number. The browser normally hands a page one pointer event per animation frame, so on a 60 Hz screen a naive reading tops out near 60 no matter what the mouse is doing. This test reads the individual reports coalesced inside each frame, and where the browser exposes a raw update stream it uses that instead.

Treat the answer as a band rather than a decimal. Anything near 1 ms is a 1000 Hz mouse, whatever the third digit says.

Polling rate and refresh rate are the same kind of number pointed at different hardware, so the useful question is how many reports arrive between two frames. The table below works that out for the three screens most people are sitting in front of.

Polling rateGap between reportsReports per frame at 60 Hzat 144 Hzat 240 Hz
125 Hz8 ms2.10.90.5
250 Hz4 ms4.21.71.0
500 Hz2 ms8.33.52.1
1000 Hz1 ms16.76.94.2
2000 Hz0.5 ms33.313.98.3
8000 Hz0.125 ms133.355.633.3

Read the 144 Hz column at 125 Hz polling: fewer than one report per frame, which means some frames are drawn with no new mouse position at all. That single row is the argument for leaving 125 Hz behind, and it is a far stronger one than anything above 1000 Hz.

If the mouse reports fine but a button misbehaves, the mouse tester covers buttons and the wheel, and the double click test measures the switch fault that looks like a software bug. Keyboards have their own version of this question, answered by the keyboard tester.

Frequently asked questions

My 1000 Hz mouse reads about 500 Hz. Which number is wrong?

Usually neither. A 1000 Hz report rate needs a clean 1 millisecond interval on the USB bus, and a hub, a front-panel header or a busy controller adds enough jitter to halve it in practice. Check three things in order: plug into a rear port directly on the board, confirm the rate set in the mouse software, and on a wireless mouse plug the dongle in via its extension rather than a hub.

Why does the reading change when I move faster or slower?

Because a mouse only reports when there is something to report. Move slowly and the sensor sends fewer updates, so the gaps between them stretch and the measured rate falls. That is why the test asks for continuous circles: the figure describes the mouse at work, and only steady movement puts it there.

Can this test tell me my mouse DPI?

No, and neither can any other web page. Movement arrives already multiplied by pointer speed, acceleration and display scaling, so the same physical inch of desk gives different numbers on two machines with identical hardware. DPI lives in the sensor and is readable only by the vendor software or the mouse’s own on-board display.

Why is my result capped at exactly my monitor's refresh rate?

Because the browser is coalescing pointer events to one per animation frame and this browser does not expose the individual reports inside them. Chromium-based browsers provide a raw update stream and the coalesced-event list, so they measure the full rate; other engines cap at the frame rate. If the number matches your refresh rate to the hertz, that is the ceiling talking, not the mouse.

Does a higher polling rate actually feel different?

The arithmetic is small and honest. At 125 Hz a movement waits up to 8 milliseconds to be reported and 4 on average; at 1000 Hz that becomes 1 and 0.5. Going from 125 to 1000 saves about 3.5 milliseconds, which is noticeable against a 16.7 millisecond frame. Going from 1000 to 8000 saves another 0.4 milliseconds and costs measurable CPU time.

Is a wireless mouse slower to report?

It depends entirely on the radio. A dedicated 2.4 GHz dongle runs at 1000 Hz as routinely as a cable does, while Bluetooth is commonly capped near 125 Hz because the connection interval is negotiated in much coarser steps. Battery saving lowers the rate further after the mouse has been still, so measure immediately after moving, not after a pause.

How the test works

The test records the timestamp of every movement report the page receives during the measurement window and takes the median of the gaps between consecutive reports; the polling rate is 1000 divided by that median in milliseconds. The median is used rather than the mean because a single scheduling hiccup โ€” a garbage collection, a background tab waking up โ€” would drag a mean down while leaving the median untouched. Recovering the individual reports takes deliberate work, because a browser is allowed to coalesce pointer events into one per animation frame: the test reads the coalesced list attached to each event and, in browsers that provide it, subscribes to the raw pointer update stream instead. Where neither is available the measurement is capped by the display refresh rate, which is a real limit of the browser and not of the mouse, and the result says so. Event timestamps are also deliberately coarsened by browsers as a fingerprinting defence, so the reading is a band โ€” 125, 250, 500, 1000 โ€” rather than an exact figure. Sensor DPI is not exposed to web pages in any form and cannot be inferred from movement, since the operating system has already applied pointer speed, acceleration and display scaling. Nothing is uploaded or stored.

Worked example

With gaps between pointer events (ms) 1.0, 1.1, 0.9, 1.0, 1.2, 0.9, 1.0, 8.4, this page works out 1,000 Hz. The 8.4 ms gap is one dropped report. It is left in the sample and ignored by the median, which is why the median is used instead of the average.

  • Median gap1.0 ms
  • Slowest gap8.4 ms
  • Gaps counted8

Sources:

What polling rate is not

It is not DPI. Polling rate is how often the mouse speaks, DPI is how much it says per inch of movement. Raising one does nothing to the other, and the two are confused constantly because both are printed on the same box.

It is not your frame rate. A 1000 Hz mouse reports 17 times between two frames on a 60 Hz screen, and 16 of those reports change nothing you can see. The value is in the one that lands just before the frame is drawn, which is a smaller and more interesting benefit than the number implies.

It is not free above about 1000 Hz. Every report is an interrupt the operating system has to handle, and 8000 Hz mice measurably load a CPU. The gain past 1000 Hz is fractions of a millisecond.