How the polling rate is measured
While it moves, a mouse sends its position to the computer at a fixed rate: its polling rate. 1000 Hz means a report every millisecond. Each report reaches the browser as a pointer event stamped with the time the system received it, and this page records that timestamp for every report it gets, including reports the browser bundled into a single event, which it unpacks one by one.
The gaps between consecutive reports become rates. A gap longer than 50 ms means the mouse stood still, so it is left out rather than counted as a very slow report. From the rest the page works out three numbers:
- Peak: the rate counted over spans of 16 ms, taking the 95th percentile across all spans. This is what the mouse does when it moves fast enough to report at every poll, without being thrown by one odd interval.
- Average: every report divided by the time spent moving. Slow stretches pull it down, because a mouse that barely moves has little to report.
- Median interval: the typical gap between two reports.
When the peak is within 15% of a standard rate (125, 250, 500, 1000, 2000, 4000 or 8000 Hz), the page names it. Mice only ever run at those rates, so a reading in between tells you something held reports back.
Timing an 8000 Hz mouse means telling 125 µs gaps apart, and browsers round their clock to make timing attacks harder: to about 100 µs in Chrome and 1 ms in Firefox and Safari. This site asks the browser for cross-origin isolation, which lets it use a finer clock, usually a few microseconds. Where the clock is still coarse, counting reports over 16 ms spans keeps the rate accurate to a few percent even though single gaps can’t be timed, and the page says so.
Why a browser can read lower than your mouse
Chrome and Edge offer raw pointer updates, an event for every report the mouse sends, and this page uses them where they exist. Other browsers only send pointer move events, which are free to merge several reports into one and may arrive once per display frame. Where the browser hands over the merged reports each with its own timestamp, nothing is lost; where it doesn’t, the reading drops toward your display’s refresh rate, and the page tells you when that seems to be happening.
Outside the browser, a wireless receiver far from the mouse or behind the computer, a USB hub, power saving on the mouse or its USB port, and a busy computer can all lower the rate or make it uneven. The mouse itself only reports when it moves, so move it quickly and continuously, in circles, for a few seconds. Locking the pointer keeps the cursor from stopping at the edge of the screen.
Buttons
Each button is recorded the moment it goes down and the moment it comes back up, from the event’s own timestamp. Buttons pressed together are tracked separately, and the page listens to both pointer and mouse events so that a second button pressed while another is held isn’t missed. Inside the test box, the right-click menu, middle-click scrolling and back and forward navigation are switched off, so every button can be pressed without leaving the page.
The back and forward buttons are the ones that most often fail to show up. Many mice let their driver software turn them into keyboard shortcuts, and some systems, macOS in particular, don’t pass side buttons to the browser at all. If a side button arrives as the keyboard’s Back or Forward key, the page says so.
Double clicks and switch wear
Inside a mouse button is a small metal switch. As it wears, its contacts can bounce, so a single press registers as two: a click becomes a double click, and a held drag lets go by itself. The fault usually shows up on the left button first, because it does the most work.
The page flags a press that comes too soon after the previous press of the same button: closer than the threshold you choose, or less than half the threshold after the button was let go, which catches a switch that chatters as it opens. A deliberate double click takes well over 100 ms from press to press, so the default of 80 ms leaves room for normal clicking. Click each button one click at a time, 20 or more times; a failing switch rarely misbehaves on every click.
The scroll wheel
Each turn of the wheel reaches the page as a wheel event with a distance and a unit. A notched wheel sends one event per notch with a large, fixed distance: a number of lines, or around 100 pixels. The page estimates steps from that, counting an event with twice the distance as two notches the browser merged. Trackpads and free-spinning or smooth-scrolling wheels send a stream of small, uneven distances instead; the page recognizes that and doesn’t pretend to count notches.
A worn or dirty wheel encoder misreads a step now and then and reports it backwards, which makes a page jump back while you scroll. The page watches for a single event going the other way in the middle of a steady scroll, with events on either side less than 100 ms away. Turning the wheel back on purpose isn’t flagged, because the scroll then carries on the new way.
Questions
Why does it show 500 Hz for my 1000 Hz mouse?
Usually because reports were held back before they reached the page. A mouse only reports while it moves, so slow movement reads low: move it quickly and without stopping, in circles, for a few seconds. Browsers other than Chrome and Edge may merge reports into one event per display frame. Wireless mice can drop to a lower rate when the receiver is far away or when power saving kicks in, and a USB hub or a busy computer can do the same. Also check the mouse software: many mice ship at 500 Hz and have to be switched to 1000.
What polling rate should I use?
1000 Hz suits almost everyone: it reports every millisecond, and the difference from higher rates is under a millisecond of delay. 2000 to 8000 Hz can make the cursor track a little more smoothly on high refresh rate displays, but it costs more processor time and battery, and some games and older computers stutter at 4000 Hz and up. 125 Hz, the old default, adds up to 8 ms of delay and is worth raising.
How can I tell if my mouse is double clicking?
Click one button at a time in the buttons box, 20 or more times, at a normal pace. If two presses land closer together than the threshold, or a press follows its own release by a few milliseconds, the page lists it as a suspected double click. A finger can’t release and press again that fast, so repeated hits on one button point to a worn switch. Other signs are drags that let go by themselves and single clicks opening files.
Why don’t my back and forward buttons register?
Either the browser never receives them as mouse buttons, or it acts on them before the page can. Many mice let their software map the side buttons to keyboard shortcuts, and some systems, macOS in particular, don’t pass side buttons to the browser at all. If your browser went back or forward instead of lighting the button, try again with the pointer inside the buttons box, where the page blocks navigation, or check the button assignments in your mouse software.
Why doesn’t the wheel test count steps on my trackpad?
Because a trackpad has no steps. A notched wheel sends one event per notch with a large, fixed distance, which can be counted. A trackpad, a free-spinning wheel or a system that smooths scrolling sends many small, uneven distances instead. The page detects that and says so rather than making up a count. Up, down and tilt still register either way.
Does locking the pointer change the result?
Not the polling rate itself. Locking hides the cursor and keeps it inside the box, so you can keep moving fast without stopping at the edge of the screen, which makes the reading steadier. Where the browser supports it, the lock also asks for raw movement without pointer acceleration. Press Esc to release it.