Keyboard Polling Rate Explained: 125Hz to 8000Hz

Keyboard polling rate is the frequency at which a keyboard can report its state to the host. The familiar figures—125Hz, 500Hz, 1000Hz, 4000Hz and 8000Hz—describe theoretical report intervals, not a promise that every physical key press will arrive at an application within exactly that time.

Use the Keyboard Polling Rate Test for a ten-second browser-observed timing estimate. The result is useful for comparing settings on the same computer, but it is not a raw USB measurement.

Polling rate in milliseconds

Polling rate and report interval are inverses: divide 1000 by the rate in Hz.

These figures describe the connection's opportunity to report. They do not include switch travel, debounce, matrix scanning, firmware processing, operating-system scheduling, game processing or display latency.

Polling rate versus keyboard scan rate

The scan rate is how often the keyboard controller checks its switch matrix. The polling or report rate describes communication with the host. A keyboard can scan and report at different rates, and firmware may wait for debounce logic before a changed key state is ready to send.

That distinction matters because a fast USB setting cannot recover time already spent before the report was created. It also explains why a browser timing trace should not be labeled as the keyboard's scan rate.

Does 1000Hz versus 8000Hz matter?

The theoretical interval falls from 1ms at 1000Hz to 0.125ms at 8000Hz, a difference of 0.875ms between report opportunities. Whether that changes a game input depends on the rest of the latency path and where the key press lands relative to the reporting schedule. It does not make every input exactly 0.875ms faster.

For most people, stable firmware behavior, reliable switches, useful rollover and a consistent connection matter more than the headline rate. Higher rates may also create more host work, so the best setting is the highest stable option that does not cause problems in the user's actual games and system.

What a browser can observe

A webpage receives KeyboardEvent timestamps after the operating system and browser have processed input. It cannot read the keyboard's USB report descriptor, inspect individual USB frames or separate debounce time from scan time. Browser load and event scheduling can also change the spacing.

Our homepage test therefore:

1. collects only focused, non-repeating A/S events for ten seconds;
2. removes invalid timestamps, impossible sub-0.125ms gaps and long pauses;
3. uses the 10th percentile of valid short intervals instead of a single fastest sample;
4. labels the answer as a browser-observed estimate.

Run several trials under the same conditions. A repeatable change after switching a firmware profile, port or connection mode is more informative than one isolated number.

How to verify a keyboard setting

First check the manufacturer's firmware or companion software for the configured report-rate profile. Then compare repeated runs on the Keyboard Polling Rate Test with the same direct USB port, browser and background workload. If you need the actual USB cadence for validation or engineering work, use a suitable USB protocol analyzer or low-level diagnostic that can inspect reports.

Use the Keyboard Tester for dead keys and chatter, and the Ghosting / NKRO Test for simultaneous key combinations. Those are separate questions from report frequency.