Wondering which mouse button you are pressing? Short answer: open the mouse test and press each button once — left, middle (press straight down on the wheel), right, and any side buttons. Every press that reaches the browser lights up its label: Left, Middle or Right, with any extra button shown as Button N. A button that never lights up while the others do is the one to look at. The test confirms which buttons register — it does not measure how fast they poll or how they feel.
How to test all the buttons
- Left and right — click each once. These are the two the browser sees most reliably, because a left click also fires the normal
clickevent and a right click raises the context menu. - Middle — press straight down on the scroll wheel until it clicks. That is a real, separate button; a wheel that scrolls but does not click when pressed is a middle-button problem, not a scroll one (that is what the scroll wheel test is for).
- Side buttons — if your mouse has back/forward thumb buttons, press each. The browser only sees them if the system forwards them as ordinary button events (see the limit below).
- Watch for the opposite problem while you are there: a single press that registers twice is not a dead button but double-click chatter, and a button that never fires is covered in how to check which button is not registering.
Which mouse button am I pressing? The quick lookup
The browser gives every button a fixed number. Press one on the mouse test and you see its label; underneath, this is what the page receives. The last column marks what we captured ourselves: we drove Chrome 154 on macOS through its DevTools input API and logged what a page listener received. That shows how the browser labels each button. It is not a measurement of any mouse.
| Button | button | buttons while held | Events you see | Captured in our run |
|---|---|---|---|---|
| Left | 0 | 1 | click | Yes |
| Middle (wheel press) | 1 | 4 | auxclick | Yes |
| Right | 2 | 2 | contextmenu, then auxclick | Yes |
| Back (side) | 3 | 8 | Per the UI Events spec | Not exercised |
| Forward (side) | 4 | 16 | Per the UI Events spec | Not exercised |
Our automated run did not deliver the two side buttons to the page, so those two rows are the specification’s values, not something we observed. Test them on your own mouse in the mouse test rather than taking the table’s word for it.
Read the two number columns differently. button says which button just changed, and it counts left, middle, right (0, 1, 2). buttons is a bitmask of everything currently held, and its order is different: left is 1, right is 2, middle is 4. That mismatch is a quirk of the spec, not of your mouse, and it is why the test shows plain Left / Middle / Right instead of asking you to decode numbers.
Two buttons at once, and Ctrl-click
Holding two buttons. In our run, pressing the left button and, while it was still held, the right button produced a second press event with button 2 and buttons 3. The value is the held buttons added together (1 for left plus 2 for right). So if a test shows a button you did not expect, check whether another one is still held down.
Ctrl-click on a Mac. In the same Chrome-on-macOS run, a left press with Ctrl held came through as button 0 (left) with the Ctrl flag set, and the browser also raised the context-menu event. So a Ctrl-click can open the right-click menu while the test still reads Left. The operating system decides that mapping; the page only sees what it is sent.
Why only the left button fires click
Only a left click fires the ordinary click event. Middle, right and side presses come through as auxclick (or, for the right button, the contextmenu event), which is exactly why a page that only listens for click can look like it is ignoring your other buttons when they are working fine.
Side and extra buttons: why they sometimes don’t show
A side button that does nothing in the test is not automatically broken. Many gaming and multi-button mice route their thumb buttons through their own driver — bound to a macro, a keystroke, or navigation — so the button never reaches the browser as a mouse-button event at all. In that case the test is telling you the truth: from the browser’s point of view, no button event arrived. To tell “remapped” from “dead,” check the mouse’s own software: if the button is assigned to a macro it is working as configured; if it is set to a plain back/forward and still shows nothing anywhere, that points at the button or the connection.
What this test can and can’t tell you
The mouse test is a click-by-click, cross-browser check of which buttons register and how they are labelled. That is the reliable part, and it runs the same in every browser. Be clear about what it does not do:
- It cannot measure polling rate, DPI, or latency — those live below the browser, in the device and the operating system, and no web page can read them (see what a browser reports when you think it is measuring polling rate).
- It cannot judge switch feel, travel, or bounce timing. It sees that an event arrived, not the millisecond-level mechanics behind it.
- It reports what your system chose to send. A remapped or driver-handled button is a configuration fact, not a hardware verdict.
Used for what it is — a fast, honest confirmation of which buttons fire — the mouse button test answers the question most people actually have: is this button working right now, in this browser, on this mouse? For click-speed instead of button coverage, the CPS test and drag test cover the other things a mouse is asked to do.