How We Measure Polling Rate in the Browser

This page explains the method: pointermove with getCoalescedEvents, pointerrawupdate on Chromium, rolling 1-second windows with a 300 ms warm-up, duplicate-timestamp removal, median over windows, class labels within ±10% held 3 seconds, browser-ceiling banners, and the honest limits — no firmware, no USB packets, no keyboard Hz. All computation stays in the tab.

What this measures

Pointer event timestamps via getCoalescedEvents() (all browsers)
Raw pointer timestamps via pointerrawupdate (Chromium only)
Rolling 1-second window rate with 300 ms warm-up
Duplicate-timestamp deduplication
Median, mean, min, max, and coefficient of variation across windows
Class label when median stays within ±10% of a standard rate for 3+ seconds
Browser-ceiling banner when observed rate hits the measured limit

What this cannot measure

Hardware firmware polling rate
USB packet timing or electrical signaling
Keyboard polling rate in Hz (browsers cannot expose this)
True input latency from device to display photon
DPI accuracy or sensor counts per inch
Gamepad or controller polling rate

The method

The test listens for pointer events on a dedicated movement area inside the page. When it uses pointermove, it calls getCoalescedEvents() on each event to retrieve the intermediate samples that the browser coalesced into that single event. Each sample carries a timeStamp (DOMHighResTimeStamp, sub-millisecond). On Chromium-based browsers, the test instead uses pointerrawupdate, which delivers non-frame-aligned samples with their own timestamps. Feature detection chooses the available path; the test never fails silently — it falls back to plain pointermove timestamps if neither advanced API is present.

The live readout counts unique samples in the trailing 1-second window. Session statistics use fixed consecutive 1-second windows: the first 300 ms after the test starts are discarded as warm-up to let the event loop settle, and samples with identical timestamps are deduplicated (only the first counts). When a window closes, its unique sample count becomes the rate for that window in Hz. The session accumulates these window rates.

The math

From the series of 1-second window rates, the test computes: median (the middle value, robust to outliers), mean (average, pulled by spikes and drops), minimum and maximum window rates, and the coefficient of variation (standard deviation divided by mean, expressed as a percentage). Variation is labeled "Variation: X% (lower is steadier)." The live chart plots each window rate as a point on an inline SVG line chart. Windows below 80% of the session median are shaded as drops; windows above 120% are shaded as spikes. A numeric table alternative is provided for screen readers.

Class labeling rule

The standard classes are 125, 250, 500, 1000, 2000, 4000, and 8000 Hz. The test shows the nearest class label only when two conditions hold: the session median sits within ±10% of that class, and the window rates stayed inside that band for at least 3 consecutive seconds (three successive windows). If either condition fails, the test shows the observed median Hz with no class label. This prevents a brief stable moment from earning a class that the session does not sustain.

Browser ceilings and the browser-limited banner

Each browser has a ceiling — the highest 1-second window rate it can consistently deliver distinct timestamps for. Provisional ceilings ship with the test and are being confirmed through Phase 0 validation runs with reference mice. When the live rate reaches that ceiling, a banner appears: "Browser-limited: the real rate may be higher than shown." This is not an error. It means the browser cannot observe timestamps finer than its ceiling. High-rate mice (4000 Hz, 8000 Hz) often reach the ceiling on current desktop browsers. The banner links to this page for the explanation.

What we cannot measure

The browser receives pointer events after the operating system processes the USB reports. It has no access to the mouse firmware, the USB packet stream, or the hardware timer that schedules reports. It cannot measure a keyboard's polling rate in Hz — key events arrive after OS processing, and the WebHID API does not expose keyboard input to web pages. It cannot measure DPI, true sensitivity, or end-to-end input latency from device to display photon. The test reports only what the browser observes, labeled as such.

Privacy statement

All computation runs in the browser tab. No mouse coordinates, timestamps, key codes, press durations, or derived rates are transmitted over the network. The only network requests are for the page assets 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: start a test, move the mouse, and confirm no request carries pointer or timing data. The copy-to-clipboard button outputs only the numeric summary with the browser-observed label. No cookies are set beyond consent-managed ad cookies (ads are deferred and not present at launch).

Validation

The table below is filled as Phase 0 validation runs are completed. Each row records a reference mouse, its vendor-software reported rate, the browser tested, the display refresh rate, and the browser-observed median and variation from a 30-second run. Results are not fabricated — entries are added only after a real run is completed and recorded.

Reference mice (to be tested): one 1000 Hz wired, one 4000 Hz or higher wired, one wireless 1000 Hz. Browsers: Chrome, Edge, Firefox, Safari (macOS). Display refresh rates: 60 Hz, 144 Hz, 240 Hz where available.

Mouse	Vendor setting	Browser	Display Hz	Observed median	Variation	Class label	Browser-limited
[Reference mouse 1 — 1000 Hz wired]	1000 Hz	Chrome	144	—	—	—	—
[Reference mouse 2 — ≥4000 Hz wired]	4000 Hz	Chrome	144	—	—	—	—
[Reference mouse 3 — 1000 Hz wireless]	1000 Hz	Chrome	144	—	—	—	—
[Reference mouse 1 — 1000 Hz wired]	1000 Hz	Firefox	144	—	—	—	—
[Reference mouse 1 — 1000 Hz wired]	1000 Hz	Safari	120	—	—	—	—

Frequently asked questions

Can a website read my mouse's polling rate?

A website can only observe the rate at which the browser delivers pointer events, after the OS processes the USB reports. It cannot read the mouse firmware, USB packets, or the hardware timer. The observed rate is a lower bound, labeled "browser-observed," and often differs from the hardware setting, especially above 1000 Hz.

Can a keyboard's polling rate be tested?

No. Key events arrive after operating system processing, and the WebHID API blocks web access to keyboard input reports for security reasons. A browser cannot measure a keyboard's hardware polling rate in Hz. Read our dedicated guide on what browser keyboard testing can and cannot show to learn why online keyboard Hz claims are impossible.

What does the browser-limited banner mean?

It means the observed rate hit the browser's measured ceiling for distinct timestamps per second. The real hardware rate may be higher — the browser simply cannot observe it. This is expected for 4000 Hz and 8000 Hz mice on current desktop browsers.

Which browser should I use for the test?

Chrome or Edge (Chromium) are recommended because they support both getCoalescedEvents and pointerrawupdate, giving the most complete sample set. Firefox and Safari use coalesced events, or plain pointermove on builds without support — and the plain-pointermove path carries a lower-confidence badge. Mobile browsers are not supported for mouse tests — touch input is not a mouse test.

Why is there a 300 ms warm-up?

The first few hundred milliseconds after the test starts often include browser initialization, event-loop settling, and the first display frame alignment. Discarding that window prevents an artificially low first window from pulling down the median.

How is the variation percentage calculated?

Coefficient of variation: standard deviation of the 1-second window rates divided by the mean of those rates, multiplied by 100. Lower variation means the rate held steadier across the session. A perfectly steady 1000 Hz session would show 0% variation.