Keyboard Polling Rate Test (Browser Event Cadence)

What this test actually measures

Every keyboard event your browser hands to a page carries a timestamp taken when the browser created the event. Subtract one timestamp from the previous one and you get the browser-observed event cadence: how far apart the events arrived, as seen from inside the page.

That number is real and reproducible, and several layers removed from your keyboard. Between the switch closing and the event reaching this page sit the keyboard's scan and report cycle, the USB or Bluetooth link, the OS input stack, the browser's input pipeline, and the page's main thread. What you measure is the output of that whole stack, and its coarsest stage dominates the result.

Why a browser cannot measure polling rate

Four independent reasons, any one of which would be enough on its own.

1. The OS coalesces and schedules input. Input reports are gathered by the operating system and delivered to applications on the OS's own schedule. Several device reports can collapse into one delivered event, and delivery is timed by the input and compositor scheduling of the system, not by the device's report rate.
2. Auto-repeat is generated by the OS, not by the keyboard. When you hold a key, the keyboard simply reports that the key remains down. The stream of repeated characters is synthesised by system software using your configured repeat delay and repeat rate. Timing that stream measures a settings value.
3. The browser coarsens its clock on purpose. High-resolution timers are a side-channel risk, so browsers quantise them. If the clock steps in whole milliseconds, a 1 ms polling interval and a 2 ms polling interval are literally the same number to your page.
4. A page never sees a USB transfer. There is no web API that exposes HID report boundaries, endpoint intervals, or link-layer timing for a system keyboard. The information simply is not present in the browser.

If you want the arithmetic of polling rates rather than a measurement of one, use the polling rate calculator, and read polling rate vs browser event cadence for the full comparison.

Held key and rapid typing are two different numbers

They are separated in this tool because mixing them produces a meaningless average.

Held-key mode gives two OS values: the initial repeat delay (how long you must hold before repeating starts) and the steady-state repeat interval (the gap between repeats after that). Both come from your system's keyboard settings. Because the source is a software timer, the interval is usually very stable, and that stability describes main-thread scheduling rather than your keyboard. The repeat rate test explores this in more depth.

Rapid-typing mode gives the distribution of gaps between your own presses. Even a fast typist rarely gets below roughly 40 ms between keystrokes — forty times longer than a 1000 Hz polling interval. The useful part is the spread: a long tail of unusually large gaps points at main-thread work or background load, not at the keyboard.

Polling rate reference — what each rate would imply

The table below is pure arithmetic from interval = 1000 ÷ rate. It is reference material, not a result: nothing on this page detects which row applies to your keyboard, and you should not read your measured cadence against it.

The distinction most people get wrong is average versus worst case. A key press lands at a random point inside the polling window, so on average it waits half an interval and at worst a full one. At 1000 Hz the polling interval is 1 ms, so the average added wait is about 0.5 ms and the worst case about 1 ms. Every step beyond 1000 Hz is therefore competing for less than one remaining millisecond.

Timer resolution, and why 1 ms matters here

The measurement environment panel above shows the smallest non-zero time difference this browser will actually express. Firefox clamps that to 1 ms unless the page is cross-origin isolated; Chromium-based browsers typically clamp to about 100 microseconds. Those are deliberate security mitigations, not bugs.

Put that next to the reference table. The entire difference between 500 Hz and 1000 Hz is 1 ms of polling interval, and a clock that steps in whole milliseconds cannot represent it. Even at 100 microsecond resolution, the OS scheduling noise sitting on top of every event is far larger than the quantity you would be trying to detect. That is why the honest output here is a cadence figure with its spread, plus a clear statement of what it is not.

How to read your cadence numbers

Look at the median first, then the spread. In held-key mode a median near 33 ms with small jitter means your OS repeat rate is roughly 30 events per second and the main thread is keeping up. Jitter that is a large fraction of the median means events are being delayed unevenly — usually background CPU load, a heavy extension, or a busy tab.

In rapid-typing mode, compare the fastest gap with the median. A big difference is normal; it is your hands. Worth investigating is a handful of gaps far above the rest — the same signature you would chase on the browser input latency test. If you suspect one press is producing two events, see the chatter test instead.