Mouse Polling Rate & Input Tests — Free, In-Browser

The core tool is a mouse polling rate test that samples pointer events using the browser's Pointer Events API. It reads coalesced events where available and falls back to standard pointermove on other browsers. A live line chart plots the rate in 1-second windows across the session, with drops and spikes shaded for quick visual diagnosis. The result card reports median, mean, min, max, variation, and a class label when the reading is steady enough to earn one.

Beyond polling rate, this suite includes four dedicated diagnostic tools for desktop mice. The click test inspects five distinct mouse buttons (Left, Middle, Right, Back, Forward) and checks for potential switch bounce intervals under 50 milliseconds. The scroll test analyzes wheel events, identifying direction, step count, delta magnitude, and dominant axis. The drift test monitors your sensor during a 15-second untouched period to identify phantom movement. The reaction test measures click response latency across five randomized visual trials.

Each tool runs in its own dedicated page with a consistent layout: a direct answer, the interactive test, an explanation of what the test measures and what it cannot measure, steps for getting a steady reading, a results table with plain-language meanings, a focused FAQ, and links to related tests. This structure makes it easy to find the information you need without hunting through menus or dealing with intrusive distractions.

A browser cannot read your mouse's firmware or USB packets. It receives pointer events after the operating system processes them, and it aligns delivery to display frames by default. On a 144 Hz display, even a 1000 Hz mouse produces batched samples unless the page reads coalesced events. The browser-observed rate is therefore a lower bound, not a hardware measurement.

Higher-rate mice (4000 Hz, 8000 Hz) almost always read lower in a browser because the OS and display pipeline cannot deliver that many distinct timestamps per second. When the observed rate hits the browser's ceiling, a banner reads: "Browser-limited: the real rate may be higher than shown." This is not an error — it is the honest limit of what a web page can see.

The ceiling varies by browser, operating system, and display setup. The browser guide explains how to interpret readings near the limit, and the how-we-measure page will carry the validation results for each browser as validation runs are completed.

Every result carries the heading "Browser-observed polling rate" and a one-line method note. The site never uses wording that implies hardware certification or access to firmware. Approved phrasing is "the browser observed about X Hz" and "a browser cannot confirm the hardware rate." A build-time check enforces this rule on every page, in both content and interface text.

All computation happens in the tab. No mouse or timing data is sent anywhere. The only network requests are for the page itself and optional analytics that count page views and test starts — never input values. You can verify this with developer tools open on the Network tab.

We also publish clear technical guides explaining why browser measurements differ from manufacturer ratings. We do not claim to offer a keyboard polling rate tool because web browsers lack the technical APIs to measure keyboard USB report intervals honestly. Where other sites fabricate numbers, we explain the architectural boundary.

A gamer checking a new mouse wants a reading that stays steady over 30 seconds of real movement. A buyer comparing devices wants to know what the browser can and cannot tell them so they don't treat a number as a hardware measurement. A troubleshooter with a wireless or suspect mouse wants a graph that shows drops so they can tell a battery or interference problem from a steady rate. A reviewer or streamer wants to copy or save the result to compare settings or share it. A privacy-minded visitor wants confidence that nothing they press or move leaves their device.

The site also serves AI crawlers and agents that need accurate, structured information about what each tool does and what its limits are. Every page includes machine-readable JSON-LD for FAQs and clear semantic HTML so automated readers can extract the same information a human would.

The measurement engines run entirely in the browser tab. No input data — coordinates, timestamps, button identities, or press durations — is transmitted, stored remotely, or logged. The copy-to-clipboard button outputs only the numeric summary with the browser-observed label. No cookies are set in the current version; consent-managed ad cookies only ever arrive if ads are approved later.

To allow you to track changes across different USB ports, DPI settings, or wireless receiver distances, the benchmark saves the summary metrics of your last 10 runs in your browser's local storage under the key mk-run-history. This history is stored solely on your local device, is never transmitted across the network, and can be cleared instantly at any time from your browser settings or test controls.

The privacy policy explains in plain language what data is processed, what is never collected (any raw input values or hardware serials), and how to verify these claims yourself using browser developer tools. There are no hidden trackers, no canvas fingerprinting, and no third-party scripts that could inspect your movement activity.

The result card shows the session median, mean, min, max, variation, and any class label, plus the test duration and browser name. The median is the most reliable single number — it represents the middle of all 1-second windows and resists outliers. The mean can be pulled up by brief spikes or down by drops. Variation (coefficient of variation) tells you how steady the rate was: lower is steadier. A class label appears only when the median sits within ±10% of a standard rate (125, 250, 500, 1000, 2000, 4000, 8000 Hz) for at least three consecutive seconds.

The stability graph plots each 1-second window as a point on a line chart. Windows below 80% of the median are shaded as drops; windows above 120% are shaded as spikes. The numeric table under the graph lists the exact rate for every window, for screen readers and for anyone who prefers raw numbers.

To compare two mice, control the variables: use the same browser (Chrome or Edge recommended), the same display refresh rate, the same test duration (30 seconds minimum), similar smooth movement patterns, and the same background apps closed. Record the median, variation, and whether a class label appeared for each. If one mouse triggers the browser-limited banner and the other does not, the limited one may have a higher real rate that the browser cannot observe.

Make sure both devices have fresh batteries or fully charged accumulators. Wireless interference from nearby routers, smartphones, or unshielded USB 3.0 cables can introduce periodic polling drops that mimic sensor failure. Testing both mice in the identical physical setup ensures that differences in variation reflect sensor and link characteristics rather than environment changes.

The method page explains the pointer event pipeline, the rolling-window math, the class-label rule, the browser-ceiling banner, and the validation log with reference mice and browsers. Start there if you want the technical details behind the numbers. If a reading looks wrong, the browser guide walks through the common causes — battery level, receiver placement, wireless interference, and display settings — before you conclude that anything is broken.