Press any key to see your keyboard's input latency split into delivery lag and processing lag. Lock a custom baseline or compare against wired, wireless, and Bluetooth benchmarks to measure the impact of any change.
Most keyboard latency tools online are vague about this. Being precise about what browser-based measurement can and cannot capture makes your result far more useful.
This tool measures the time between when the operating system timestamps a keydown event and when the browser's JavaScript engine processes it. This is the OS-to-browser processing delay, representing the portion of input lag that reflects your keyboard's polling rate, USB transmission efficiency, OS scheduling overhead, and browser event handling speed combined. It is sometimes called the software latency layer, and it is the component of the full input chain most directly affected by your keyboard hardware choice and system configuration.
True hardware-level USB polling latency (the delay between switch actuation and USB packet transmission) requires a USB protocol analyzer or oscilloscope. No browser-based tool can directly read this. Similarly, display latency (the time from GPU output to pixel on screen) and game engine tick latency are outside what JavaScript can observe. What this tool gives you is real, useful data about one important layer of the input chain. While it is not a substitute for hardware measurement, it provides a genuinely informative relative benchmark.
Two keyboards can have the same average latency of 8ms but feel completely different to use. If one keyboard always delivers events within 6 to 10ms (2ms jitter) while another fluctuates between 3ms and 20ms (17ms jitter), the second one feels unpredictable, especially in fast gaming or high-speed typing where your muscle memory has learned to compensate for a consistent delay but cannot adapt to a variable one. Low jitter is what makes a keyboard feel reliably responsive, not just fast on average.
Your complete input chain runs from switch actuation to USB polling, OS processing, application tick, GPU render, and monitor display. This test captures the middle segment, which includes USB polling, OS processing, and browser event handling. At 1000 Hz polling rate, the USB segment alone contributes up to 1ms. The OS processing layer typically adds 0.5 to 5ms. Browser overhead adds another 0.5 to 10ms depending on system load. Understanding which layer is contributing the most to your result tells you exactly where an improvement effort will have the most impact.
The most valuable use is relative comparison. Test your keyboard as it currently is, make a change (plug into a different USB port, switch from Bluetooth to 2.4GHz, close background applications, change polling rate), then test again. The difference between the two averages and jitter scores is your objective, quantified measurement of the impact of that change. This kind of before-and-after comparison extracts real information from a browser-based test and sidesteps the limitations of absolute measurement.
For most typing and everyday use, latency below 30ms is imperceptible. The situations where it matters are fast-paced games (CS2, Valorant, osu!, rhythm games) where the game engine processes inputs on short tick cycles, and high-speed typing above 80 WPM where the delay between a keypress and the character appearing creates a disconnect that makes self-correction difficult. You can check your raw keystroke rate with our keyboard CPS test. If your keyboard feels sluggish in everyday use, background processes and system load are almost always the cause, rather than the keyboard hardware itself.
Latency is never caused by a single component, but is the sum of contributions from several places in the input chain. Here is each one and how much it typically contributes.
Polling rate controls how often your keyboard reports its state to the computer. At 1000 Hz, it reports once per millisecond, meaning the maximum additional delay from polling is 1ms. At 125 Hz, that maximum is 8ms. On average, polling contributes half the interval value, which is 0.5ms at 1000 Hz and 4ms at 125 Hz. This is why upgrading from 125 Hz to 1000 Hz saves roughly 3.5ms on average, which is a real but modest improvement. Verify yours with our keyboard polling rate test.
Wired USB is the baseline, and all other connection types add delay relative to it. A 2.4GHz wireless dongle at 1000 Hz, like those used by Logitech Lightspeed or Razer HyperSpeed keyboards, adds 1 to 3ms over wired. Bluetooth HID adds 10 to 30ms because Bluetooth uses a slotted radio protocol optimized for efficiency rather than speed. For gaming or fast typing, wired or 2.4GHz at 1000 Hz delivers the most consistent results.
The operating system processes USB HID reports in interrupt-driven code, but the delivery of those events to applications still runs through the scheduler. When the CPU is heavily loaded, OS scheduling delays add jitter to input event delivery, which you will see as wider variance in your latency readings across a 50-sample session. This is why closing background applications before testing produces meaningfully cleaner results, and why gaming with heavy background processes feels worse than the hardware alone would suggest.
Browsers process input events in their JavaScript event loop, which shares CPU time with rendering, JavaScript execution, and network operations. A loaded browser tab, heavy script execution, or heavy visual animations all introduce event loop delays that show up as increased latency in this test. The cleanest results come from running the test as the only active tab in a browser window with no extensions. Chrome and Edge generally show slightly better event timing than Firefox for this type of measurement.
These two terms are related but distinct. The keyboard's scan rate is how fast its internal controller reads the key matrix to detect which keys are pressed, typically 1000 Hz on gaming keyboards and sometimes higher. The polling rate is how often the keyboard then reports to the computer via USB. Both affect latency, so a keyboard with a 1000 Hz scan rate and a 1000 Hz polling rate delivers the fastest possible end-to-end detection. Some keyboards scan faster than they poll, and this extra scan speed helps with accurate detection at high key-press rates but does not reduce reporting latency beyond the polling interval.
Every keyboard includes a firmware debounce delay, which is a brief window after a keypress during which additional signals from the same switch are ignored. This prevents contact bounce from registering as double keypresses. Most keyboards default to 4 to 8ms of debounce time. Increasing this to 12ms, a common fix for switch chatter, adds up to 4ms of additional latency. The trade-off between eliminating double inputs and minimising delay is worth understanding if you are tuning a keyboard's firmware. If you are experiencing key chatter, our keyboard double typing test identifies which specific keys are affected.
The test runs the moment you start pressing keys inside the zone. These habits give you data that is reliable enough to make real decisions from.
Close other browser tabs, pause cloud sync, and stop any downloads or antivirus scans before running the test. System load from background processes adds variability to OS scheduling, which shows up as higher jitter in your results. For a clean baseline that reflects only your keyboard and connection, test with the system as idle as possible.
You do not need to click inside a text box. The tool captures keypresses globally on this page. Simply press any key to immediately register a latency sample. The container highlights in yellow on each keypress to confirm that the input has been processed successfully.
You do not need to press a specific key or at a specific speed. Press any key, or multiple keys in sequence, at your natural typing pace. The tool measures each keydown event independently regardless of which key it is. Aim for the 50-sample default before drawing any conclusions about average or jitter, as fewer samples give less reliable statistics.
Your jitter score (shown as standard deviation in ms) is the most useful single number for gaming and competitive typing. Under 3ms is excellent. 3 to 8ms is typical for quality wired keyboards. Above 10ms suggests system load is interfering. The stability score summarises this: 95 and above means your latency is stable and predictable, while below 80 means it varies enough to affect feel during fast input.
The test's highest practical value is comparison. Run a full 50-sample session, note your average and jitter, make one change (USB port, connection type, background load), then run again. The difference in the two averages is an objective measurement of what that change actually did, which is far more reliable than trying to judge by feel alone.
Plug your keyboard directly into a rear USB port on your motherboard's back panel rather than a USB hub. Hubs and extension cables add extra routing layers that can increase latency jitter. For wireless keyboards, keep the 2.4GHz receiver close to the keyboard to prevent radio interference from causing lag spikes.
Ordered from the most impactful and easiest to the most involved. Start at the top, as most people see the largest gains without touching any hardware.
USB hubs, especially unpowered or front panel hubs, can cap your keyboard at 125 Hz and introduce additional jitter. Connecting directly to a rear motherboard USB port bypasses this limitation entirely. This is the single most common cause of unexpectedly high latency in this test, and it costs nothing to fix. After making the change, reset the test and run another 50 samples to confirm the improvement.
Many keyboards ship at 500 Hz by default. Open your keyboard's companion software (Logitech G HUB, Razer Synapse, SteelSeries GG, Corsair iCUE) and confirm the polling rate is set to 1000 Hz. This reduces the polling interval from 2ms to 1ms, saving up to 1ms of reporting delay. Verify the change with our keyboard polling rate test before drawing conclusions from the latency test.
Bluetooth adds 10 to 30ms of latency compared to wired connections, plus significantly more jitter. If your keyboard supports both Bluetooth and a 2.4GHz dongle, always use the dongle for gaming or fast typing. If you are testing over Bluetooth and seeing 30ms+ results, this is expected because the connection protocol, not the keyboard, is the bottleneck.
Windows Game Mode allocates more CPU resources to the foreground application and reduces background process scheduling interference. Setting your power plan to High Performance prevents the CPU from clock-speed throttling, which removes a source of variable latency under load. Both settings are in Windows Settings and cost nothing to enable. Together they typically reduce jitter noticeably in browser-based latency tests.
Antivirus scans, cloud backup, browser sync services, and video conferencing apps idling in the tray all consume CPU scheduler cycles. These appear in latency tests as irregular high latency spikes, which are events that arrive much later than usual because the scheduler was briefly occupied. Closing background applications before testing and gaming reduces jitter without any hardware changes. The consistency score in this test will show you the improvement immediately.
Outdated keyboard firmware can include suboptimal debounce timing or USB communication code that has since been corrected. Check your keyboard manufacturer's website for firmware updates and run them before testing for a baseline. Similarly, keeping USB host controller drivers current, through Windows Update or your motherboard manufacturer's site, ensures your system is handling HID events with the most efficient code available. If a firmware update changed your debounce settings and you are now experiencing repeated keypresses, our keyboard double typing test can confirm whether chatter is still the cause.
Knowing what a tool can and cannot measure makes every result more useful, not less.
These ranges reflect browser-measured OS-to-browser latency on a reasonably clean system, rather than raw USB hardware specs. Use them as relative context, not absolute verdicts.
Results above 25ms in this browser test do not necessarily mean your keyboard hardware is slow. System load from other processes, running this test in a background tab, or using a browser with heavy extensions all inflate the measurement. Always test with minimal background activity and a focused browser window before concluding that a hardware change is needed.
Clear, technically honest answers to what people actually ask about keyboard latency and how to measure it.