A mouse button test in the browser reads the integer MouseEvent.button code that the page receives on each mousedown and tells you which of five named buttons the browser actually saw. The five recognized codes are integer 0 Primary, 1 Auxiliary, 2 Secondary, 3 Back, and 4 Forward, and that mapping comes from the W3C Pointer Events specification rather than from any assumption about physical left or right. So a primary count of one and a secondary count of zero on the tool gives you a clear, evidence-based statement about what the page received, not a verdict about the hardware. When the pointer sits inside the dashed target and you press one button at a time, the tool increments an overall total, increments the matching named counter, and appends the label to a short Recent list of the last eight accepted presses. That is exactly the job of the Mouse Tester page, and the rest of this guide explains how to run it, read each result, and avoid misreading a zero count as a hardware failure.
Most people arrive at a mouse button test because something looks wrong: a Back key that stopped doing anything in the browser, a middle-click paste that no longer fires, an extra side button that registers when it should not, or a freshly remapped mouse where physical left now means Secondary. The browser only knows about buttons that reach the page as mouse events, and several layers — the browser, the operating system, driver software, accessibility hooks, browser extensions, and remote-desktop tools — can absorb a press before the page ever sees a code. That is why a tool that listens to button-down events and labels each one with a recognized web name is useful: it tells you what the browser ultimately delivered, so you can compare that with what you expected to happen. Try the Mouse Tester to do this in your browser.
The Five MouseEvent.button Codes the Tool Can Read
The browser hands each mousedown to the page as a single integer in MouseEvent.button. The MDN reference for MouseEvent.button lists the five well-known codes, and the Mouse Tester applies those same labels in the order the browser delivers them. Any other integer — for example, a synthetic value that an accessibility tool injects — appears as Unknown with its numeric code, and fractional values are rejected because the documented mapping uses integers only.
| Code | Name in the tool | Common physical meaning |
|---|---|---|
| 0 | Primary | Main activation button (commonly left; swappable in OS settings) |
| 1 | Auxiliary | Middle button or wheel click |
| 2 | Secondary | Secondary button (commonly right; swappable in OS settings) |
| 3 | Back | Extra side button that the browser usually maps to history.back() |
| 4 | Forward | Extra side button that the browser usually maps to history.forward() |
Two details from that table drive the rest of this article. First, Primary and Secondary describe roles in the web event model, not physical sides, so a left-handed user with right-handed mouse settings will still see Primary firing from the right switch. Second, Back and Forward are only present when the browser exposes them — when an extension, a remote session, or the OS itself captures the press before the page, the named count for that code stays at zero even though the hardware itself is fine.
How to Run a Mouse Button Test
Open Mouse Tester in your browser, rest your pointer inside the dashed target, and work through the buttons your device exposes. The page suppresses its own context menu and auxiliary default behavior inside the target so that a middle or right press does not immediately replace the result with a menu or paste action.
- Move the pointer into the dashed target on the page and leave it there for the whole session.
- Press the primary button one deliberate time, then release.
- Press the secondary button once, the middle or wheel button once, and any extra side buttons (Back, Forward) one at a time.
- After each press, confirm that the total count increased by one and that the matching named label also increased by one.
- Repeat the same sequence inside the application where the problem actually shows up — a game, design tool, or alternate browser — then use Reset test to clear this browser-only session.
One press per button is the starting check. To rule out flakiness, repeat the sequence three or four times and confirm the same named counts increase each round. If a button produces two events for a single physical press, the count rises by two on that round and you have a useful data point — pair it with manufacturer diagnostics before treating it as a hardware failure.
Reading the Counts and the Recent List
The tool shows three pieces of information on every press: a single Total counter that increments on every button-down delivered to the target, five named counters (Primary, Auxiliary, Secondary, Back, Forward) that each increment only when the matching code arrives, and a Recent list that retains the latest eight accepted labels in the order the browser delivered them.
The named counters are how you answer the original question, namely, is this mouse button working? If the Back button on your mouse should send code 3 and the Back counter rises by one after each press, the browser is delivering the event. If the Back counter stays at zero, the event did not arrive at the page for some reason. The Recent list takes that one step further by preserving the order: if you press Back, then Forward, then Back again, the list should read Back, Forward, Back from the bottom up. That order check matters when an application or driver is consuming certain events and remapping others, because a button may still arrive but with a different name than you expected.
Why a Button May Not Register on the Page
A zero count for a named button is real data, but it is not a hardware diagnosis. The press may never have reached the page at all, and the most common reasons are layers above the device:
- Browser navigation: Back and Forward buttons are routinely assigned to history.back() and history.forward() by the browser itself, so the page often never receives the corresponding mousedown.
- Operating system: macOS, Windows, and many Linux desktop environments can remap extra buttons or intercept them for Mission Control, task view, or virtual desktop switching.
- Drivers and manufacturer software: Logitech, Razer, Corsair, and similar utilities often claim extra buttons for macros or DPI cycling before the browser sees them.
- Extensions: tab managers, gesture tools, and accessibility helpers frequently bind side buttons to their own shortcuts.
- Remote-desktop clients: when the local mouse is moving a remote cursor, button codes can be translated or dropped depending on the protocol.
When any of these layers capture the press, preventing default behavior inside the target cannot force the page to receive it. The right next step is to test the same device in the application where the problem occurs, then in another browser, before concluding anything about the physical switch itself.
What This Test Does Not Measure
Mouse Tester reports browser button-down events only. It does not measure click speed, the interval between two clicks, polling rate, button debounce, wireless latency, switch actuation force, pointer movement, scroll-wheel deltas, or drag behavior. It also cannot certify accessibility, game suitability, or hardware condition — those claims need different measurements and, in some cases, physical access to the device.
Because every count lives in the current tab only, switching tabs, reloading the page, or pressing Reset test clears the session. The tool does not request a device identifier, install a driver, upload events, save a history, or listen outside the visible test target, so any verdict you make from a session belongs to that one browser on that one device at that one moment. If you need to compare, run the same sequence in two browsers and treat identical named counts as a positive signal that the device is delivering standard mouse events end to end.
If you're weighing options, Mouse Scroll Test on Windows: Check Wheel Directions covers this in detail.
If you're weighing options, Mouse Click Test: Verify One Press per Button covers this in detail.