Mouse latency is the delay between a physical mouse action and the moment software responds to that action. Because every measurable layer — USB polling, driver processing, operating-system handling, browser event delivery, and application logic — adds its own delay, latency is rarely a single number you can read off a screen. The fastest practical way to start a latency investigation inside a browser is to confirm that every button press actually reaches the page at all. A button that never registers has effectively infinite latency from the user's point of view. Mouse Tester turns that first check into a one-screen, no-install procedure: place the pointer inside a dashed target, press each available button one at a time, and watch named counts increment while the browser labels each event by its MouseEvent.button code. From there, you can decide whether the problem sits below the browser (a switch, driver, or transport layer the page can never see) or between the browser and the application where you actually noticed the lag.
What Mouse Latency Actually Includes
When readers search for how to test mouse latency, they often expect a single number in milliseconds. Real input delay is the sum of at least five independent stages, and a web page can only observe the final stages:
- Hardware switch activation — the physical moment a microswitch closes inside the mouse body.
- USB or wireless transport — the polling interval that determines how often the device reports its state, commonly 125 Hz, 500 Hz, 1000 Hz, or higher.
- Device driver and operating system — kernel processing, remapping, accessibility software, or vendor tools that may consume events before any page sees them.
- Browser event delivery — the path from raw input to a mousedown event the page can listen for.
- Application handling — game engine, design tool, or web app logic that responds to the event.
A web tool has no access to the first three stages. It can only report on what reaches its own event listeners. That is the exact reason the page-level test is so useful as a first step: it isolates the part of the chain you can actually observe in the browser, and it gives you a yes/no answer per button before you move on to timing measurements that require different tools or hardware.
Why Button Detection Comes First
Before measuring how fast a click arrives, you need to know the click arrives at all. If pressing the side button does not increment any counter on the page, the latency number you want to measure does not exist yet — no event means no timestamp. That is the gap the Mouse Tester fills. The widget sets up a large target, listens for mousedown events, and classifies each one using the standard Web mapping for MouseEvent.button: 0 Primary, 1 Auxiliary, 2 Secondary, 3 Back, 4 Forward. Codes outside that set are kept as numeric unknowns; fractional codes are rejected.
The target suppresses its own context menu and auxiliary activation so a Secondary or middle click does not immediately replace the result you are trying to record. Counts and the latest eight labels stay in the current tab; no upload, no install, no driver. Reset clears the in-memory session, and refreshing or closing the tab removes the state entirely.
Confirming the Browser Receives Every Button Press
This is the practical workflow for using the browser to confirm that every available button on your mouse is being delivered to a web page.
- Open the Mouse Tester in a fresh tab and let the page finish loading; the dashed target should fill the test area.
- Move the pointer inside the dashed target and click once with the main button; confirm that the total and the Primary count both increase by exactly one.
- Click the secondary button inside the target and verify the Secondary count increments by one while Primary stays where it was.
- Press the wheel or middle button and check the Auxiliary count; the target suppresses the usual default behavior so the test does not derail itself.
- Press each side button your mouse exposes; Back and Forward should each produce a separate named increment when the browser forwards them.
- Inspect the Recent list to confirm the order the browser actually delivered the events, not the order you thought you pressed them.
- Repeat any suspect button several times to rule out a flaky single press, then use Reset test to clear the in-memory session before a fresh run.
For cross-checking against an operating-system workflow on the same machine, the companion guide How to Test Mouse Buttons on Windows 11 walks through the Windows-level settings panel; together the two views tell you whether an unrecognised press is being absorbed before or after the browser layer.
Mapping the Five Button Codes
The page classifies every accepted event by integer code. The mapping follows the Web platform specification rather than assumptions about which physical side a button sits on.
| Code | Named label | Common physical button | What it usually does |
|---|---|---|---|
| 0 | Primary | Main activation button | Selects, activates, fires the default action |
| 1 | Auxiliary | Middle button or wheel click | Opens links in a new tab, pans in design tools |
| 2 | Secondary | Secondary activation button | Opens a context menu |
| 3 | Back | Side button (rear) | Browser history back, game-specific binding |
| 4 | Forward | Side button (front) | Browser history forward, game-specific binding |
| any other integer | Unknown (numeric) | Vendor-specific or remapped | Reported with its raw code, not forced into a known name |
The point of the table is that Primary is defined by the Web model, not by your thumb. Operating-system settings can swap the physical left and right roles, after which the page still reports 0 as Primary because that is the main activation button according to the browser. The same principle applies to extra buttons: a side button that fires browser history navigation may never reach the page at all, because the browser itself consumes that event before any page listener runs. The mapping follows the Web specification described in MDN's MouseEvent.button reference and W3C Pointer Events — the button property.
When a Button Count Stays at Zero
A zero for any named label after a deliberate press is a useful signal, but it is not a hardware diagnosis. It tells you only that an event with the expected MouseEvent.button code did not reach this page during the test. There are several layers above the physical switch that can absorb the press before it becomes a page event:
- Browser navigation — back and forward buttons are commonly handled by the browser itself and never reach the page.
- Extensions and accessibility software — input remappers and assistive tools may consume or rewrite events before the listener runs.
- Driver and operating-system settings — vendor software can reassign buttons, disable extra inputs, or hand them off to system shortcuts.
- Remote-desktop and virtualisation layers — these can change which integer code arrives at the listener, sometimes producing an Unknown numeric instead of the expected label.
Because each of these layers sits above the page, preventing default behaviour inside the target only suppresses the small set of in-page defaults the browser would otherwise run. It cannot override higher-priority system handling. To move past a zero result, repeat the test in the actual application where the problem appears, and compare with manufacturer software where you can confirm which physical switch the device believes it pressed. A single zero in one browser tab is evidence about the page, not the hardware.
What Mouse Tester Does Not Measure
The page is honest about what falls outside its scope. The following are not part of the contract, and a web page cannot measure them without privileged access to the device:
| Category | What it would require | Why a browser page cannot do it |
|---|---|---|
| Click latency in milliseconds | Synchronised hardware timestamps before and after the page | The page has no access to the physical switch moment |
| Polling rate | Raw HID reports or vendor diagnostics | Browsers expose synthesised events, not raw reports |
| Debounce or chatter | High-resolution event recording over time | Pages observe discrete events, not switch vibration |
| Wireless transport delay | Receiver-side timing or firmware tools | The radio path is invisible to web pages |
| Click speed (CPS) | Time-stamped click pairs | Belongs on a dedicated click-speed page |
| Scroll-wheel deltas | Wheel event sampling | Different event family, different test page |
Each of those measurements belongs in a different tool with a different contract. Treating this page as if it could certify hardware condition, game suitability, or wireless latency would misrepresent what it actually does. The reliable contract is narrower: interpret MouseEvent.button codes that reach the target, count those events transparently, retain a short recent list, and warn clearly when software has intercepted a press before the page saw it.
Reading the Recent List as a Signal
Because the page keeps only the latest eight accepted labels, the Recent list doubles as a quick integrity check. If your intended sequence was Primary, Secondary, Back, Forward and the Recent list shows Back, Back, Back, Back, you have just learned that either the browser is reissuing that single back press four times or the key is mechanically chattering. The list makes the order visible at a glance, which is more useful than a single running total when you are trying to spot a pattern.
When the recent list is empty after a deliberate press, that is the same signal as a count of zero: no matching event reached the target during the session. Treating the list as a short audit trail, rather than a permanent history, also matches the tool's real limits — refreshing the tab or selecting Reset test removes the in-memory state, and nothing is uploaded or saved anywhere outside the current page. Combining the Recent list, per-button counts, and a fresh Reset before retesting gives you a reproducible browser-only session you can describe to a vendor or compare across browsers without installing anything.