Polling rate is the number of times per second your mouse reports its position to your computer, measured in hertz, and most modern mice advertise 125 Hz, 500 Hz, 1000 Hz, or 8000 Hz tiers. Mouse Tester does not measure polling rate directly; it tests something adjacent but equally important: whether each button press on your mouse actually reaches the browser as a recognized MouseEvent.button code. The two checks answer different questions, but they share the same diagnostic goal, which is confirming that your mouse is delivering what your computer expects from it. A mouse can advertise a 1000 Hz polling rate and still feel sluggish if a button event is dropped, remapped, or never delivered to the page. That is why the button-event check is a useful first step before you dig into firmware, drivers, or manufacturer software.
What polling rate actually measures
Polling rate describes how often the mouse tells the host where the cursor is. The host, which is your computer or browser, never asks; it waits for the next report. A 125 Hz mouse sends 125 position reports per second, a 500 Hz mouse sends 500, a 1000 Hz mouse sends 1000, and an 8000 Hz mouse sends 8000. Common tiers, in order from least to most responsive, are 125 Hz for office or battery-saver modes, 500 Hz for general use, and 1000 Hz for gaming. Anything above 1000 Hz is marketed for high-frame-rate competitive play, though the practical ceiling depends on the USB transport, the driver, and the application.
Polling rate only describes motion reports. It says nothing about what happens when you press a button. A button press is a separate event sent the moment you actuate the switch, and the browser handles it through its own event pipeline. Two mice with identical 1000 Hz polling rates can produce noticeably different click feel depending on how the button event arrives, how the operating system remaps it, and how the application consumes it. Understanding that distinction matters because most "is my mouse slow?" complaints come down to button response, not position reporting.
Where polling rate tests stop and button tests begin
Dedicated polling-rate tools measure how often the host receives motion samples, usually by tracking how fast pointer coordinates change during continuous movement. They are excellent for confirming that your dongle, cable, or driver is delivering position reports at the expected rate. They do not, however, tell you whether the side button you press in a design app actually registers, or whether the back button you press in the browser fires a navigation event before the page ever sees it.
Mouse Tester is built to cover that gap. The tool listens for mousedown events on a single dashed target and records the integer button code the browser delivers. It tallies a total count, one named count per Web-defined button code, and a short recent list of the last eight labels received. It does not claim to test polling rate, debounce, switch force, or wireless latency. What it does claim is narrow and verifiable: each time a button event reaches the test area, the matching named counter goes up by one.
This makes it a complementary check. If your polling rate is healthy and your buttons still feel unresponsive, the button-event layer is the next place to look. If the buttons do register correctly here, the issue is almost certainly downstream of the browser, in the application, the driver, the extension stack, or the game profile.
Run a button event test with Mouse Tester
The test is intentionally short. You do not need to install anything, sign in, or move the mouse around. The page already has a dashed target loaded and waiting.
- Place the pointer inside the dashed target on the Mouse Tester page.
- Press your primary button once, then your middle or wheel button, then your secondary button, one at a time.
- If your mouse has extra buttons, press the back and forward side buttons too, one at a time.
- Watch the total count and the named counters after each press; each press should add exactly one to the total and to the matching named label.
- Glance at the recent list to confirm the order you pressed matches the order the browser received.
- Press Reset to clear the session if you want a clean baseline, then repeat the same sequence as a sanity check.
The target suppresses its own context menu and any default auxiliary activation while the pointer is inside it, so a middle or right click will not trigger the browser's own menu and replace your test result. Counts remain in the current tab only, and closing or refreshing the page wipes the session.
Read the button code results
Mouse Tester follows the Web platform's MouseEvent.button mapping rather than assumptions about the physical position of switches. The mapping is documented in the W3C Pointer Events specification and summarized on MDN's MouseEvent.button page. Five integer codes have named labels in the tool, and any other integer is shown as Unknown with its raw value. Fractional codes are rejected because the documented mapping uses integer codes only.
| Code | Label | Common physical meaning |
|---|---|---|
| 0 | Primary | The main activation button, configurable per user or operating-system setting |
| 1 | Auxiliary | Commonly the wheel click or middle button |
| 2 | Secondary | Commonly the right-side button |
| 3 | Back | Side button the browser typically maps to history-back |
| 4 | Forward | Side button the browser typically maps to history-forward |
The Primary label does not always mean the physical left button. Operating-system settings can swap the left and right physical buttons, and the Web event model follows the configured role, not the physical side. Auxiliary is often the middle or wheel-click button. Back and Forward are commonly the extra side buttons on a productivity or gaming mouse, but only when the browser exposes them; many browsers reserve these codes for their own navigation.
What a zero count actually means
A zero on a named counter is the most misread result. It does not prove the switch is broken. It only proves that no matching event reached the test target during your session. Several layers can absorb the event before the page sees it:
- The browser may claim the button itself; back and forward side buttons often trigger history navigation before any page-level handler runs.
- An installed extension can remap a button to a shortcut or macro before the page receives the event.
- Accessibility software can synthesize or consume events for switch control or dwell-click workflows.
- A remote-desktop session can flatten or reinterpret button codes depending on the transport.
- Manufacturer driver software can assign a side button to a keystroke or a desktop-level action that bypasses the browser entirely.
If a button shows zero, switch to the application where the original problem occurs and repeat the test there. Games, design tools, and 3D editors often have their own button-mapping layers, so a result that looks bad in the browser can be normal in another host. If the count is zero everywhere, the next step is the device's own configuration software, not more clicks or isolated tests. Mouse Tester reports what the browser sees, not what the switch should do.
Pair this check with other quick tests
Button events are only one layer of the input stack. If your goal is to verify overall mouse performance, the button-event test sits between a polling-rate check and an application-level mapping check. Run the polling-rate test first to confirm position reports are arriving at the expected rate, then open Mouse Tester to confirm the buttons themselves are reaching the browser. If both pass and a problem persists, the remaining suspects are the application's input mapping, the user profile, or the device firmware.
You can extend the same pattern to the keyboard, the scroll wheel, and the click cadence. A consistent diagnostic routine, covering polling rate, button events, scroll events, and click interval, covers the main symptoms people describe when they say their mouse feels off, and it does so without installing drivers, signing in, or uploading any data. Counts stay in your current tab, and resetting is one click away.
For a deeper look, see Mouse Scroll Test on iPhone: Verify Scroll Directions.
For a deeper look, see How to Test a Mouse Scroll Wheel in Your Browser.