11 min
Why a Key Does Not Register
A key press passes through seven layers before a page sees it, and only three of them travel with the keyboard. Check them in order to find the real fault.
Why Mouse Polling Results Differ by Browser
Two browsers, one mouse, two different polling rates — and neither browser is lying. A web page never sees the mouse directly; it sees what the browser chooses to hand over, and browsers hand over different things.
10 min read · updated 13 September 2026 · links to 4 tools
In short
A mouse sends movement reports at a fixed rate, such as 125, 500 or 1,000 times a second, but a web page never receives them directly. Browsers usually merge mouse movement into about one event per display frame, so a page that only counts those events sees roughly your screen's refresh rate — about 60 on a 60 Hz display — however fast the mouse is. The merged samples can be recovered with getCoalescedEvents(), and some browsers also offer pointerrawupdate, which delivers movement as it arrives; not every browser supports either. On top of that, browsers round their clocks, which can break a test that works from the gap between samples while leaving a test that counts samples over time correct. Movement speed, wireless power saving and a busy computer all thin the stream further. So a browser result is an estimate of what that browser exposes, not a reading of the hardware.
On this page
- The same mouse, three different numbers
- What a mouse actually sends
- Browsers merge movement into display frames
- Getting the merged samples back
- Browsers round their clocks, and that breaks one kind of test
- Other things that thin the stream
- How to get a reading you can trust
- What a browser can and cannot tell you
The same mouse, three different numbers
Take a 1,000 Hz mouse on a 60 Hz display and move it for fifty milliseconds. The mouse sends fifty reports. A page that only listens to ordinary pointer events receives three. A page that asks for the samples merged into those three events gets all fifty back.
Every polling rate tester is choosing one of those rows, whether it says so or not. That single choice explains most of the disagreement between testers and between browsers.
What a mouse actually sends
A USB mouse is asked for news at a fixed interval, and the polling rate is how often. A basic office mouse commonly reports 125 times a second, once every 8 milliseconds. Gaming mice usually offer 500 and 1,000, and some recent models go to 4,000 or 8,000.
There is an important catch before any browser gets involved: a mouse only sends a report when it has something to say. Held still, it says nothing. Moved slowly, it can have no movement to report on some intervals and skip them. That is why every polling test asks for fast, continuous movement, and why a gentle wiggle reads low on any tester, in or out of a browser.
Browsers merge movement into display frames
A page has no use for a thousand position updates a second if it can only draw sixty frames. So browsers commonly collect the movement that arrives between frames and dispatch it as a single pointer event, carrying the latest position. This saves a great deal of work, and for nearly every page it is invisible.
For a polling test it is decisive. A tester that times ordinary pointer events is measuring how often the browser dispatches them, which tracks the display refresh rate. On a 60 Hz screen that tends to read near 60; on a 144 Hz screen, nearer 144. The mouse is not involved in that number at all.
If a tester gives almost exactly your monitor's refresh rate whatever mouse you plug in, it is counting dispatched events.
Getting the merged samples back
Browsers that merge movement usually keep the individual samples too. A page can ask each pointer event for them with getCoalescedEvents(), and receives the list of movements that were folded into it, each with its own timestamp. Counting those gets much closer to what the mouse sent.
Some browsers go further with an event called pointerrawupdate, which fires as movement arrives rather than once per frame, and is only available on secure pages. Support for both varies between browsers and versions, so a careful tester detects what is available and says which method produced its number. The polling rate test shows all three side by side, marking any the browser does not support.
Browsers round their clocks, and that breaks one kind of test
Precise timers can be abused to fingerprint visitors and to measure things a page should not see, so browsers deliberately limit how finely a page can read the time. Depending on the browser and its security settings, timestamps may move in steps of a tenth of a millisecond or more.
That matters more than it sounds, because there are two ways to turn timestamps into a rate. One takes the typical gap between samples and inverts it. The other counts how many samples arrive over a stretch of continuous movement. When the clock is rounded, the first can be badly wrong while the second stays right. The figures below come from running both methods over simulated mice with rounded clocks.
| Mouse | Clock step | Typical-gap method reads | Counting method reads |
|---|---|---|---|
| 1,000 Hz | 1 ms | 1,000 Hz | 1,000 Hz |
| 2,000 Hz | 1 ms | 1,000 Hz | 2,001 Hz |
| 4,000 Hz | 1 ms | 1,000 Hz | 3,999 Hz |
| 4,000 Hz | 0.1 ms | 3,333 Hz | 4,000 Hz |
| 8,000 Hz | 0.1 ms | 10,000 Hz | 8,000 Hz |
The last row is the unsettling one: rounding does not only make a fast mouse read low. With a fine but not fine enough clock, the typical-gap method can report more than the mouse can send. The polling rate test on this site counts samples, and measures and shows your browser's clock step beside the result.
Other things that thin the stream
- Slow or stop-start movement. Fewer intervals have movement to report.
- Wireless power saving. Many wireless mice lower their rate on battery or when they sense slow movement, and some only reach their top rate with a dedicated receiver rather than Bluetooth.
- A busy computer. When the processor is loaded, events can be delivered in bursts and some intervals are lost to the page.
- A background tab. Browsers throttle pages that are not visible, so a test must be run in the front tab.
- The mouse's own setting. Many mice keep the polling rate in their own memory or in their software; a mouse set to 500 Hz reads 500 on any computer.
How to get a reading you can trust
- Use a test that tells you which method produced its number. Coalesced samples or raw updates are the ones worth reading.
- Move fast, in continuous circles, for several seconds. Do not stop and start.
- Close other heavy programs and keep the test tab in front.
- Plug a wireless mouse into its own receiver, or use a cable, when checking its top rate.
- Compare the result with the nearest standard rate — 125, 250, 500, 1,000 — rather than expecting an exact figure.
- For a claim above 1,000 Hz, use the manufacturer's own utility. A browser is the wrong instrument for proving 8,000 Hz.
What a browser can and cannot tell you
A browser test is excellent at one job: telling whether a mouse is running at a basic rate or a gaming rate, and showing whether a setting change actually took effect. It is poor at verifying very high rates, and it cannot see anything the operating system or the browser keeps from the page.
The same honesty applies to the other mouse checks. A double-click test can show a switch registering twice, and a pointer latency test can show the cursor trailing your hand, but both measure what the browser delivers, not the hardware directly.
Frequently asked questions
Why does my 1000 Hz mouse show 60 Hz in some tests?
Because that test counts ordinary pointer events, which browsers usually merge into one per display frame. On a 60 Hz monitor that reads close to 60 whatever the mouse does. A test that recovers the merged samples reads much closer to the real rate.
Why do Chrome and Firefox give different polling rates?
They can expose different things — one may offer raw updates or merged samples that the other does not — and they round their clocks differently. A test that reads the typical gap between samples is especially sensitive to clock rounding.
What is getCoalescedEvents?
A browser feature that returns the individual pointer movements merged into a single pointer event, each with its own timestamp. Counting those gives a far better estimate of a mouse's polling rate than counting the events themselves.
Can a browser test verify an 8000 Hz mouse?
Not reliably. Clock rounding and event handling limit what a page can resolve at that speed. Use the manufacturer's own software for rates above 1,000 Hz.
Why does my polling rate drop when I move slowly?
A mouse only sends a report when it has moved. Slow movement leaves some intervals with nothing to report, so the observed rate falls. Move fast and continuously when testing.
More guides
10 min
How to Check a New Monitor Before the Return Window Closes
Dead pixels, backlight bleed and IPS glow are three different things with three different verdicts. Here is what to check, and what counts as a defect.