Mouse Test

Diagnose double-click failure, dead buttons, and worn scroll wheels

A free online mouse click test, mouse click tester, polling rate (Hz) check, latency comparison, and DPI / sensitivity helper in one page. Click left, right, middle, and side buttons, spin the scroll wheel, and watch each region of the mouse illustration light up in real time. No download, no account, no install — everything runs locally in your browser using the standard MouseEvent and WheelEvent APIs.

This is a hardware mouse tester rather than a "mouse click test program" you install on Windows — the entire flow runs in the browser tab and works the same on Mac, Windows, Linux, and ChromeOS. If you've used desktop tools like MouseTester, MouseChecker, or MouseAccuracy, the goals overlap; the trade-offs are covered in the Online Mouse Tester vs Desktop Apps section below.

Get Easily Started With Your Test

1. Click every button on your mouse and check that the matching region lights up on the mouse illustration.
2. Point your cursor at the illustration and spin the scroll wheel up and down.
3. Check that the arrows on the illustration also light up as you scroll.

If all the relevant buttons on your physical mouse light up, your clicks are being registered correctly and the mouse is working.

Why Test Your Mouse Online

A mouse that clicks today can fail tomorrow. Micro-switches under the left and right buttons are rated for 10–50 million clicks depending on the grade — once they start to wear, double-clicks appear on single clicks, clicks register late, or the button stops registering entirely. Scroll wheels develop dead zones. Side buttons are the hardest to test because most applications do not use them, so you can go months before noticing they have failed.

This tester exposes exactly what the browser is receiving from the OS. The page listens for mousedown, mouseup, dblclick, wheel, and contextmenu events on the window, reading the MouseEvent.button, MouseEvent.buttons, and WheelEvent.deltaY values the browser exposes. Each matching region on the SVG mouse illustration is filled in the moment the event fires, so you can see both the click and any missed or phantom registration.

Common reasons to run a mouse test:

• Pre-purchase inspection — verify every button on a second-hand mouse before buying or immediately after delivery
• Post-repair verification — confirm a switch replacement or solder job actually restored the button
• Diagnosing double-click failure — worn micro-switches register two mousedown events from a single physical press
• Testing side buttons 4 and 5 — the hardest buttons to verify in everyday software
• Scroll wheel dead zone check — confirm the encoder wheel registers both directions through the full rotation
• RMA documentation — gather clear evidence of a failing button before a warranty claim
• Gaming readiness — confirm primary and side buttons register reliably before a competitive session

How to Test Your Mouse in 3 Simple Steps

Step 1: Open the tester in a modern browser

Use Chrome, Firefox, Edge, or Safari on a recent version. The MouseEvent interface has been stable in every major browser since 2015, but side-button support and precise WheelEvent.deltaY reporting only work in Chrome 49+, Firefox 52+, Safari 10.1+, and Edge 14+. On older browsers, left, right, and middle clicks will still register, but the side buttons and high-precision wheel deltas may not.

No browser extension or permission prompt is required. The page only listens for mouse events fired into the browser window — it does not and cannot read input outside the tab.

Step 2: Click every button and spin the wheel

Click the tester area with each of the five standard mouse buttons one at a time:

• Button 1 (left click) — the primary button; should light the upper-left region of the illustration
• Button 2 (middle click) — press the scroll wheel straight down; should light the narrow central strip
• Button 3 (right click) — the secondary button; should light the upper-right region (the browser context menu is suppressed on the illustration so the test can see the event)
• Button 4 (side button — back) — typically used as "back" in web browsers; should light the upper side-button region
• Button 5 (side button — forward) — typically used as "forward"; should light the lower side-button region

Then hover over the illustration and scroll the wheel up and down. The corresponding arrow should highlight for each direction. If you have a tilt-wheel mouse, horizontal scroll events are also captured and shown in the live status panel.

Step 3: Review the results

Every button you pressed should have marked its region as tested (green). Every region that is still at rest colour has not yet registered an event. A full pass means:

• All five button regions turned green
• Both scroll arrows turned green
• No region fired without you pressing the matching button (a false positive points to a stuck or bouncing switch)

If a button does not register, try pressing it 20–30 times in quick succession. An intermittent result (registers some of the time) usually indicates a worn switch contact rather than a fully failed one, and is the most common way mice degrade before full failure.

What the Mouse Tester Checks

The five standard mouse buttons

The MouseEvent.button property identifies which button triggered an event:

• 0 — left (primary) button — maps to the mouse-1 region
• 1 — middle button (wheel click) — maps to the mouse-3 region
• 2 — right (secondary) button — maps to the mouse-2 region
• 3 — fourth button, typically "back" — maps to the mouse-4 region
• 4 — fifth button, typically "forward" — maps to the mouse-5 region

The MouseEvent.buttons property is a separate bitmask that reports every button currently held, not just the one that triggered the event. Bit 0 = left, bit 1 = right, bit 2 = middle, bit 3 = back, bit 4 = forward. This tester reads both values so you can confirm multi-button chords are being registered correctly.

On unconventional layouts — vertical mice, trackballs, or programmable gaming mice with additional thumb buttons — the number-to-position mapping may differ from a standard two-button-plus-side-button design. What matters for hardware testing is that pressing any button produces an event with the expected button value.

The scroll wheel (both directions)

The browser fires a wheel event whenever the scroll wheel rotates. The deltaY property is negative when the wheel scrolls up and positive when it scrolls down. This tester captures both directions and highlights the matching arrow on the illustration.

Precision mice with a free-spinning or high-resolution wheel fire many more events per revolution (often with fractional deltaY values) than budget mice with a stepped wheel. The scroll distance counter sums the absolute delta across every wheel event, so you can quantify how much scrolling a single flick produces — useful for comparing two mice side-by-side or confirming a wheel encoder is working smoothly.

If the wheel produces no events at all, the rotary encoder inside the mouse is probably failed or the ribbon cable to the scroll wheel board has come loose. Both are common after a few years of heavy use.

Double-click detection

The browser fires a dblclick event automatically when two mousedown/mouseup cycles happen on the same element within the OS double-click interval (typically 500 ms on Windows, configurable in Control Panel > Mouse > Buttons). This tester counts dblclick events separately from regular clicks, so you can verify:

• Intentional double-clicks — rapid click-click on the left button increments the double-click counter once per pair
• Unintentional double-clicks — a worn left-click switch that bounces will generate a dblclick from a single physical press; if the double-click counter climbs faster than you intended, the switch is failing

Chrome and Firefox apply slightly different timing and location thresholds for dblclick, but in both, the second click must land close to the first to qualify. A moving cursor will produce two single clicks rather than one double-click.

Right-click and the context menu

By default the browser opens a context menu on right-click. This tester calls preventDefault() on contextmenu events fired inside the mouse illustration so the right-click can be tested without the menu appearing. Outside the illustration the normal right-click menu still works.

If right-click does not register even with the context menu suppressed, the physical right-click micro-switch is failed or its cable trace is broken. On many budget mice the right-switch fails before the left, because it sees less use and develops contact corrosion.

Middle-click and wheel-click crosstalk

The wheel on most mice is a dual-purpose component: rotating it fires wheel events, and pressing it down fires a mousedown with button === 1. On ageing mice it is common for the wheel to fire a wheel event every time you press it down, because the encoder picks up a small rotation as the wheel depresses. This tester shows both the middle-click region and the wheel arrows, so you can see crosstalk directly: a press that should only light the middle button but also briefly lights the up or down arrow indicates the wheel mechanism is worn or misaligned.

Mouse click test (mouse click tester)

A mouse click test answers a single question: when you press a button, does the OS register exactly one event in the right place, every time? The page above turns that into a visual loop — click, watch the matching region light up, repeat — so a worn switch reveals itself as either a missed press, a duplicated press, or an unrelated region firing.

Use it as a structured mouse click tester:

1. Single-click each button 20 times — left, right, middle, side back, side forward. The total-clicks counter on the live panel should rise by exactly 20 each time, and the corresponding region should light blue on every press and turn green when released.
2. Watch the double-click counter while you single-click — if it goes up without you intending a double-click, the left-switch is bouncing. This is the classic early-stage symptom of switch wear, and the most reliable thing this tester catches that desktop click-counters miss.
3. Test mouse click while moving the cursor — a click during a drag should still register. Some failing switches register fine while stationary but drop events when stress is applied to the shell.
4. Test mouse clicker scripts cautiously — autoclicker tools fire mousedown events through the OS that look identical to real clicks, so if you want to test mouse clicking under sustained load (e.g. for streaming or competitive play), an autoclicker hammering the page will show whether the OS, browser, or mouse is the bottleneck. The tester counts each event regardless of source.

If you've used a Windows-only "mouse click test program" before — desktop tools like MouseTester, MouseAccuracy, or PassMark MouseCheck — the click-counting flow here gives you the same signal without an install.

Mouse polling rate test (mouse Hz test)

Polling rate (also written "mouse Hz") is how often the mouse reports its state to the host: 125 Hz once per 8 ms, 500 Hz once per 2 ms, 1000 Hz once per ms, or 4000–8000 Hz on flagship gaming mice. The browser cannot read the raw HID report cadence directly, but it can give you a rough estimate from mousemove event timing — useful for spotting whether your mouse is running at the rate you think it is.

Quick mouse Hz test inside this page

1. Open the page and click anywhere to focus.
2. Move the cursor in a slow circle for 5–10 seconds.
3. Open your browser's DevTools (F12) → Performance tab → record while moving.
4. Stop the recording and look at the gap between consecutive mousemove events.

Approximate event spacing maps to polling rate:

• ~8 ms between events → ~125 Hz
• ~4 ms → ~250 Hz
• ~2 ms → ~500 Hz
• ~1 ms → ~1000 Hz
• Sub-1 ms → ≥1000 Hz (browsers throttle to roughly the screen refresh rate when many events queue, so 4000 Hz mice often appear as ~1000 Hz in mousemove)

This is an indicative mouse polling rate test, not an authoritative one. A purpose-built tool — Wooting's Mouse Tester, Microsoft Mouse Rate Checker, or Linux's evtest — reads raw HID timing and is the right answer for hard numbers. The browser-side flow above is enough to confirm whether a 1000 Hz mouse is actually running at that rate, or whether something (a USB hub, vendor software, or a damaged cable) is pushing it back to 125 Hz.

Mouse latency test in the browser

A mouse latency test measures the delay between physical click and event delivery. The browser exposes high-resolution event.timeStamp values on every mousedown, so a comparative latency test (mouse A vs mouse B on the same machine, same browser, same USB port) is feasible — even though absolute end-to-end latency requires hardware tooling.

How to run a comparative mouse latency test here

1. With the first mouse, click the left button 50 times at a steady cadence (one click per second is comfortable). The total-clicks counter increments on each press; the live panel shows the most recent timestamp.
2. Plug in the second mouse and repeat — same port, same cadence, same hand.
3. Compare the responsiveness feel alongside the totals. The mouse with consistently faster on-screen feedback after the physical click is the lower-latency one for click events.

Typical mouse click latency by transport

• Wired USB at 1000 Hz — 1–3 ms click-to-event
• Wired USB at 125 Hz — 4–8 ms
• 2.4 GHz wireless dongle (Logitech Lightspeed, Razer HyperSpeed) — 1–3 ms
• Bluetooth 5.x mouse — 8–15 ms typical, 20–30 ms under interference
• Bluetooth Low Energy mouse — 15–30+ ms

If a single mouse measures noticeably outside its expected band — e.g. a 1000 Hz wired mouse feeling like 30 ms — the bottleneck is usually a USB hub, a USB 3.0 port radiating 2.4 GHz noise that interferes with a wireless dongle plugged in nearby, or Windows USB selective suspend kicking in. Plug the mouse directly into a motherboard USB 2.0 port and rerun the test.

What a browser-based latency test mouse flow can't see

The browser sees events only after the OS has scheduled them. It cannot break "click latency" into "switch debounce + USB poll + OS dispatch + JS event". For absolute numbers — the kind reviewers quote — a high-speed camera aimed at the LED on a modded mouse remains the gold standard, and tools like Nvidia LDAT include click input on top. Use the browser-based latency test mouse flow here for relative comparisons; treat the numbers as ranks, not absolutes.

Mouse DPI tester and sensitivity test

DPI (dots-per-inch — also called CPI, counts-per-inch) is how many pixels of cursor movement the OS receives per inch of physical mouse travel. A mouse sensitivity test verifies that the DPI your mouse advertises is the DPI your OS actually receives, and that it stays consistent across the mousepad.

Quick mouse DPI tester procedure

You can verify DPI with this page plus a ruler:

1. Set your OS pointer speed to a known multiplier — Windows: Settings → Mouse → Mouse pointer speed at the default centre tick (this is a 1:1 multiplier in Windows 11). On macOS, set tracking speed to the lowest setting and disable "Pointer acceleration" via Terminal (defaults write .GlobalPreferences com.apple.mouse.scaling -1).
2. Place the cursor on the left side of a horizontal ruler line, with the page open.
3. Move the mouse exactly one inch (25.4 mm) to the right on the mousepad without lifting.
4. Read how many pixels the cursor moved. Open DevTools (F12) → Console and run let x = 0; addEventListener('mousemove', e => x += e.movementX); console.log(x) before the test, then console.log(x) afterwards to read the total movementX.
5. The total should match your set DPI. A 1600 DPI mouse should produce ~1600 pixels of movementX for one inch of travel; a 400 DPI mouse should produce ~400.

Outside ±5%, the mouse is reporting a different DPI than its software claims — common on cheaper mice without true on-board DPI selection, and on gaming mice where the active profile differs from what the LCD on the mouse shows.

Mouse sensitivity test (in-game vs OS)

In-game sensitivity is a multiplier on top of DPI. A mouse sensitivity test for gaming usually means an "eDPI" calculation: eDPI = DPI × in-game sensitivity. Two players with the same eDPI move the in-game crosshair the same physical distance per inch of mouse travel. This page can confirm the DPI half of that equation; the in-game sensitivity half has to be set inside the game.

What this tester can and can't do for DPI

The tester reads mousemove.movementX and movementY after Windows/macOS pointer-acceleration curves have already been applied, which is why you have to disable pointer acceleration before measuring. With acceleration disabled the values map cleanly to raw DPI; with it enabled the math doesn't work. For raw HID-level DPI verification independent of the OS, use a vendor utility like Logitech G Hub's "DPI test" or a hardware tool like an optical sensor analyser.

Troubleshooting Common Mouse Problems

Button does not register at all

The most common reasons a mouse button produces no event:

1. Cable or receiver connection — unplug the USB cable and plug it into a different port directly on the computer. Avoid hubs. For wireless mice, re-pair the dongle and check the battery.
2. Failed micro-switch — Omron, Kailh, and Huano switches are rated for tens of millions of clicks but can fail earlier after liquid exposure, static discharge, or heavy daily use. A failed switch typically registers 0% of the time, where an ageing switch registers intermittently.
3. Broken trace or solder joint — side buttons in particular are often connected by thin ribbon cables that can crack after repeated mouse lifts. If one side button fails cleanly while the other works, a cable is the most likely cause.
4. Driver intercept — Logitech G Hub, Razer Synapse, Corsair iCUE, and similar utilities can remap or disable buttons. Temporarily disable the vendor software and retest to rule out a software remap.
5. OS-level setting — Windows' Settings > Bluetooth & devices > Mouse > Additional mouse settings lets you swap primary and secondary buttons. A swapped setting can make it look like the left click is failing when in fact it is being reported as button 2.

Double-click on single press

If the double-click counter increments when you only meant to click once, the left-click micro-switch is bouncing — the contact is making and breaking multiple times during a single physical actuation. This is almost always mechanical wear inside the switch. Three fixes from cheapest to most permanent:

• OS debounce tuning — Windows and macOS do not expose a per-mouse debounce setting, but some vendor utilities (Logitech Options+, Razer Synapse) include a "click debounce" timeout. Raising it to 8–12 ms masks most switch bounce at the cost of slower registered double-clicks.
• Switch cleaning — a few drops of contact cleaner (not WD-40, which leaves residue) into the switch followed by 100 rapid click cycles can break up contact oxidation and restore reliable actuation for another few months.
• Switch replacement — the permanent fix. Most mice use standard Omron D2F or Kailh GM series switches that can be desoldered and replaced for about $1 each. A few higher-end mice (Logitech G Pro X Superlight, Razer DeathAdder V3) use optical switches that do not bounce and are not user-replaceable, but also do not wear out.

Scroll wheel skips or drops events

A wheel that scrolls erratically — registering up when you scrolled down, or skipping several steps — usually has a dirty rotary encoder. Opening the mouse, removing the wheel assembly, and cleaning the encoder wheel contacts with isopropyl alcohol restores most wheels. If cleaning does not help, the encoder itself has worn out and needs replacement.

A wheel that produces no events in only one direction is almost always an encoder issue rather than a switch, because the direction is determined by the phase of the two encoder signals. Replacing the encoder module is the fix.

Cursor jitter or stuck cursor

Cursor movement is handled separately from click events — this tester does not directly measure cursor tracking, but jitter or sticking usually indicates a dirty sensor or a failing USB connection. Try:

• Clean the sensor with a soft, dry cloth or compressed air
• Try the mouse on a different surface; glass and reflective surfaces can confuse optical sensors
• Replace the USB cable or receiver — internal cable breaks inside the mouse shell are common after a few years
• Check for firmware updates from the mouse vendor; sensor calibration fixes are pushed regularly

Side buttons not recognised in some applications

Not every application listens for the 4th and 5th buttons. Web browsers map them to back/forward by default, but a text editor or game may ignore them entirely. If the side buttons register correctly in this tester but not in your target application, the problem is in the application, not the mouse. Map the buttons to keyboard shortcuts using the vendor utility or a general-purpose tool like X-Mouse Button Control on Windows or Karabiner-Elements on macOS.

Mouse Testing on Different Operating Systems

Windows

Windows exposes the full five-button layout through the HID driver. All MouseEvent.button values 0–4 should be reported by the browser with no additional configuration. A couple of Windows-specific things to verify if side buttons are not registering:

• Swap left/right — Settings > Mouse > Primary mouse button. If set to "Right," the OS swaps button 0 and button 2 before the browser sees them, which can look like a failed left-click.
• ClickLock — Control Panel > Mouse > Buttons > "Turn on ClickLock." When enabled, holding a button briefly acts as a drag-lock. This can interfere with mousedown/mouseup symmetry in the tester.
• Gaming mouse profile — many gaming mice store their active profile on the hardware. If a profile has disabled or remapped buttons, the OS sees the remapped event. Check the vendor software for the active profile.

macOS

macOS traditionally shipped with single-button mice, but modern Macs fully support the five-button layout when paired with a standard USB or Bluetooth mouse. A few platform-specific notes:

• Secondary click — System Settings > Mouse > "Secondary click" must be enabled for right-click to register in the browser at all. With it off, the browser only sees button === 0 events.
• Mission Control bindings — system shortcuts can intercept middle-click and side-button presses before the browser receives them. Disable the relevant shortcut in System Settings > Keyboard > Keyboard Shortcuts > Mission Control to get the raw event through.
• Scroll wheel direction — "Natural scrolling" in System Settings > Mouse inverts deltaY relative to the default. The tester highlights the arrow matching the direction of your finger motion on the wheel, not the content scroll direction.

Linux and ChromeOS

X11 and Wayland both expose the standard HID mouse interface through libinput. All five buttons work out of the box. On ChromeOS, enable "Developer mode" if you need to use vendor utilities, but the browser itself reads mouse events through the same interfaces as Windows and macOS.

Online Mouse Tester vs Desktop Apps

Desktop mouse testing tools exist — PassMark's MouseCheck, KeyboardTest, manufacturer utilities like Logitech Options+, and low-level HID inspectors like USBlyzer. Each has trade-offs versus an online tester.

Online tester advantages:

• No installation or admin rights required
• Works the same on Windows, macOS, Linux, ChromeOS
• Tests the full input stack from hardware through OS through browser — the same path every web application relies on
• Cannot be confused by conflicting driver software because the browser sits above the driver layer
• Accessible on any computer, including a borrowed machine

Desktop tool advantages:

• Can read raw HID reports to show polling rate, scan rate, and sub-millisecond timing
• Can capture button combinations that browsers suppress (for example, some OS shortcuts like Windows Win+click)
• Can test button debounce behaviour directly rather than inferring it from dblclick events
• Keep working without a network connection and without depending on browser event timing

For the common cases — confirming a button fires, diagnosing double-click failure, verifying the wheel works in both directions, checking side buttons — an online tester is faster and requires nothing to install. For polling-rate measurement or low-level switch debounce analysis, a desktop HID inspector is more appropriate.

Frequently Asked Questions

Does this mouse tester work with any mouse?

It works with any mouse the operating system recognises as a standard USB HID or Bluetooth HID input device. That covers wired USB mice, wireless 2.4 GHz RF mice with a USB dongle, and Bluetooth mice. Gaming mice with programmable buttons, vertical ergonomic mice, trackballs, and built-in laptop trackpads all work without extra configuration.

The only hard limitation is browser support for side buttons. Chrome 49+, Firefox 52+, Safari 10.1+, and Edge 14+ all report MouseEvent.button values 3 and 4 for the side buttons. Older browsers will still register the three primary buttons and the wheel, but side-button presses will silently do nothing.

What mouse buttons can be tested with this tester?

Five buttons plus the scroll wheel:

• Button 1 — left (primary) click
• Button 2 — middle click (pressing the scroll wheel down)
• Button 3 — right (secondary) click
• Button 4 — side button, typically "back" in web browsers
• Button 5 — side button, typically "forward" in web browsers
• Scroll wheel — rotation in both directions, with optional horizontal scroll on tilt-wheel mice

Mice with extra programmable buttons (6th, 7th, sniper buttons) can still be tested here — each extra button will fire with its own button value, visible in the live status panel, even if there is no region on the illustration for it.

Why do some clicks not register in the browser?

A few specific clicks are intercepted at the OS level before the browser sees them:

• Right-click on the desktop/taskbar — when the pointer is outside the browser window, the OS context menu opens, not the browser's. The tester only captures events inside the browser window.
• Three-finger tap and other trackpad gestures — these are handled by the OS trackpad driver and do not produce MouseEvent instances in the browser.
• Wheel click in Chrome while scrolling is active — Chrome's auto-scroll cursor can briefly suppress button === 1 events while active. Press Esc to cancel auto-scroll.

These are OS and browser design decisions, not mouse faults. The physical button is working correctly even if the event does not reach this tester.

Does this test work on all browsers?

The core MouseEvent and WheelEvent APIs are supported in every modern browser — Chrome, Firefox, Safari, Edge, Opera, Brave — back several years. For the best results, including side-button and precise-wheel-delta reporting, use a current version of Chrome or Firefox.

Internet Explorer and legacy Edge (pre-Chromium) fire events in a slightly different format and may not register side buttons. If you are testing on one of these browsers, the left, right, and middle buttons will still register but side-button presses may go unreported.

How do I test for mouse double-click failure?

Open the tester and rapidly click the left button once. Watch the "Double clicks" counter at the bottom of the live panel. A single physical press should never increment the double-click counter — if it does, your left-click switch is bouncing, which is the first stage of classic double-click failure.

To rule out accidental fast-pressing, space your clicks at least 600 ms apart (two full seconds is comfortable). The OS double-click window is typically 500 ms, so anything slower than that cannot be counted as a double-click by the browser.

Why is the scroll arrow lighting even when I did not scroll?

The most common cause is accidental wheel rotation when pressing the middle button — the wheel encoder picks up the small angular movement as you depress it, firing a wheel event alongside the middle-button mousedown. This is a well-known symptom of a worn middle-click mechanism. Some mice (Logitech MX Master, Razer Basilisk) have stiffer middle-click return springs to minimise this crosstalk, but it appears on most mice after a few years of use.

Is my mouse data sent to any server?

No. This tester processes every event locally inside your browser tab using JavaScript. Mouse event data is never transmitted, stored, or shared with any third party. The MouseEvent and WheelEvent objects are read by the page's JavaScript, used to update the visual state, and discarded. You can confirm this by opening your browser's developer tools (F12 > Network tab) while using the tester — no outgoing requests will be triggered by your clicks.

Can I run a mouse polling rate test (mouse Hz test) here?

Yes, indirectly. The browser doesn't read raw USB HID timing, but the gap between consecutive mousemove events tracks polling rate closely enough to tell whether your 1000 Hz mouse is actually running at that rate. The full procedure is in the Mouse polling rate test (mouse Hz test) section above. For absolute polling rate numbers, a dedicated tool — Wooting Mouse Tester, MouseTester on Windows, or evtest on Linux — reads raw HID reports and is the right choice.

Can this tester run a mouse latency test?

Yes, comparatively. The page records a timestamp for every mousedown, so you can compare two mice on the same machine and same port and tell which one is consistently faster. The full flow is in the Mouse latency test in the browser section. Absolute click latency — physical actuation to OS event — is not measurable from JavaScript because the timestamp arrives after OS scheduling. For absolute numbers, a high-speed camera, Nvidia LDAT with click input, or an LED-on-pad rig is the gold standard.

Is this a mouse click test program I need to install?

No. It's a browser-based mouse click tester — open the page and start clicking, no install or admin rights needed. Desktop mouse click test programs (PassMark MouseCheck, MouseTester, MouseAccuracy) overlap with what this tester does, and a desktop tool can read raw HID reports the browser cannot. For everyday "is this button working / is it double-clicking" diagnosis, the browser flow is faster and works on Mac, Windows, Linux, and ChromeOS without changing tools.

Can I use this as a mouse DPI tester or sensitivity test?

Yes, with one caveat: you have to disable Windows / macOS pointer acceleration first, because the browser sees movementX / movementY after the OS curve. With acceleration off, you can confirm a mouse's actual DPI matches what its software advertises by sliding the mouse exactly one inch and reading the total movementX. Full procedure in the Mouse DPI tester and sensitivity test section above. For raw HID-level DPI verification independent of OS settings, a vendor utility (Logitech G Hub, Razer Synapse) is more accurate.

Can autoclickers (test mouse clicker tools) be tested here?

Yes. An autoclicker injects mousedown / mouseup events through the OS that look identical to physical clicks, so a "test mouse clicker" run will increment the same counters and light the same regions. This is useful for confirming an autoclicker is firing at the rate it claims, or for stress-testing whether your mouse, OS, or browser drops events at high click rates. The tester counts each event regardless of source.

Related Testing Tools

If you are testing other input hardware alongside your mouse, these tools use the same browser-based approach — no downloads, no accounts, everything processed locally:

• Keyboard Test — Test every key on your keyboard, detect stuck keys, verify NKRO rollover, and see KeyboardEvent.code / KeyboardEvent.key values in real time.
• PS4 Controller Test — Test DualShock 4 buttons, analog sticks, triggers, and vibration via the HTML5 Gamepad API.
• PS5 Controller Test — Test the DualSense controller including all face buttons, triggers, touchpad, and haptic feedback detection.
• Xbox Controller Test — Test Xbox One, Xbox Series X/S, and Xbox 360 controllers across all buttons, bumpers, triggers, and thumbsticks.

When to Use Multiple Input Testers

If you use a mouse and keyboard together — which is almost every desktop setup — testing both before an important session confirms your entire input chain is functioning. Mouse and keyboard events flow through different browser APIs (MouseEvent and WheelEvent vs KeyboardEvent) and different OS driver stacks, so a problem with one does not necessarily mean a problem with the other. Running both tests takes a couple of minutes and catches most input-layer issues before they interrupt a deadline.