One press, one sample
The first keydown event becomes a sample. Holding a key does not flood the results because automatic repeat events are ignored.
Keyboard latency tester.
Measure event delay.
Measure how quickly keyboard events reach this browser and how consistently they arrive. Press naturally, collect a useful sample, and compare changes under the same conditions.
Start measuringPress any key.
Read the delay.
The panel focuses automatically. Use a wired connection and close demanding background tasks when comparing devices or settings.
Important: this is browser-observed event delay, not a direct measurement of switch actuation or total click-to-pixel latency.
Latency monitor
Keep this panel focused and press keys repeatedly
—
Latest event delay--ms
Awaiting input0 samples
Average
--ms
Jitter
--ms
Minimum
--ms
Maximum
--ms
What this test
actually measures.
Each key event carries a browser timestamp. The tester compares that timestamp with the moment its JavaScript handler runs. The difference is the event-dispatch delay visible to this page.
Consistency matters
Average delay describes the center of the results. Jitter describes how widely those samples vary. A stable result is easier to trust and compare.
Context shapes the number
Operating-system scheduling, browser load, power settings, background work, and connection type can all affect the delay observed here.
From switch
to screen.
A keyboard input passes through several stages. This browser can observe only the final handoff into page code.
- Switch actuationA physical contact or optical sensor detects the press.
- Firmware scanThe keyboard controller scans its matrix, applies debounce, and prepares a report.
- Connection transferUSB, a 2.4 GHz receiver, or Bluetooth carries the report to the computer.
- System dispatchThe operating system and browser deliver the event to this page. This is the stage the tool observes.
- Visual responseThe browser renders a later frame. Display refresh and pixel response happen after the measured event.
Read the result
without overreading it.
Use the numbers to compare configurations on the same computer and browser. They are not a universal product ranking.
Average
The arithmetic mean of the current sample history. Lower values indicate that events reached the handler sooner during this run.
Jitter
The standard deviation of the samples. Lower jitter means delivery timing stayed more consistent from press to press.
Minimum
The quickest observed event. It shows the best result in the run, but should not be treated as the keyboard's guaranteed latency.
Maximum
The slowest observed event. A single spike may reflect a busy browser tab or operating-system scheduling rather than the keyboard alone.
Make comparisons
that mean something.
Control the test conditions before deciding that one keyboard or setting is faster.
Keep the setup stable
Use the same browser, USB port, power mode, and background workload for both runs.
Collect enough samples
Press naturally at least 30 times. A larger history reduces the influence of one scheduling spike.
Repeat the run
Reset and test again. A change is more convincing when it appears across several runs.
Change one variable
Compare wired with wireless, one polling setting with another, or one power profile at a time.
Reduce avoidable
input delay.
Start with changes that are reversible and easy to compare.
- Prefer a direct connection. Connect through a motherboard USB port or a well-powered receiver extension before troubleshooting hubs.
- Compare connection modes. A dedicated 2.4 GHz receiver often prioritizes responsiveness; Bluetooth behavior varies by device and power policy.
- Limit background load. Heavy tabs, updates, recording tools, and CPU-intensive work can delay browser event handling.
- Check keyboard settings. Supported polling-rate, debounce, and performance modes can change behavior, but higher settings may use more power.
- Retest after each change. Keep the same sample size and conditions so the comparison remains useful.
Private by design.
Samples are calculated in this tab. No key history or timing result is uploaded, stored in an account, or sent to a server.
0samples transmittedComparative by nature.
The browser cannot see the instant a physical switch closes. Use this test to compare local conditions, not certify manufacturer specifications.
100recent samples retainedFAQ
Clear answers about browser-based keyboard latency testing.
Is this absolute keyboard hardware latency?
No. A webpage cannot observe the exact moment a switch actuates or directly inspect USB packets. It measures delay at the operating-system-to-browser event boundary.
What is a good keyboard latency result?
Lower and more consistent is generally better, but the useful baseline is your own system. Compare repeated runs in the same browser under the same load instead of treating one threshold as universal.
Why do some samples show zero?
Very fast delivery can round close to zero. A zero may also be used when a browser exposes timestamps from an incompatible clock origin, preventing an invalid extreme value from distorting the run.
Why does the result change between runs?
Event handling competes with browser work and operating-system scheduling. Background applications, power management, thermal limits, and tab activity can all introduce variation.
Does a higher polling rate always lower this number?
Not always. Polling rate affects one part of the input chain, while this page observes a later stage. Firmware, connection mode, system load, and browser scheduling still matter.
Can I compare wired, Bluetooth, and 2.4 GHz modes?
Yes, as a practical local comparison. Keep every other condition unchanged, collect the same number of samples, and repeat each mode more than once.
Does refresh rate affect this measurement?
The displayed number is calculated when the event handler runs, before a later frame is rendered. Refresh rate affects when you see the update, but is not directly included in the reported sample.
Are key names or timings saved?
No. The current key and latest 100 timing samples exist only in this page's memory and disappear when you reset or leave the page.
Method and
further reading.
This test uses browser event timestamps and the page's handler time. Review the method before comparing results from different tools.
Browser event timing
Read MDN's references for Event.timeStamp and KeyboardEvent to understand the browser data available to this page.
Longer testing guide
Use the keyboard latency guide for a repeatable A/B procedure and a worksheet for recording conditions.
Ready for
another run?
Reset the history, keep the conditions steady, and see whether the change holds up.
Measure again