Mouse Polling Rate Test
Find out how many times a second your mouse actually reports its position — and, just as importantly, how much of that number your browser is able to measure. Everything runs locally; nothing is uploaded.
What this measures, and what it cannot
Polling rate is how often your mouse tells the computer where it is. A 1000 Hz mouse reports every millisecond, a 125 Hz one every eight. This page times the gaps between the reports that reach the browser and takes the median — not the average, because one gap where your hand changed direction would drag a genuine 1000 Hz reading down to something plausible and wrong.
Two things stand between the mouse and the number above, and both are worth stating plainly rather than hiding behind a confident figure.
Event coalescing. Browsers hand pointer events to a page in step with the screen, so a naive test on a 60 Hz monitor measures every mouse in the world at about 60 Hz. This page listens on pointerrawupdate where it exists and calls getCoalescedEvents() on every event, which returns the individual reports the browser bundled together, each carrying its own original timestamp. That is what lets a 1000 Hz mouse read as 1000 Hz behind a 60 Hz frame loop. The Event source field tells you which path your browser took.
Timer resolution. This is the real limit, and it is not the same in every browser. Browsers deliberately blunt their clocks so that pages cannot use precise timing to fingerprint or attack you. Chrome and Edge round timestamps to 100 microseconds; Firefox rounds to a full millisecond unless the page is cross-origin isolated, which requires HTTP headers a static site like this one cannot send. A rate is only honestly claimable when its reporting interval spans at least two clock ticks, so a 1 ms clock tops out around 500 Hz — a 500 Hz mouse and a 1000 Hz mouse are then literally the same measurement. When that happens this page prints a capped result with a "≥" in front of it instead of inventing precision it does not have.
How to get a reading you can trust
Swirl continuously in wide circles inside the box — the test needs a couple of hundred timed reports, and a mouse that is standing still reports nothing at all. Keep the window focused and in front. Close anything heavy in the background: the measurement passes through the operating system's event queue and your browser's event loop, so a machine under load reports low, and a laptop throttling on battery reports lower still. Wireless mice are honest here but sensitive to their link, so a mouse on a shared dongle or a long, obstructed path to its receiver will show more jitter and the occasional dropped report.
Expect a real 1000 Hz mouse to measure somewhere in the high hundreds rather than exactly 1000. That is normal — it is the queueing, not the hardware. What matters is which rate it lands nearest, which is what the Matches field reports, and the tolerance there is deliberately loose for exactly this reason.
Reading the histogram
The bars are the gaps between reports, bucketed in quarter-millisecond steps from 0 to 12 ms. A mouse locked to one rate is a single spike: 1 ms for 1000 Hz, 2 ms for 500 Hz, 4 ms for 250 Hz, 8 ms for 125 Hz. Two spikes — one at your rate and one at double it — is the signature of a receiver dropping every so many reports, or of a browser handing over events in batches. A wide smear rather than a spike means the machine, not the mouse, is deciding when your input gets looked at.
My mouse says 1000 Hz but this says 125
125 Hz is the USB default, and a mouse that advertises more will sit at 125 until something sets it higher. Check the mouse's own configuration software, and check that the setting survived a reboot or a change of USB port — plenty of them do not. A gaming mouse plugged into a hub, or a wireless one sharing a receiver with a keyboard, is also worth testing directly in a port on the machine before you blame the mouse.
Mouse DPI test — measure your CPI with a bank card
The other number on the box. DPI — counts per inch, CPI, the two words mean the same thing — is how many steps the sensor reports for every inch the mouse travels across the desk. A browser cannot read it from the mouse. Nothing in any web API exposes a sensor setting, and no page has ever been able to ask one.
What a browser can do is count. Lock the pointer, sum the movement the operating system reports over a swipe, and divide by how far that swipe actually went — a distance you have to measure yourself, on the desk, with something of a known size. That is an inference, and it inherits every distortion sitting between the sensor and this page. The panel below reports the assumptions and the uncertainty alongside the figure, because without them the figure is not worth reading.
- Lay a bank card flat on the mousepad. Every payment card is 85.60 mm long, by ISO/IEC 7810 — that is the ruler.
- Tell the panel how far you are going to swipe. Two card lengths end to end is a good swipe; further is a better measurement.
- Set the browser zoom to 100% — Ctrl+0, or Cmd+0 on a Mac. Chrome was measured not to care, but not every browser was.
- Click the pad below to lock the pointer, swipe once from one end of that distance to the other, and click to finish.
What this figure is, and what it is not
It is effective CPI: counts per inch as your operating system hands them to the browser, at the speed you happened to swipe. It equals the sensor's hardware DPI only when nothing between them is scaling the number, and on a default Windows or macOS install something is.
Pointer acceleration is the big one. Windows ships with “Enhance pointer precision” on, which moves the pointer further per count the faster you move — so a fast swipe measures high and a slow one measures low, and neither is the sensor's DPI. macOS accelerates by default too and offers no checkbox at all. The note above tells you how to turn it off on your system; until you do, the panel is measuring your pointer curve, not your mouse.
Pointer speed is the quiet one. The speed slider in your mouse settings multiplies counts before the browser ever sees them. On Windows the middle notch, the sixth of eleven, is 1:1; anything else scales this reading by a fixed factor. Games and creative apps add their own in-app sensitivity on top, which is why an in-game figure and this one can both be right and still disagree.
Browser zoom and display scaling do not move the units — which we checked rather than assumed. The obvious worry is that a swipe measured at 200% zoom would report half the counts, and that devicePixelRatio is therefore the divisor. It is not, and neither is anything else. We posted a fixed raw pointer delta straight into the operating system's event stream with the page pointer-locked, and repeated it at display scale factors of 1, 2 and 3 and at browser zoom levels of 100%, 125% and 200%. In all six cases the page saw exactly the same movement total, while devicePixelRatio ranged over 1, 2, 2.5, 3 and 4. Under Pointer Lock, Chrome hands the page the operating system's pointer delta untouched.
So this panel divides by nothing, and dividing by devicePixelRatio would actively break it — on a Retina Mac at 100% zoom the ratio is 2 and nothing is zoomed at all, so “correcting” would halve a correct answer. The Pixel ratio field is shown above for exactly that reason: watching a correct reading sit next to a ratio of 2 is the fastest way to see that it is not the divisor. One caveat survives the experiment, and it is why the steps still say 100%: the Pointer Lock specification says these values are in CSS pixels, and Chrome measurably does not do that. Only Chrome was tested, and a browser that follows the spec here would report fewer counts as you zoom in.
Why a bank card and not a ruler on the screen
Because the distance that matters is travelled on the mousepad, not on the screen. A page has no idea how many millimetres of desk a screen pixel stands for — it does not know your monitor's physical size, and an on-screen ruler would be measuring the wrong surface anyway. So the ruler has to be a real object, and it may as well be one already on the desk: every credit, debit and bank card in the world is 85.60 × 53.98 mm to a tolerance of a tenth of a millimetre, because ISO/IEC 7810 ID-1 says so and cash machines enforce it.
The swipe uses Pointer Lock for a reason worth stating. Without it the cursor stops dead at the edge of the screen while your hand carries on, the movement deltas stop arriving, and the total comes out short — which looks exactly like a low-DPI mouse rather than like a failed measurement. That is the single most misleading thing a test like this can do, so if the browser will not grant the lock this panel prints no number at all.
How to get a reading you can trust
Swipe further. Everything else is second to this. The error is dominated by the few millimetres of slop at each end of the stroke, and that slop is a fixed distance, so it shrinks as a fraction of a longer swipe: one card carries about ±10%, two about ±5%, four about ±2.5%. The Honest range field is that arithmetic, and watching it narrow as you swipe further is the fastest way to see why long swipes matter.
Swipe straight, once, in one direction. The card measures a straight line. A stroke that wanders up and down, or backs up half-way, travelled further than the card says and reads high — so the panel measures how straight the swipe was and refuses the run rather than quietly reporting the DPI of a squiggle.
Then swipe again, faster. This is the test within the test. A sensor's DPI is a constant, so two swipes across the same card must produce the same figure. If a slow swipe and a fast one disagree, something speed-dependent sits between the sensor and this page, and on a desktop that is almost always pointer acceleration. The panel compares every run you take and says so outright when they do not agree, because two numbers that disagree tell you more than one number on its own ever could.
It says 1450 and my mouse is set to 1600
That is a 9% shortfall, and the usual causes are all in the list above rather than in the mouse: acceleration on a slow swipe, a pointer-speed slider off its centre notch, browser zoom, or a swipe that ended a few millimetres short of the card. Turn acceleration off, set zoom to 100%, swipe across four card lengths instead of two, and take three runs. If they agree with each other and still sit below the setting, check the mouse's own software — plenty of them expose several DPI stages on a button and boot into the wrong one.
Checking the rest of the mouse? The mouse button and scroll test covers left, middle and right clicks, double-click behaviour, the scroll wheel and dragging. For the other half of the input-lag question, the refresh rate test measures what your display does with all those reports.
