Mouse tester
Test every button, the scroll wheel, double-click chatter, and an approximate polling rate — all live, all in your browser, nothing sent anywhere. Useful for checking a new mouse out of the box, diagnosing a flaky click before you decide whether to return one, or just satisfying your own curiosity about what your hardware is actually reporting.
How each test works
| Test | What it checks | Events used |
|---|---|---|
| Button test | Whether each physical button is detected, and correctly identified | pointerdown, pointerup, click, auxclick, contextmenu |
| Live event log | The exact sequence and timing of what the browser received | same events, timestamped |
| Scroll wheel test | Whether up and down scroll register, and roughly how large each step is | wheel (deltaY) |
| Double-click chatter | Whether any pair of clicks arrives implausibly close together | click, event.timeStamp |
| Polling rate | Roughly how often movement updates arrive while you move the mouse | pointermove, event.timeStamp |
Every one of these reads event.button, event.deltaY or event.timeStamp — standard, well-specified properties of the DOM UI Events and Pointer Events specifications. Nothing here depends on a browser-specific quirk or an undocumented API.
Double-click chatter, explained properly
A mechanical mouse switch is a small metal leaf spring that physically bends to close a circuit when you press it. Over hundreds of thousands or millions of presses, that leaf fatigues. Instead of making one clean contact, a worn switch can bounce — break and remake the connection within a few milliseconds — and the mouse's own controller has no way to tell that bounce apart from a genuine second press. It reports two clicks. Your file gets deleted twice, your inventory slot drops two items, your browser tab opens twice: all from one press of your finger.
This is different from a switch that simply stops registering, or one that feels mushy — chatter specifically means extra clicks appearing that you did not make. It is also distinct from a deliberate fast double-click, which a healthy human finger can genuinely produce in roughly 80-150 milliseconds. The test above measures every gap between consecutive clicks and flags anything under a threshold (35ms by default, and adjustable) as implausible for a human to have intended — the kind of gap that indicates a bounce, not a decision.
If you see a chatter flag appear consistently on the same button, especially unprompted during single, deliberate clicks, that is reasonably strong evidence the switch is wearing out. Many mice with this problem are still within a warranty period specifically because switch wear is a known, common failure mode — worth checking before you assume the whole device needs replacing.
Why the polling-rate figure is only approximate
A mouse's real polling rate is a property of its USB firmware: how many times per second it sends a report to the operating system, regardless of whether the cursor actually moved. A web page never sees that raw stream. Between the USB report and your JavaScript, the operating system and the browser both apply their own batching — pointermove events are commonly coalesced to the monitor's refresh rate (60Hz, 144Hz, and so on), and browsers throttle event delivery further to avoid flooding a page with more updates than it can usefully render.
What this tool can honestly measure is how often your script was actually woken up while you moved the mouse inside the box — which puts a floor under the true rate without ever exactly matching it. That is why the estimate rounds to the nearest of the common values (125 / 250 / 500 / 1000Hz) rather than displaying a precise, jittery number: the precision the raw calculation implies is not real precision the browser can deliver.
A quick checklist for a used or new-to-you mouse
Whether you are testing something you just unboxed or checking a second-hand one before buying, running through these in order takes about two minutes:
- Every button registers at all. Left, right, middle-click (press the wheel down, don't just scroll it), and both side buttons if the mouse has them. A dead side button is one of the most common used-mouse faults.
- Right-click reports as button 2, not something else. A miswired or badly-driven mouse occasionally reports the wrong index.
- The left button single-clicks cleanly. Click it slowly, ten or twenty times, and watch the chatter test — a single flagged gap during slow, deliberate clicking is a real warning sign, not noise.
- The scroll wheel moves in both directions without skipping. Scroll slowly one notch at a time and confirm the direction and count match what you actually did.
- The cursor doesn't jump or freeze during the polling-rate test. Smooth movement inside the box should give a steady reading; if the estimated rate jumps around wildly or repeatedly drops to a very low number, that can indicate a failing sensor, a bad cable, or wireless interference rather than a real polling-rate limitation.
Frequently asked questions
What does the button test actually check?
It listens for real pointerdown/pointerup/click/auxclick events and reads event.button to work out which physical button you pressed — 0 for left, 1 for middle, 2 for right, and conventionally 3 and 4 for the back and forward side buttons. It confirms the browser is receiving a distinct, correctly identified signal for each button, which is the first thing to check when a button seems dead, sticky, or is reporting the wrong click.
Why does right-click show a menu on other sites but not here?
The test area calls preventDefault() on the contextmenu event, but only inside that one box — nowhere else on the page is affected. Without that, a right-click test would be interrupted by the browser's own menu before you could see the result register.
What is “double-click chatter” and why does it happen?
Chatter is when a single physical click gets reported as two (or more) separate clicks. Mechanical mouse switches contain a small metal leaf that bends to complete a circuit; as it wears from hundreds of thousands of presses, the contact can bounce or lose consistent connection for a fraction of a millisecond, and the controller reports that bounce as an extra click you never made. It shows up as an unwanted double-click when you meant to single-click — the single most common reason people test a mouse before returning or replacing it.
Why 35ms as the default chatter threshold — could a fast real double-click get flagged by mistake?
35ms is a conservative starting point: deliberate fast double-clicks from a human finger typically land in the 80-150ms range, well above it, while chatter bounces are usually well under 10-20ms. There is no single industry-certified number, though, which is why the threshold is a field you can change — lower it if you are a very fast, intentional double-clicker and want to rule out false positives, or raise it if you want to catch borderline cases.
Why is the polling-rate reading only approximate?
Browsers do not hand a web page the raw stream of USB reports a mouse sends. Pointer-movement events are coalesced and throttled — typically batched to the display's own refresh rate — before JavaScript ever sees them, so a script can only measure how often it was woken up, not the mouse's true internal polling interval. The estimate here is a reasonable lower bound and a useful sanity check (is this mouse obviously running at 125Hz or 1000Hz?), not a lab-grade measurement. A manufacturer's own configuration software, which talks to the device directly, will always be more precise.
What's a good polling rate, and does a higher number always mean better?
125Hz was the long-standing USB default and is still fine for ordinary use; 500-1000Hz is common on gaming mice and noticeably reduces input latency and cursor stepping in fast-paced games. Rates advertised well above 1000Hz mostly shrink an already-small latency gap further and matter far less than a mouse's actual sensor quality and your own monitor's refresh rate — a very high polling rate paired with a 60Hz screen has little to show for itself.
Can this tool detect a dying mouse before it fails completely?
It can surface early symptoms — occasional chatter on the left button, a side button that intermittently stops reporting, scroll events that skip a direction — that often show up sporadically well before a mouse fails outright. It cannot predict a failure with certainty or diagnose the internal cause (switch wear vs. a loose cable vs. a driver issue); it only tells you what the browser is currently receiving.
Does this work with a trackpad or a touchscreen instead of a mouse?
The button test and chatter test work with any pointing device that can send a click, including a trackpad's physical click and two-finger right-click gesture. The scroll test responds to two-finger trackpad scrolling the same way it responds to a wheel. The polling-rate test is only meaningful for a mouse — trackpads and touchscreens use entirely different sampling hardware, so a reading from one would not mean what this tool describes.
Is any of this sent anywhere?
No. Every event is read and processed in your browser only. Nothing about how you click, scroll or move your mouse is uploaded, logged, or stored anywhere — closing or reloading the page clears it all.
Use cases & limitations
Where this is genuinely useful
- Checking a new mouse before your return window closes. Every button, the wheel, and the classic chatter fault, in under two minutes.
- Diagnosing an intermittent problem. The live event log makes an inconsistent side button or a skipped scroll direction visible and timestamped instead of just "felt off".
- Sanity-checking a gaming mouse's advertised polling rate. Not a certified measurement, but enough to tell 125Hz from 1000Hz.
- Verifying a fix. After cleaning a switch or reinstalling drivers, re-run the chatter test to confirm the flagged gaps are actually gone rather than trusting a feeling.
What this tool cannot tell you
- The precise hardware polling rate. Browser event coalescing means the reading is an approximation, explained above — not a lab instrument's number.
- DPI or sensor accuracy. This tool has no way to measure how far the cursor moves relative to how far your hand physically moved.
- Click latency in milliseconds. It can show you the sequence and rough timing of events, but precise input-lag measurement needs hardware outside a browser's reach.
- The root cause of a fault. A dead button could be a worn switch, a broken solder joint, a driver issue, or a firmware bug — this tool reports the symptom the browser sees, not the internal diagnosis.
- Anything about a wireless dongle's own health independent of the mouse. If your mouse is wireless, a bad reading could be the receiver, interference, or low battery rather than the mouse itself.