A Windows 11 mouse button test in a browser reports the exact MouseEvent.button code (0 Primary, 1 Auxiliary, 2 Secondary, 3 Back, 4 Forward) each press delivers to a web page, so it can confirm which physical buttons Windows 11 is actually passing through to applications. The built-in Settings app only lets you swap primary and secondary, change scroll direction, and tune pointer speed; it does not show you which buttons the browser can detect or whether extra side buttons on a gaming mouse are even reaching the page. To run quick checks without installing a driver, open the Mouse Tester in your Windows 11 browser, place the cursor inside the dashed target, and press each button one at a time. The widget increments a total, shows one count per named code, and keeps the latest eight button labels in the order they arrived. Use this when a side button appears dead, when a click feels unresponsive in a specific app, or when you want to verify that Windows 11 has not remapped a function behind your back.
What Windows 11's Built-In Mouse Settings Actually Do
Windows 11 ships a mouse panel under Settings, then Bluetooth and devices, then Mouse, which exposes five user-facing options: primary mouse button (left or right), scroll direction, scroll wheel lines to scroll, pointer speed, and the "Enhance pointer precision" toggle. A "Mouse pointer crosshair" toggle and a link to "Additional mouse settings" sit at the bottom of the same panel. The Additional mouse settings link opens the legacy Control Panel applet, which adds pointer shadow, snap-to-default, and visibility trails, but none of these screens emit a button-press event or show a live counter for the buttons on your device.
What that means in practice is that Windows 11 can change what each button does after the operating system receives it, but it does not show what reached the operating system in the first place. A gaming mouse with six or seven physical buttons, for example, exposes extra inputs through the manufacturer's driver, not through Settings. If the driver is missing, the side buttons may never reach the browser at all, and no setting in Windows 11 will tell you that. A browser-based test fills that gap by listening to the mousedown event the page actually receives and reporting the integer code attached to it.
Why a Browser-Based Test Adds Value in Windows 11
Browser event tests and the Windows Settings panel answer different questions. The Settings panel answers what Windows 11 does with this button. A browser test answers whether the browser received a MouseEvent.button code at all, and which one. Both pieces of information are useful when a button on a multi-button mouse suddenly stops working in a specific program. The Settings panel can show that primary and secondary are swapped in the way you expect; the browser test can confirm that the side button labeled "Back" on the mouse shell is actually firing with code 3 in the browser, rather than getting intercepted by a driver, remapped by an extension, or eaten by a remote-desktop session.
Running the test in the browser also avoids the need to install vendor software. Windows 11 does not bundle a generic button tester, and manufacturer utilities (Logi Options+, Razer Synapse, Corsair iCUE, SteelSeries GG) install background services that can themselves change how extra buttons appear in other applications. The Mouse Tester loads as a local web page, asks for no device identifier, and clears its in-memory counts when you refresh, close the tab, or hit Reset. For a focused check on Windows 11 of whether a specific physical button reaches the browser, it is a faster first step than opening any of those configuration suites.
How to Test Mouse Buttons on Windows 11
The test runs entirely inside a single browser tab. Use these steps on Windows 11 to verify each button on your mouse.
- Open your preferred browser on Windows 11 (Edge, Chrome, Firefox, or Brave) and navigate to the Mouse Tester page.
- Move the cursor inside the dashed target area on the page so the pointer remains there for the entire test.
- Press each physical mouse button one at a time: primary, middle or wheel click, secondary, back, and forward, in any order.
- Watch the total counter, the per-named count, and the recent list. Each successful press should add exactly one event to the total and to the matching named row.
- Press the same button a few more times to confirm the named count keeps rising and the recent list shows the same label in the order you pressed.
- Repeat the same sequence in the affected application, such as a game, a design tool, or your usual browser, to compare results.
- Click Reset test to clear the current tab's counts and start a fresh run.
Throughout the test, keep the cursor inside the dashed rectangle. Moving the pointer outside the target means the browser will not fire the mousedown event for any button you press, and the count will not move. The target also suppresses its own context menu and auxiliary activation while you press, so testing a secondary or middle button does not replace the result with a menu or a wheel-scroll gesture. Counts remain in the current tab only; closing the tab or refreshing the page clears the session, and the widget does not save a history outside the visible test target.
Reading the MouseEvent.Button Codes
The Web platform defines MouseEvent.button as an integer that identifies the button that caused a mouse event. The Mouse Tester labels codes 0 through 4 with friendly names. Codes outside that range are labeled Unknown with their numeric value, and fractional values are rejected because the mapping uses integers only.
| MouseEvent.button code | Named label | Common physical mapping |
|---|---|---|
| 0 | Primary | Main activation button (usually left) |
| 1 | Auxiliary | Middle button or wheel click |
| 2 | Secondary | Context button (usually right) |
| 3 | Back | Extra side button for navigating back |
| 4 | Forward | Extra side button for navigating forward |
Note that Primary describes the role, not the finger. Windows 11 lets users swap primary and secondary in the mouse settings, so a right-handed user who has flipped the setting will see the right physical button fire with code 0 and the left with code 2. The browser still reports the role, not the side. Auxiliary is most often a wheel click, but it can also be a dedicated middle button on trackballs and some ergonomic mice. Back and Forward are extra navigation buttons that the browser exposes when Windows 11 and the driver pass them through.
The label printed on the mouse shell is not a guarantee. A button marked "DPI" on a gaming mouse may send code 4 from the browser's point of view, and a side button labeled "Back" may not register at all. The exact mapping is documented in the MDN MouseEvent.button reference and the W3C Pointer Events specification. The distinction between button and buttons matters here: button identifies the single button associated with a press, while buttons is a bit field of buttons currently held during other mouse events. The Mouse Tester classifies the single button code on each mousedown and does not reconstruct a continuous held-button state.
When a Button Shows Zero Presses on Windows 11
A zero count for a button you pressed means the browser did not receive a matching MouseEvent.button code while the cursor was inside the target. On Windows 11, that can happen for several reasons before you ever conclude the mouse is broken.
- The browser itself consumes back and forward for in-page history navigation, so a quick press of the side button may move the page back instead of reaching the JavaScript handler.
- Manufacturer software installed on Windows 11 (Logi Options+, Razer Synapse, Corsair iCUE, SteelSeries GG) remaps the button to a keyboard shortcut, a macro, or a different mouse event before the page sees it.
- A browser extension such as a tab manager or a gestures add-on can intercept the extra buttons and never forward them.
- Remote-desktop, virtualization, or accessibility software running on Windows 11 can synthesize or strip mouse events on the way to the browser.
- The cursor drifted out of the dashed target between presses, so the mousedown event never landed on the test element.
Eliminate these by closing unrelated extensions, quitting the manufacturer's configuration app, and reloading the page. If the same button still produces zero after several deliberate presses with the cursor held inside the target, the event is being intercepted above the page level, and the remedy is at the operating system, driver, or extension layer, not inside the Mouse Tester. The tool cannot override higher-priority browser or system handling, and preventing default behavior on the target only reduces accidental actions within that area.
Test the Same Mouse in the App Where It Fails
Browser results are a strong starting point, but they are not the full picture. Some Windows 11 applications handle extra buttons with their own event loops and may ignore the standard MouseEvent.button codes entirely. A game using raw input, for example, reads from the device directly and may not produce any DOM event for the side button at all. A design tool that captures wheel events for zoom may swallow the wheel click before the browser can count it.
Use the Mouse Tester to confirm that the browser receives the codes you expect, then repeat the same button-by-button sequence inside the program where the problem shows up. Compare the named counts you see in the browser with what the application reports or behaves like. If the browser counts the press but the application does nothing, the issue is not the mouse or the operating system; it is the application's input handling. If the browser shows zero presses but a different tool on Windows 11 does show activity, the input is being intercepted by Windows 11, a driver, or an extension. The companion guide How to Test Mouse Buttons in Your Browser covers the same procedure in a more general browser context if you want a side-by-side reference.