Keyboard Polling Rate Calculator
Convert a polling rate to its interval and see how much waiting time that interval can add — arithmetic performed on the number you enter, not a measurement of your hardware.
Rate and interval
Cycles per second. Accepted range 1 to 32,000 Hz.
Time between two checks. Accepted range 0.03125 to 1000 ms.
interval ms = 1000 ÷ rate Hz · average added wait = interval ÷ 2 · worst case = interval
These are theoretical figures for one stage of the input chain. They describe the polling window itself, not the delay your system actually produces.
How these numbers are worked out
Rate and interval are two ways of writing the same quantity:
interval_ms = 1000 / rate_hz. A rate of 1000 Hz is a 1 ms window,
500 Hz is a 2 ms window, 8000 Hz is a 0.125 ms window.
The added wait is the time between a key press becoming true at the device and the next
poll collecting it. If presses land at arbitrary points inside the window — a fair
assumption for human typing, which is not synchronised to the polling clock — that wait is
spread evenly from zero up to one full interval. So
average = interval / 2 and worst case = interval. The best case
is effectively zero, when a press happens to land just before a check.
The comparison against display refresh uses frame_ms = 1000 / refresh_hz,
which gives about 16.67 ms at 60 Hz, 6.944 ms at 144 Hz and
4.167 ms at 240 Hz. It is there only as a yardstick for judging whether a
difference in polling interval is large or small.
The model deliberately leaves out everything else: transfer scheduling on the bus, how long the report itself takes, the keyboard's own matrix scan and debounce, operating-system input handling and the application's own frame timing. Entries below 1 Hz or above 32,000 Hz are clamped to that range, because outside it the arithmetic no longer describes any transport in real use.
Common polling rates side by side
Each doubling of the rate halves the interval, and halves what is left of the wait. The row matching the rate above is marked as selected.
| Polling rate | Interval (ms) | Average added wait (ms) | Worst case (ms) |
|---|---|---|---|
| 125 Hz Selected | 8 | 4 | 8 |
| 250 Hz Selected | 4 | 2 | 4 |
| 500 Hz Selected | 2 | 1 | 2 |
| 1000 Hz Selected | 1 | 0.5 | 1 |
| 2000 Hz Selected | 0.5 | 0.25 | 0.5 |
| 4000 Hz Selected | 0.25 | 0.125 | 0.25 |
| 8000 Hz Selected | 0.125 | 0.0625 | 0.125 |
Difference between two rates
Going from 1000 Hz to 8000 Hz cuts the average added wait from 0.5 ms to 0.0625 ms — a saving of about 0.4375 ms. The worst case falls by 0.875 ms. For scale, that average saving is about 2.6% of one 60 Hz frame (16.67 ms) and about 6.3% of one 144 Hz frame (6.944 ms).
This is the transport component only, and only in theory. It says nothing about the keyboard's internal scan rate, the operating system's input handling, the application's own timing or the display. Against a 16.67 ms frame at 60 Hz or a 6.944 ms frame at 144 Hz, differences at the top of the polling range are small.
What this calculator cannot tell you
Every number on this page is arithmetic performed on the rate you typed in. Nothing here is measured, so the page cannot confirm what rate your keyboard actually runs at, whether its firmware really delivers that rate, or how much delay your system produces end to end. A web page cannot observe USB or Bluetooth transfers at all.
The added wait shown here is one stage among many. Switch actuation, matrix scanning and debounce, firmware processing, operating-system input handling, application logic and display refresh all sit outside this model, and together they are usually far larger than the polling window. If you want a browser-side measurement instead of a model, the event cadence test reports the interval between key events as your browser receives them — which is not the same thing as a polling rate.
What a polling rate actually describes
A polling rate is how often the host computer asks an input device for its current state. At 1000 Hz it asks a thousand times a second, so the checks are one millisecond apart. At 125 Hz they are eight milliseconds apart. Rate and interval carry exactly the same information, which is why the two fields at the top of this page are two views of one number.
The interval is the more useful form, because it is the size of the window in which a press can already be true at the device without the computer knowing about it yet. Nothing is lost in that window — the press is simply not reported until the next check comes round.
Why the average wait is half an interval
People usually quote the whole interval: "1000 Hz means 1 ms of lag". That is the worst case, not the typical one. A key press is not synchronised to the polling clock, so it can land anywhere inside the window with roughly equal probability. Sometimes it lands just before a check and waits almost nothing; sometimes it lands just after one and waits a full interval.
Averaged over many presses, the wait works out at half an interval. Both numbers are worth knowing: the average describes how the device behaves most of the time, and the worst case describes the tail you occasionally hit. Halving the interval halves both.
Why a higher polling rate is not automatically better
Each doubling of the rate removes half of what is left, so the returns fall away quickly. In average added wait:
- 125 Hz to 250 Hz saves 2 ms
- 250 Hz to 500 Hz saves 1 ms
- 500 Hz to 1000 Hz saves 0.5 ms
- 1000 Hz to 2000 Hz saves 0.25 ms
- 2000 Hz to 4000 Hz saves 0.125 ms
- 4000 Hz to 8000 Hz saves 0.0625 ms
The whole span from 125 Hz to 8000 Hz is about 3.94 ms of average wait, and more than half of that is gone by 500 Hz. Meanwhile every doubling doubles the number of transfers the host has to service each second, which means more frequent CPU wake-ups and more work for the USB stack. On some systems that overhead is measurable; on wireless devices it also costs battery life. A high rate is only useful if the device has genuinely new information to report each time it is asked.
Polling rate is not scan rate
Two different stages are easy to confuse. Scan rate is how often the keyboard's own controller reads its key matrix and updates the report it holds. Polling rate is how often the host asks for that report. If a keyboard scans its matrix every millisecond, polling it eight thousand times a second cannot produce fresher information than the scan provides — the extra checks mostly return what the previous one already said.
Debounce sits in the same place. Most keyboards wait a short, fixed period after a contact changes before they accept it, to avoid reporting the mechanical bounce of the switch as several presses. That delay is part of the device, not the transport, and on many designs it is larger than the entire polling window. Manufacturers publish these figures inconsistently, so treat a headline polling number as one stage of several rather than a summary of the whole device.
Where this delay sits in the whole chain
A key press travels through switch actuation, matrix scan and debounce, firmware, the transport this page models, the operating system's input stack, the application, its rendering, and finally the display. The polling window is one link, and usually not the biggest one.
Display refresh is a useful yardstick because it is easy to compute the same way:
1000 / refresh_hz gives about 16.67 ms per frame at 60 Hz,
6.944 ms at 144 Hz and 4.167 ms at 240 Hz. The entire difference
between 1000 Hz and 8000 Hz polling — roughly 0.44 ms on average — is a
small fraction of a single frame at any of those refresh rates. That does not make it
nothing, but it does put it in proportion.
If you want to see what a browser can and cannot observe about this, read polling rate versus browser event cadence, or build a full component estimate with the keyboard latency calculator.
Related tools and reading
Frequently asked questions
What is the polling interval at 1000 Hz?
One millisecond. A 1000 Hz polling rate means the host asks the device for its state 1000 times per second, so the gap between two checks is 1000 / 1000 = 1 ms. A press that lands just after a check waits up to a full millisecond to be picked up, and on average waits about half of that, roughly 0.5 ms.
Why is the average added wait half the polling interval?
Because a key press is not synchronised to the polling clock. It can land anywhere inside the window between two checks with roughly equal probability, so the wait until the next check is spread evenly between zero and one full interval. The mean of that spread is half an interval, while the worst case is a full interval.
Is 8000 Hz polling noticeably better than 1000 Hz?
On paper the average added wait drops from about 0.5 ms to about 0.0625 ms, a saving of roughly 0.44 ms. That is real but small: one frame at 60 Hz lasts about 16.7 ms and one frame at 144 Hz about 6.9 ms, so the saving is a small fraction of a single frame. It also only affects the transport stage; every other stage of the input chain is unchanged.
What is the difference between polling rate and scan rate?
Polling rate describes how often the host reads the keyboard's report over USB or another transport. Scan rate describes how often the keyboard's own controller reads its key matrix and updates that report. They are separate stages, and a device can be polled at a high rate while still scanning its matrix more slowly, in which case the scan is the limiting stage.
Can this page measure my keyboard's polling rate?
No. Everything here is arithmetic performed on the number you type in, so it describes a rate rather than measuring one. A web page cannot observe USB transfers at all. The closest a browser can get is the cadence of the key events it receives, which our event cadence test reports and which is shaped by the operating system and the browser as well as by the device.
Does a higher polling rate always reduce input lag?
It can only reduce the part of the delay spent waiting for the next poll, and that part shrinks with diminishing returns: moving from 125 to 1000 Hz removes about 3.5 ms of average wait, while moving from 1000 to 8000 Hz removes about 0.44 ms. Higher rates also mean more transfers per second and more frequent CPU wake-ups, which on some systems costs more than the delay it saves.