Mouse Polling Rate & Input Lag Tester

What mouse polling rate means for gaming

Polling rate is how often your mouse reports its position to the operating system, expressed in Hz (reports per second). A 1000 Hz mouse sends 1,000 position updates every second, or one every 1 ms. A 4000 Hz mouse sends 4,000 updates, or one every 0.25 ms. The higher the rate, the more precisely the cursor tracks micro-movements, and the lower the maximum latency between a physical movement and a screen update.¹

For competitive gaming, polling rate affects aim consistency more than raw accuracy. At 125 Hz the cursor can be up to 8 ms behind the physical mouse; at 4000 Hz that maximum gap is 0.25 ms. In controlled testing, higher polling rates reduced jitter, but the perceptual threshold landed around 2000 Hz rather than a universal jump from 500 Hz to 1000 Hz.²

The shape of the chart tells you which stage to fix first. A flat line pinned at 1000 Hz on a mouse configured for 8000 Hz points to the configured rate not reaching the browser, which is usually pointer-event coalescing rather than a hardware limit. A jagged line near the expected rate instead points to USB bandwidth contention or power management delaying reports, so the fix sits on the connection path rather than in the mouse settings. Tracking that difference across a full 30 second sample separates a consistent scheduling problem from random background noise.

How to read the scrolling Hz chart

The chart shows the last 600 Hz samples as a rolling polyline. The X axis is time (left = oldest, right = most recent) and the Y axis is polling rate in Hz, auto-scaled to the next standard polling tier above your current maximum. A perfectly stable 1000 Hz mouse produces a flat line near the top of a 1000 Hz scale, while a 4000 Hz mouse on the 4000 Hz scale looks similar but sits higher on its own scale. The live metrics above the chart show the current, average, and maximum Hz alongside the longest gap between events in milliseconds.

Reading stable versus unstable signals

Vertical red lines mark polling dropouts, which are moments when the gap between two events exceeded 8 ms (equivalent to fewer than 125 Hz).⁵ Occasional red marks are normal during bursts of very fast movement when the input pipeline coalesces events.³ Persistent red marks indicate a real problem: USB bandwidth contention, a failing cable, or power management throttling the USB port.

High variance (jagged line) on a 1000 Hz mouse usually means the mouse is sharing USB bandwidth with another high-frequency device on the same hub or root port. Connecting the mouse to a dedicated USB port on the motherboard typically smooths out the reading. If the line stays jagged after switching ports, try unplugging other USB devices one at a time to find the peripheral that is competing for bandwidth.

What this test measures, and what click latency is

One boundary is worth drawing before you mistake this chart for a click test. Everything here measures how often position reports arrive: the Hz numbers and the Longest Gap metric both describe the stream of movement data, and nothing on this page times a button press. Spanning switch travel, the debounce filter inside the mouse, and the whole input stack before the press registers as an event, click latency is a different quantity, and a proper measurement of it needs a test that times presses rather than movement. The distinction matters because a mouse can move beautifully and still feel late when you click.

For that question, the hand-off lives on the variant pages. The click latency test measures button response time with the same local-processing guarantee this page has, and the mouse debounce guide explains the software filter that trades double-click prevention against response time. Switch type completes the picture, because optical and mechanical switches affect which latency you feel on every click; the optical versus mechanical comparison covers that choice in depth. When a fast polling rate coexists with a click that still feels late, the two quantities deserve separate measurements. Start with the number, then adjust the one knob you control.

Why browsers cap PointerEvent delivery

Browsers do not deliver every hardware mouse event to JavaScript. The OS schedules input events on its own timer, then the browser coalesces rapid events to avoid flooding the main thread, which reduces event-handling work but also reduces the granularity available to ordinary listeners. Understanding this pipeline explains why a 4000 Hz mouse does not always produce a 4000 Hz reading in the browser. The gap between the hardware rating and the measured result is a useful diagnostic because it shows how much the operating system and browser are combining reports before your code runs.

How coalescing hides hardware reports

At the OS layer, Windows Raw Input documentation describes buffered reads for high-frequency mice at 1000 Hz, where multiple events can accumulate between message-loop iterations.⁶ Higher polling rates such as 2000 Hz, 4000 Hz, and 8000 Hz have been studied in gaming setups, and modern gaming-mouse sensors also advertise 8 kHz polling.² Those higher rates require the browser to support getCoalescedEvents(), which is a PointerEvents API extension that exposes the intermediate events the browser would otherwise merge.⁴ Without that extension, a fast mouse and a slow mouse can look identical to a normal event listener because the extra reports are hidden.

Display refresh rate sets the frame-time ceiling too: 60 Hz is 16.67 ms per frame, while 144 Hz is 6.94 ms.⁷ This tool calls getCoalescedEvents() on every dispatch, so a 4000 Hz mouse should read close to 4000 Hz in browsers that support the API. A reading lower than the advertised rate can reflect the OS, USB, driver, firmware, or browser pipeline coalescing reports before JavaScript sees them. In practice, the most common culprits are USB power management and a shared root hub, both of which are fixable without replacing the mouse.

How to improve your polling rate reading

If you are getting a lower reading than your mouse's advertised polling rate, the cause is almost always somewhere in the connection or the operating system rather than the sensor itself. Work through the following steps in order, retesting after each one, until the measured average gets close to the rated maximum.

Step-by-step troubleshooting

1. Plug into a dedicated motherboard USB port. Front-panel headers, USB hubs, and docking stations share bandwidth and introduce scheduling jitter. Use a rear port directly on the motherboard's USB controller.
2. Remove other USB devices from the same root hub. High-frequency keyboards, headsets, and other peripherals compete for the same USB polling slot. Verify by temporarily unplugging them and re-running the test.
3. Update mouse firmware. Firmware updates can fix bugs or add device functions, so check your mouse software for an update option before assuming the sensor is at fault.⁹
4. Disable OS mouse acceleration. Enhanced pointer precision (Windows) and mouse smoothing (macOS) filter input events before they reach applications, which can interfere with raw timestamp spacing. Use a direct-input or raw-input driver mode if your mouse software offers it.⁶
5. Review USB power settings. On Windows, check the USB selective suspend setting under Power Options; Windows enables selective suspend by default and can suspend idle ports.
6. Run the test as the only active application. Heavy CPU or GPU load causes OS scheduler delays that appear as polling rate drops. Close games, video, and background processes, then re-test.

Once the troubleshooting above has cleared the connection, the rate itself is a setting you can change. On software-configurable mice, the maker's configuration software exposes the polling rate alongside the other pointer settings, and you pick a tier from what the device supports.¹ Some mice also let you assign profiles that switch the rate automatically between uses, which is worth setting up before you blame the hardware for a number that changes on its own. Whatever you change, this page is the verifier: re-run the session after switching tiers and confirm the new average actually lands where the setting claims, because a profile that silently failed to apply is indistinguishable from a USB problem until you measure it.

Polling rate tiers and what each means for gaming

Mice ship with fixed polling rate tiers, and software-configurable mice let you choose between them. The standard tiers are 125 Hz, 250 Hz, 500 Hz, and 1000 Hz. Ultra-high-polling mice add 2000 Hz, 4000 Hz, and 8000 Hz options. Each tier halves the maximum latency gap between hardware position reports: at 125 Hz the cursor can lag up to 8 ms behind physical movement, at 1000 Hz that ceiling drops to 1 ms, and at 4000 Hz it falls to 0.25 ms. Your tester reading tells you which tier your system is actually delivering, which may differ from the mouse's advertised maximum depending on USB port assignment, driver settings, and power management configuration.

The practical benefit depends on your monitor's refresh rate and your own perceptual sensitivity. Running a 1000 Hz mouse on a 60 Hz monitor means the display updates slower than the mouse reports, so some of those reports never produce a visible frame update. At 144 Hz or 240 Hz the headroom narrows, and the difference between 500 Hz and 1000 Hz becomes more relevant during fast flick movements.⁷ Above 1000 Hz, diminishing returns set in for most players; controlled studies found higher polling rates reduce jitter, but pointing performance stayed unaffected up to about 1 ms of jitter.

CPU overhead is the trade-off for ultra-high polling rates. An 8000 Hz mouse sends 8000 reports per second, which can add USB traffic and CPU usage on some systems. Some gaming mice allow per-application polling rate profiles that stay at 1000 Hz during desktop use and switch to 4000 Hz inside specific games.⁵ Verifying the actual rate your system delivers with this tester confirms whether that profile switch is working correctly, or whether a driver or firmware issue is keeping it at the lower setting. A consistent gap between your mouse's rated maximum and the measured average here usually points to a USB or driver issue worth addressing before concluding the hardware is at fault.

How the reports reach the machine matters as much as the sensor. A mouse talking to a 2.4 GHz dongle behaves much like a wired report stream for polling purposes, and readings through a good dongle land close to the mouse's rated tier. Bluetooth is the variable one: the link schedules its traffic in connection intervals, which can hold readings down no matter what the sensor is capable of. If your reading is low and the mouse connects over Bluetooth, switching to the dongle or a cable is a faster experiment than any USB tweak. The wireless versus wired latency comparison covers the numbers side of that decision.

What input lag includes in a browser measurement

Input lag in this context is not a single number from one source. It is a stack: the mouse firmware queues reports at the configured polling rate, the USB controller schedules those reports across its polling window, the operating system processes them and applies any pointer acceleration, and the browser finally dispatches the PointerEvent to this page. Each stage adds a fixed or variable delay, so the total you measure is the sum of the whole path rather than the raw hardware response time.

This page measures movement polling rate in the Hz chart, while the click latency test times the button path separately. The two are related but distinct: a high polling rate reduces movement latency, and fast switch registration reduces click latency, and a mouse can be strong in one and weak in the other. Moving to a direct rear USB-A port, disabling USB selective suspend, raising the polling rate to its maximum, and turning off pointer acceleration each target a different stage, which is why applying them one at a time tells you which stage was responsible for the reading you started with.