DeviceBenchFree online mouse tester
Mouse test that names the switch that stopped reporting
Every switch a browser has a name for is on the drawing — left, right, the wheel pressed down, and the two thumb buttons — each with its own press counter. A switch that has died leaves its zone gray while the rest turn cyan; one that sticks leaves its zone amber after your finger has lifted; and one that fires twice on a single press runs its counter ahead of you. The thumb buttons reach a page as buttons 3 and 4 only when something stops the browser spending them on back and forward, which is what the test pad does inside its own borders.
- 100% free
- No signup
- 5 switches
- Counts every press
- Wheel notches too
Move onto the pad and press each button once, wheel included.
- Leftbutton 0Under the index fingerno report0
- Rightbutton 2Under the middle fingerno report0
- Wheel clickbutton 1The wheel pressed straight downno report0
- Forwardbutton 4Upper thumb buttonno report0
- Backbutton 3Lower thumb buttonno report0
The pad holds the page still and cancels the context menu while your pointer is inside it, so the right button and the two thumb buttons can be pressed as often as you like.
Four things on a modern mouse never become browser buttons at all: the DPI switch behind the wheel, the profile button underneath, the sniper button some pads put beside the thumb rest, and the numbered keys on an MMO mouse. Those are resolved in the mouse’s own firmware or by its driver, and reach a web page as keystrokes if they reach it at all.
How to test a mouse button by button
Three passes, and the order matters: the switches most likely to be dead are the ones ordinary use never presses.
Put the pointer on the pad and click left, then right
The pad is the only region on this page that listens, and it holds the context menu shut for as long as your pointer is inside it — press the right button ten times in a row and nothing pops up to interrupt you. Every press adds one to the number printed on that part of the drawing, and the zone turns cyan the first time that switch fires.
Press the wheel straight down, then both thumb buttons
Pushing the wheel down is the middle switch, and it is the one people most often discover has died, because ordinary use almost never presses it. The thumb buttons come next: the pad cancels the navigation they would otherwise trigger, so instead of sending your browser back a page they land as buttons 3 and 4 and light the two boxes on the left flank.
Read the zone that never left gray
A zone still gray after you have pressed it is a switch reporting nothing, which is the answer most visitors came for. A zone that stays amber once your finger has lifted means the release never arrived and the button is mechanically stuck — the same fault that makes a desktop start selecting everything you drag across. A counter that climbs faster than you pressed is a third fault entirely, and it has its own page.
Technical specifications
| Switches tracked | 5 — left (button 0), wheel click (1), right (2), back (3), forward (4) |
|---|---|
| Events read | pointerdown and pointerup, so a pen and a trackpad report through the same five slots as a mouse |
| Held-button decoding | The event.buttons bitmask, where right is bit 1 and the wheel is bit 2 — deliberately not the button order |
| Side-button navigation | Default prevented on mousedown, mouseup and auxclick for buttons 3 and 4, inside the pad only |
| Context menu | Suppressed while the pointer is over the pad so the right button can be hammered |
| Wheel rotation | Counted as notches up and down on its own row; rotation is not a press |
| Never visible to a browser | The DPI switch, the profile button underneath, and any key an MMO mouse sends as a keyboard macro |
| Data kept | None — the five counters are numbers in memory, and Reset zeroes them |
Frequently asked questions
My thumb buttons do nothing on other test pages. Why?
Because the browser spends them before the page ever sees them. Chrome and Firefox both map the two side buttons to back and forward in history, and unless a page cancels the default on mousedown, mouseup and auxclick, pressing one navigates away instead of registering — which is exactly what this pad cancels inside its own borders. If a thumb button still shows nothing here, the next suspect is your mouse software: several vendors ship the side buttons bound to the Alt+Left and Alt+Right keystrokes rather than to buttons 3 and 4, and a keystroke never arrives as a mouse button.
What do button 0, 1 and 2 mean?
They are the numbers Pointer Events gives the switches, and the middle one surprises everybody: 0 is left, 1 is the wheel click, 2 is right. The order changes again in the bitmask that reports everything held down at once, where the right button sits at bit 1 and the wheel at bit 2. Feeding one of those into the other is the most common bug in a home-made mouse tester, and because it only shows while a button is physically down, it survives a long time.
My mouse has twelve buttons. Where are the rest?
They are not reaching the browser as mouse buttons. Pointer Events has names for five, and a mouse with a thumb keypad ships those keys through its own driver as keyboard macros, so they arrive as F13 or Ctrl+Shift+3 rather than as button 5. If yours does send a sixth or seventh button, the page prints the raw number in a note under the drawing instead of pretending nothing happened.
The left button sometimes registers two clicks. Is that this page?
No, that is the mouse, and the fault has a name: the metal contact inside the switch rebounds on its way shut, and the mouse counts the rebound as a press of its own. You can see it here as a counter jumping by two on one deliberate click, but the double click test is the page that times the gap between the pair and tells you whether it landed inside the window an operating system treats as a deliberate double click.
Does the wheel count as a button?
Pressing it does; rolling it does not. The click is the middle switch and shares its counter with button 1, while rotation arrives as a different kind of event that carries a distance rather than a press, which is why notches up and down are counted on their own row here. A wheel that registers a click every time you roll it has a worn middle switch, and you will watch the click counter climb while you scroll.
Can I test a trackpad or a touch screen here?
Partly. A trackpad reports through the same first two slots — a two-finger tap is turned into a right click by the operating system, so it lands here as button 2 — but there are no middle or thumb switches on it to find. A touch screen has one contact and no buttons at all, and the page says so when it detects a coarse pointer as your primary one.
A button works here but not in one game. What now?
If the switch reports on this page the hardware is doing its job, so the problem sits above it. The usual causes are a per-application profile in the mouse software that swapped itself in when the game launched, a binding that turned the button into a macro, or a game reading raw input and ignoring anything the driver remapped. Close the vendor software and test again in the game: if the button comes back, you have found which of the three it was.
About the five switches a browser can see
A browser never sees a mouse; it sees a pointer with at most five named switches on it, described by two fields that do not use the same order. PointerEvent.button says which switch changed in the event you are reading and numbers the wheel click 1 and the right button 2. PointerEvent.buttons is a bitmask of everything held down at that instant, and it puts the right button at bit 1 and the wheel at bit 2. Both are needed — one answers “what was just pressed”, the other “what is down now” — and mixing them turns a held right button into a middle click on screen.
The thumb buttons deserve their own paragraph, because they are the ones people come here convinced are broken. Both of the major browsers hand buttons 3 and 4 to history navigation, so on a page that does not intervene, pressing one takes you off the test instead of registering on it. There is a way to tell the two failures apart without any tool: if your browser jumps back a page while the box stays gray, the browser took the press and the switch is fine. If pressing does nothing anywhere, click into any text field and press it again — a driver that has remapped the button to a keystroke will leave the keystroke behind, and a switch that is genuinely dead will not. Rotation is a separate question from the click, and belongs to the scroll wheel test.
Six questions cover almost every mouse complaint, and they are worth asking in this order. Does the switch report at all — that is this page. Does one press arrive as two: the double click test times the gap and says whether it is chatter. Does the wheel skip a notch or jump back a step. Does the pointer itself stutter or drift while your hand moves smoothly — the cursor test draws the path so you can see the break. Is the mouse reporting often enough, which the polling rate test counts, and is the sensor resolution the number on the box, which the mouse DPI test approximates from a measured drag. If every one of those passes and your clicks still feel slow, the subject is your hand rather than the hardware, and the CPS test scores that instead.
What the counters keep
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
Each of the five counters is one number held for as long as this tab stays open. No record is made of which button you pressed in what order, so there is no sequence anywhere to keep, and Reset leaves nothing behind it.