Skip to main content

Mouse tester and polling rate test

Test CPS, polling rate, click latency, scroll, buttons, DPI, and drag.

Free & unlimitedWorks offline

Click here to start

Click as fast as you can for 5 seconds

All processing happens in your browser. No data is sent to any server.

This mouse tester splits into seven tabs, each measuring one thing the browser can actually observe. CPS counts clicks over a 1, 5 or 10 second run. Polling rate times the gaps between mousemove events and plots the last 100 samples against 125, 500 and 1000 Hz reference lines. Click latency measures how long a button stays down and flags re-triggers under 20 ms. Scroll counts wheel notches in each direction and catches direction reversals inside 50 ms. Button test maps event.button 0 to 4, so the side buttons are covered. Position and DPI reads clientX, screenX and movementX live, and the drag tab traces a path and totals its length.

Key facts about Mouse tester and polling rate test

Key facts about Mouse tester and polling rate test
TabsCPS, Polling rate, Click latency, Scroll, Button test, Position / DPI, Drag test
CPS durations1, 5 or 10 seconds, with a session best kept on screen
Polling methodinterval between consecutive mousemove events, converted to Hz
Polling bucketsreported as 125, 250, 500 or 1000 Hz once the rolling average crosses each mark
Polling chartlast 100 samples, capped at 1200 Hz, with 125 / 500 / 1000 Hz guide lines
Click latencymilliseconds between mousedown and mouseup on the same button, with min, max and average
Bounce flaga new mousedown less than 20 ms after the previous mouseup
Double-click speedgap between two mouseup events when it is under 500 ms
Scroll jittera wheel event whose direction reverses within 50 ms of the previous one
Buttons coveredleft 0, middle 1, right 2, back 3, forward 4 — extra buttons 5 and up are ignored
Position readoutclientX/Y inside the pad, screenX/Y on the desktop, and summed movementX/Y
Drag testtraces the pointer path on a canvas and totals the distance in CSS pixels

What happens to your file

Every measurement is taken from DOM mouse events inside this tab and kept in React state. No file is uploaded, no result is sent anywhere, and nothing is written to storage — reload the page and the CPS best, the polling samples, the latency records and the drag paths are all gone. The canvas trails in the Position and Drag tabs are drawn locally with the 2D context and never read back or exported. The tool cannot see your mouse outside this tab either: the moment the page loses focus, the event stream stops, which is why a test that looks dead is usually a page that is not focused.

About this tool

  1. 1

    Start on CPS

    Pick 1, 5 or 10 seconds and click inside the pad. The timer starts on your first click, the counter runs live, and the best result of the session stays on screen for comparison.

  2. 2

    Measure polling rate

    Switch to the Polling rate tab and move the mouse in continuous fast circles inside the pad. Slow or stop-start movement produces few samples and an artificially low reading.

  3. 3

    Read the Hz bucket, not the raw number

    The large figure is a rolling average of the last 100 intervals. Under it the tool names the nearest standard bucket — 125, 250, 500 or 1000 Hz — which is the number worth comparing to the spec sheet.

  4. 4

    Check click latency and bounce

    Click and release twenty or thirty times in the latency pad. Average duration tells you how long you hold a click; the debounce panel counts re-triggers under 20 ms, which indicate a failing switch.

  5. 5

    Test the wheel

    Scroll up and down inside the scroll pad. Up and down counts should match your notch count, and the jitter counter should stay at zero — reversals inside 50 ms point at a worn encoder.

  6. 6

    Cover all five buttons

    In Button test, press left, middle, right and both side buttons. Each lights up and keeps a press count, so a button that registers intermittently shows as a count that lags behind the others.

  7. 7

    Finish with position and drag

    Position / DPI draws a live trail and accumulates movementX and movementY. Drag test records each press-move-release as a path with its total length, which exposes a drag that breaks halfway.

Specs & compatibility
Browser supportChrome, Edge, Firefox, Safari and Opera — all use standard MouseEvent and WheelEvent
Polling ceilingbrowsers deliver mousemove on the event loop, so measured Hz saturates well below an 8000 Hz mouse
Safari and Firefoxcoalesce mousemove more aggressively than Chromium, so the same mouse reads lower
Side buttonsback and forward only arrive if the mouse sends them as buttons 3 and 4 rather than as keyboard macros
Scroll deltasdeltaY units differ between browsers and OS settings; counts are reliable, raw values are not comparable
movementX/Yalready scaled by OS pointer acceleration, so it is not a raw sensor count
Touchpadswork for CPS, scroll and position, but polling rate and button 3/4 tests do not apply
Account or installnone — no signup, no driver, no extension
  • Run the polling test on a mouse pad with the mouse actually moving; a stationary sensor sends no events and the reading collapses to zero.
  • A 1000 Hz mouse frequently reads 400 to 700 Hz here because the browser, not the mouse, sets how often mousemove is delivered — treat the bucket as a floor, not a ceiling.
  • If a 4000 or 8000 Hz mouse reads the same as a 1000 Hz one, that is the expected result; no browser API exposes report rates that high.
  • Compare two mice in the same browser window on the same day. Numbers from different browsers or different machines are not comparable.
  • Accumulated movementX and movementY are affected by Windows Enhance pointer precision and macOS pointer acceleration; turn acceleration off before comparing counts between mice.
  • Back and forward buttons that do nothing here are often configured in the vendor software to send Alt+Left and Alt+Right instead of real buttons 3 and 4.
  • Double-click speed only appears when two releases land within 500 ms; if a single physical click produces two entries, that is switch bounce rather than a fast double-click.
  • CPS test at 1, 5 and 10 seconds with a session best
  • Polling-rate chart over the last 100 mousemove intervals
  • Click duration with min, max, average and 20 ms bounce detection
  • Scroll direction counts and 50 ms jitter detection
  • All five standard buttons with per-button press counts
  • Live clientX, screenX and movement readout with a canvas trail
  • Drag path tracing with total distance
  • Checking whether a gaming mouse is actually running at the polling rate its software claims.
  • Proving a double-click fault on an ageing mouse before sending it back under warranty.
  • Diagnosing a scroll wheel that jumps backwards by watching the jitter counter.
  • Confirming that side buttons are mapped as real buttons rather than keyboard shortcuts.
  • Benchmarking click speed for games where clicks per second matter.
  • Testing whether a drag breaks mid-stroke, which points at a failing left switch rather than the sensor.
The number is derived from the gaps between mousemove events the browser hands to the page, and browsers coalesce pointer movement to their own schedule rather than to the USB report rate. Chromium delivers more samples than Firefox or Safari, so the same mouse reads differently in each. Use the bucket as evidence that the mouse is above 125 Hz and that its intervals are consistent; for an exact report rate you need a USB analyser or the vendor's own utility, not a web page.
Not directly. The Position tab accumulates movementX and movementY, but those values have already passed through the operating system's pointer acceleration and scaling, so they are not raw sensor counts. To approximate DPI you would disable pointer acceleration, move the mouse a measured physical distance in a straight line, and compare the accumulated movement to that distance. Even then the result is an estimate, which is why the tool shows the raw numbers instead of printing a DPI figure it cannot justify.
A bounce is recorded when a new mousedown arrives less than 20 ms after the previous mouseup on the same pad. No human releases and presses a button that fast, so a gap that short is the switch contact chattering as it opens. A healthy mouse records none in a long session. One or two may be noise; a steady stream while you click normally is the classic symptom of a worn Omron-style switch and is the same fault that causes unwanted double-clicks in file managers.
Wheel events depend on the encoder, the driver and the operating system's scroll settings. A free-spinning wheel with no detents fires many small events per revolution, and macOS inertial scrolling continues to fire events after you let go. Count in short, deliberate notches with smooth scrolling disabled if you want the numbers to line up. The direction counts and the jitter figure are the diagnostic parts; the raw deltaY values are not comparable between browsers.
Partly. CPS, click latency, scroll, position and drag all work, because those come from ordinary mouse and wheel events. The polling-rate tab will report something, but a trackpad has no USB report rate to compare it to, so the figure is meaningless. The button test only lights left, middle and right on most trackpads, since buttons 3 and 4 do not exist. Trackballs behave like mice for every tab.
No. Every counter, sample buffer and canvas trail lives in memory for as long as the page is open. Switching tabs inside the tool keeps its own tab state, but reloading the page clears everything, and nothing is written to local storage, cookies or any server. If you want to keep a result, take a screenshot before you reload — there is deliberately no history feature to store.

Related tools

View all

Part of Hardware testers that run in your browser

Updated

We use anonymous analytics to improve ToolChamp. No personal data is stored or sold. Privacy Policy