Keyboard Polling Rate Test — Check Your Keyboard Hz
Hold a key in the test area to inspect repeated keydown events reaching your browser. The displayed Hz is 1000 divided by the median of the last 500 event intervals. It includes operating-system key repeat.
This is a browser event-rate check, not a USB polling-rate measurement. Typing speed, repeat settings and browser scheduling affect the result; even the shortest interval cannot establish the keyboard’s hardware rate. Check the manufacturer’s settings or a USB capture for that.
What is keyboard polling rate?
Polling rate is how often your computer asks the keyboard for its state. USB is host-driven, so the keyboard never speaks unprompted: it requests an interrupt endpoint with a fixed interval — the bInterval field in its HID descriptor — and the host collects a report on that schedule. 1000 Hz means once every millisecond, 125 Hz once every 8 ms.
That interval caps one slice of input lag, not the whole chain. A report ready just after a poll waits almost a full interval, so polling adds about half an interval on average: roughly 4 ms at 125 Hz, 0.5 ms at 1000 Hz. Scanning, debounce and the display sit outside that figure, and are usually larger.
125, 500, 1000 and 8000 Hz — what each one actually costs
- 125 Hz — a report every 8 ms, about 4 ms average added delay. The USB default, and what most office and laptop keyboards run.
- 250 Hz — 4 ms, about 2 ms. 500 Hz — 2 ms, about 1 ms.
- 1000 Hz — 1 ms, about 0.5 ms. Standard on gaming boards and the practical end of the curve.
- 8000 Hz — 0.125 ms, about 0.06 ms. Needs a high-speed USB link and far more interrupts.
Wireless: 2.4 GHz dongles versus Bluetooth
A 2.4 GHz dongle is itself a USB device, so a wireless gaming keyboard usually reports at 1000 Hz over its receiver and some boards claim 4 or 8 kHz. Bluetooth cannot match that: Bluetooth Low Energy's minimum connection interval is 7.5 ms, a hard ceiling near 133 Hz, and most keyboards negotiate longer intervals to save battery.
What a browser can and cannot measure
This is a browser event-rate check, not a USB polling-rate measurement. Typing speed, repeat settings and browser scheduling affect the result; even the shortest interval cannot establish the keyboard’s hardware rate. Check the manufacturer’s settings or a USB capture for that.
When you need the real number
Vendor software reads the setting straight from the device, so Synapse, iCUE, G HUB and VIA are the first stop. USB capture gives ground truth: Wireshark with USBPcap on Windows, Bus Hound, or usbmon on Linux shows the real spacing of interrupt transfers. Reviewers who publish latency figures use a microcontroller or a high-speed camera, never a web page. Any site that confidently prints "8000 Hz" from inside a browser is showing a rounding artefact.
Does polling rate affect FPS?
Yes at the very top of the range, and through CPU load rather than graphics. Every report raises an interrupt the driver stack services on the CPU, so 8000 Hz costs eight times the interrupts of 1000 Hz; forum measurements reach roughly 17% of a core, and in a CPU-bound game that is frames you can lose. At 1000 Hz and below the cost is small enough to ignore.
Frame drops right after buying a "faster" keyboard are usually the higher report rate plus RGB software talking to the same device. If stutter starts when you enable 4 K or 8 K mode, set the board back to 1000 Hz, close the lighting software and measure again.
Polling rate vs scan rate vs debounce
- Scan rate — how often the keyboard's controller reads its own switch matrix, often 1 to 10 kHz. Internal; the host never sees it.
- Debounce — the settle window after contact, typically 3 to 8 ms on mechanical switches and much shorter on Hall-effect boards. Usually the biggest delay in the chain.
- Polling rate — how often the host collects the finished report. External, and the only one of the three in the USB descriptor.
The order is: switch closes, matrix scan notices, debounce expires, report queued, host polls. Raising polling on a board with 10 ms debounce changes almost nothing, which is why boards with modest report rates regularly beat 8 kHz ones in measured end-to-end tests. It also explains why online tools disagree with each other and with vendor software: some estimate scan rate, some measure event rate, and people compare the two and conclude their keyboard is faulty. It usually is not.
Frequently asked questions
How do I check what polling rate my keyboard has?
Open the vendor software first. Razer Synapse, Corsair iCUE, Logitech G HUB and VIA for QMK boards all show the report rate the device is actually set to, and that value comes from the keyboard itself rather than an estimate. A browser test only shows how fast key events reach a web page. For proof at the hardware level, capture USB traffic with Wireshark plus USBPcap on Windows, Bus Hound, or usbmon on Linux, and read the interval between interrupt transfers.
Is an 8000 Hz polling rate worth it on a keyboard?
Not on a keyboard. At 1000 Hz a finished report waits at most 1 ms to be collected; at 8000 Hz it waits at most 0.125 ms. You are buying back roughly half a millisecond on a chain that already contains 3 to 8 ms of debounce and a whole monitor refresh. Very high rates also multiply interrupt load, with figures around 17% of a CPU core reported on hardware forums. For keys, 1000 Hz is where the curve flattens.
Does polling rate affect FPS or CPU usage?
It can, at the top of the range, and through CPU load rather than graphics. Every report raises an interrupt the driver stack must service, so 8000 Hz costs eight times the interrupts of 1000 Hz; forum measurements reach about 17% of one core. At 1000 Hz and below the cost is negligible. One Tom's Hardware user did lose frames in CPU-heavy games after swapping a 50 Hz wireless combo for a 1000 Hz board with RGB software running.
What is the difference between polling rate and scan rate?
Scan rate is internal, polling rate is external. The keyboard's own controller scans its switch matrix, often at 1 to 10 kHz, to notice that a key moved. The host then collects the finished report over USB on its own schedule, once per millisecond at 1000 Hz. Between the two sits debounce, usually 3 to 8 ms and normally the largest delay of the three. A high polling rate cannot speed up a slow scan or a long debounce.
Why does the polling rate test show 125 Hz when my keyboard is set to 1000 Hz?
Hold a key in the test area to inspect repeated keydown events reaching your browser. The displayed Hz is 1000 divided by the median of the last 500 event intervals. It includes operating-system key repeat.
This is a browser event-rate check, not a USB polling-rate measurement. Typing speed, repeat settings and browser scheduling affect the result; even the shortest interval cannot establish the keyboard’s hardware rate. Check the manufacturer’s settings or a USB capture for that.
Can a wireless keyboard actually do 1000 Hz?
Over a 2.4 GHz dongle, yes. The dongle is a USB device in its own right and normally reports at 1000 Hz, with some recent boards advertising 4 or 8 kHz. Over Bluetooth, no: Bluetooth Low Energy's minimum connection interval is 7.5 ms, which caps reporting near 133 Hz, and most keyboards use longer intervals to save battery. If reporting rate matters to you, use the dongle or a cable, not Bluetooth.
Does a USB 2.0 port limit polling rate to 1000 Hz?
Only in full-speed mode. A full-speed USB HID device's shortest interval is one 1 ms frame, so 1000 Hz is its ceiling. Keyboards that advertise 8 kHz enumerate as high-speed devices and use 125 microsecond microframes, which any USB 2.0 port provides, so the same board behaves identically in a 2.0 or a 3.0 socket. What is worth avoiding is a cheap hub or a KVM in the path, which can re-clock or buffer reports.