What DPI Testing Actually Measures
Mouse DPI (dots per inch) measures how many pixels the on-screen cursor moves for every inch the physical mouse travels across a surface. A mouse rated at 800 DPI moves the cursor 800 pixels per inch of hand movement, while a 1600 DPI mouse moves 1600 pixels in the same distance. This sensitivity value lives in the mouse firmware or in a companion software utility; Windows, macOS, and Linux do not expose it in any standard settings panel.
The number matters because it controls how the mouse feels in everyday use. Productivity tasks like spreadsheet editing often feel smoother at 800 to 1200 DPI, while first-person games typically use 400 to 1600 DPI for precise aiming. Before assuming a sensitivity problem is hardware-related, confirm the actual DPI the mouse is delivering, since operating system pointer acceleration or in-game sensitivity sliders can override the device's native value and make the cursor travel further or shorter than the sensor rating suggests.
Two Reliable Ways to Measure DPI
The two methods that work on any mouse are a ruler-based physical test and a read of the manufacturer's software. Each gives a slightly different answer, so understanding both helps you pick the right one for your situation.
Ruler and screen-distance method
Place a ruler or marked tape along your mousepad, set the mouse at the zero mark, and move it exactly one inch forward. Read how many pixels the cursor traveled on screen and divide by the inches moved to get effective DPI. A 1600 DPI mouse that has been doubled by Windows acceleration can show 3200 pixels of travel per inch, which is why this method measures the full operating system pipeline rather than just the sensor. For the cleanest result, disable pointer acceleration first, use a straight-line motion rather than a curve, and average three readings. This is the only method that works on mice without companion software or on-board memory, and it remains the standard for verification.
Manufacturer software
Logitech G Hub, Razer Synapse, Corsair iCUE, SteelSeries GG, and similar utilities display the active DPI stage the firmware is using. Open the software, select the active profile, and read the value. This is faster than the ruler method but only works for mice the software recognizes, and it tells you the sensor's reported value rather than the cursor travel the operating system actually delivers. The two methods should agree within a small tolerance when pointer acceleration is disabled.
Why Button Verification Belongs in a Mouse Diagnostic
A sensitivity test that misses clicks, fires twice, or ignores the back and forward buttons is hard to trust. Before running any DPI measurement, a quick check that every button on the device actually reaches the application where you will be testing is worth the extra minute. This is exactly where Mouse Tester fits in: it does not measure DPI, but it confirms which button codes the browser receives from each physical switch.
Mouse Tester listens for MouseEvent.button codes delivered to a single on-page target. It increments a total count, shows one named counter per Web specification code, and keeps the latest eight button labels in the order they arrived. The page suppresses its own context menu and auxiliary activation so that a middle-click or right-click inside the test area does not open a browser menu and wipe the result. Used together with a DPI method, button verification catches a common class of false alarms: a user who thinks their mouse DPI has changed is sometimes seeing a failing side switch or a wheel button that no longer fires. Confirming button health first makes the DPI result easier to interpret and rules out click registration as the real problem.
How to Verify Every Button with Mouse Tester
- Open Mouse Tester in a fresh browser tab and let the dashed target load fully.
- Move the pointer inside the dashed area and keep it there for the rest of the test so every press is delivered to the same target.
- Press the primary button once and watch the total counter and the Primary named count each rise by one.
- Press the secondary button once and confirm the Secondary named count increments without the browser context menu appearing.
- Press the auxiliary button, which is typically the wheel click, and confirm the Auxiliary named count increases while the page does not scroll or trigger autoscroll.
- If your mouse has extra side buttons, press the back and forward buttons one at a time and confirm their named counts rise in the same order.
- Check the Recent list to confirm the order of the last eight labels matches the order you pressed them, since out-of-order delivery can indicate event remapping.
- Repeat any button several times to make sure each press produces exactly one increment and no double counts.
- Open the same Mouse Tester page inside the application where you suspected a problem, for example alongside your game or design tool, and rerun the press sequence to compare.
- Click Reset test to clear the in-memory session when you want to start over.
Reading the Five MouseEvent.button Codes
The Web specification defines exactly five named integer codes for mousedown events, and Mouse Tester labels them so the result is readable without remembering the mapping. The full reference is published on MDN's MouseEvent.button page.
| Code | Label | Typical physical button |
|---|---|---|
| 0 | Primary | Main activation button (often left, but OS-swappable) |
| 1 | Auxiliary | Middle button or wheel click |
| 2 | Secondary | Secondary activation button (often right, but OS-swappable) |
| 3 | Back | Side navigation back button when the browser exposes it |
| 4 | Forward | Side navigation forward button when the browser exposes it |
Any other integer code that reaches the page is labeled Unknown with its numeric value rather than forced into a known name, and fractional codes are rejected because the specification uses integers. The named mapping is deliberately the Web event model rather than physical position, so a right-handed user with a left-handed operating-system swap still sees code 0 register as Primary. The named mapping contains exactly five unique keys and five unique labels, and an independent fixture covering codes 0 through 4 plus negative, next-range, and large unknown values prevents a shifted mapping from passing its own checks.
When Zero Counts Do Not Mean a Broken Switch
Software sits between the physical switch and the page. A zero count for a specific named label means no matching event reached the test area during the session, which is a different statement than the switch being broken.
Common reasons a button fails to register in the browser include the operating system intercepting extra side buttons, browser extensions remapping input, accessibility software synthesizing events, remote-desktop tools altering codes, and game or application overlays capturing the click before it reaches the page. Back and forward buttons are especially likely to be claimed by browser history navigation before Mouse Tester can see them. Preventing default behavior on the test target reduces accidental actions but cannot override higher-priority browser or system handling.
To rule out interception, run the test in a fresh private browsing window with extensions disabled, and repeat the press sequence in the application where you noticed the original problem. If a button produces multiple events on a single press, cross-check with the Double Click Test or with your mouse manufacturer's diagnostic software. Mouse Tester reports browser events only and cannot certify hardware condition, polling rate, debounce timing, or wireless latency, so treat one browser session as a useful sanity check rather than a repair diagnosis. All counts remain in the current tab and are cleared by refreshing, closing the page, or selecting Reset test, so no data leaves the device.