How to use it
- Open the Polling rate tab, keep “Raw updates” selected if your browser offers it, and press Measure for 5 s.
- Move the mouse in large, continuous circles inside the box until the bar fills. Pauses over 100 ms are discarded, but short stops lower the sample count.
- Read the estimated rate, the nearest standard rate (125/250/500/1000/2000/4000/8000 Hz) and the quality notes. The histogram shows how tightly the intervals cluster.
- For DPI, open the DPI estimate tab, type the distance you will move (a ruler next to the mouse helps), press Start DPI run, move the mouse exactly that far to the right and click or press Esc.
- Repeat two or three times; copy or download the JSON/CSV if you want to keep the numbers.
Example
A 1000 Hz mouse in Chrome on a 144 Hz monitor records 4,812 intervals in 5 seconds with a median of 1.00 ms, a mean of 1.04 ms and a CV of 9%: the estimate is ~1000 Hz, quality “Good”. The same mouse in Firefox shows a median of 6.9 ms (~144 Hz): the event rate matches the refresh rate, so the tool marks the result as frame-locked and explains that it reflects the browser, not the mouse. For DPI, moving 10 cm (3.94 in) produces 3,150 counts: 3,150 ÷ 3.94 = ~800 DPI.
How the estimates are made
interval = timeStamp[i] − timeStamp[i−1] (pauses > 100 ms dropped)
event rate = 1000 / median(interval) Hz
jitter (CV) = stdev(interval) / mean(interval)
frame-locked : |rate − refresh| < 12% of refresh
DPI = Σ|movementX| ÷ distance in inches (1 in = 2.54 cm)Event timestamps come from the Pointer Events API. With “Raw updates” the page listens to pointerrawupdate, which the browser dispatches for every input report it receives; with “pointermove + coalesced” it unpacks getCoalescedEvents(), the events the browser folded into each per-frame pointermove. The display refresh is estimated from the first 60 animation frames. Browser timestamps are rounded to about 0.1 ms, so 4000 and 8000 Hz mice show a wider spread than they really have. The DPI run uses the Pointer Lock API with unadjustedMovement where the browser supports it; when it does not, the run falls back to pointer deltas in device pixels, which include the operating system’s pointer speed, “enhance pointer precision” and display scaling.
Sources: W3C Pointer Events Level 3 – coalesced events and pointerrawupdate, W3C Pointer Lock 2.0 – unadjustedMovement, MDN – PointerEvent.getCoalescedEvents().
These are estimates derived from what the browser delivers, not measurements of the hardware. A low figure can mean a slow mouse, a browser that coalesces events, a busy system or a wireless link saving power. To verify a mouse’s configured rate or DPI, use the manufacturer’s software.
Questions
- Why does my 1000 Hz mouse show only 60, 120 or 144 Hz?
- The browser is delivering one pointer event per screen refresh and attaching the rest as coalesced events. Switch to “Raw updates” in Chrome or Edge; in Firefox and Safari there is no raw event stream, so the test can only show the frame rate. The tool flags this case as frame-locked.
- Is the DPI result exact?
- No. It depends on how precisely you moved the mouse the stated distance and on whether raw input was available. Expect a spread of a few percent between runs; the “nearest common setting” line snaps the estimate to the DPI steps most mice offer (400, 800, 1600 …).
- What is the difference between polling rate and DPI?
- Polling rate is how many times per second the mouse reports its position to the computer (Hz). DPI, strictly CPI, is how many counts the sensor produces per inch of travel. A higher polling rate reduces latency and jitter; a higher DPI makes the cursor move further per centimetre.
- Does this work with a touchpad or a pen?
- Only mouse pointer events are counted. Touchpads report through the same path but at the rate the driver chooses, so the figures are not comparable with a USB mouse; pen and touch input are ignored.