Short answer: a web page cannot measure your mouse’s polling rate. A browser “polling rate test” does not read how often your mouse reports to the computer — the 125 Hz, 500 Hz or 1000 Hz figure on the box. It counts how many pointer events the browser handed the page in a second, a number set by the browser and your display, not by the mouse. To show exactly why, we captured every field a browser gives a page during a mouse move.
Every field the browser gives the page — and none is a rate
We drove a mouse move in Chrome and, over the DevTools Protocol, logged the complete set of properties on each pointermove event. This is everything a page has to work with:
| Fields the browser provides | What they are |
|---|---|
pointerId, pointerType, isPrimary | Which pointer this is (an id, and “mouse” / “pen” / “touch”) |
clientX/Y, screenX/Y, pageX/Y, offsetX/Y | Where the pointer is now, in CSS pixels |
movementX/Y | Change in position since the last event, in CSS pixels |
pressure, tiltX/Y, twist, width, height | Pen/touch geometry (0 or defaults for a mouse) |
button, buttons | Which buttons are pressed |
timeStamp | When this event reached the page, in milliseconds |
That is the whole list. There is no field for polling rate, no report interval, and no device Hz. The browser never tells a page how often your mouse sent a report to the operating system — only where the pointer is now and when this particular event arrived. The one time value it does give, timeStamp, is a page-relative clock in milliseconds, and browsers deliberately coarsen its precision to blunt timing and fingerprinting attacks — so you cannot recover clean sub-millisecond gaps between hardware reports from it either.
So what does a “polling rate tester” actually count?
It counts events per second: how many pointermove events the browser delivered while you moved. That rate is capped above your mouse, not by it:
- The browser batches movement to its render frames. Chromium and other engines dispatch
pointermovealigned to the rendering pipeline — roughly your display’s refresh rate. So the page tends to see event counts near your monitor’s refresh (about 60 per second on a 60 Hz screen, more on a 144 Hz one) whether your mouse polls at 125 Hz or 1000 Hz. The number tracks your display, not your mouse. getCoalescedEvents()narrows the gap, it doesn’t close it. Modern browsers expose this method precisely because they batch events between frames: it hands back the finer samples the browser collected, so a careful page can count more than one per frame. But that is still browser-mediated, buffer-limited batching — not a guaranteed one-to-one with your mouse’s USB reports. It gets you closer to the real rate; it does not turn the page into a USB analyzer.
Put together: a browser “polling rate” number floats with your display and browser, and changing your mouse’s actual polling rate may not move it at all. It is a real measurement of how fast the browser fed the page — just not of your hardware.
How to actually check your polling rate
Your true polling rate lives in the USB/HID link between the mouse and the operating system, below where any web page can see. Read it from the mouse’s own configuration software, the manufacturer’s specification, or an OS-level HID/polling utility that talks to the device directly. A browser sits too far downstream to observe it.
What a browser can honestly show you is its own event stream: which mouse buttons and movements reach the page, the scroll direction and wheel units it reports, or your click speed. For what a browser can and cannot observe in general, see how we test.
The same limit as a “DPI checker”
This is the DPI-analyzer problem again in a different costume. A browser reports events, not sensor hardware — the same reason a “DPI analyzer” page can’t read your mouse’s DPI. And it is the same reason that, when we ran the same input through three browsers, they agreed on units and codes but none of them exposed anything about the device underneath. Browsers are honest about what reaches the page; they were never a window onto the hardware.
Method: the pointer-event field list was captured from real pointermove events in Chrome (HeadlessChrome 153), driven by an automation tool over the Chrome DevTools Protocol on 2026-09-16. The set of fields a page receives is the same in normal browsing; positions and timestamps on your machine will differ. These are browser-observed events, not device readings, and do not certify any hardware polling rate.