Keyboard Latency Calculator
Add up the stages between a key press and a pixel changing on screen, using values that you supply — this is an arithmetic estimate, not a measurement of your hardware.
Read this before you trust a number
Every field below is an assumption you control. The defaults are ordinary starting points, not measured figures, and real components vary enormously between products, firmware versions and drivers. The stages also overlap and queue in ways that a simple sum cannot capture, so the total is an approximation of an approximation. Only hardware instrumentation — a high-speed camera or a latency measurement rig — can produce a real end-to-end number. How this site measures things, and where it stops.
Latency model
Starting points
Each preset is an illustrative set of plausible values chosen to get you started. None of them describes a specific product, and none of them was measured. Change every field you can actually verify.
Applied to every stage whose value you typed directly, to produce its best and worst case. The two wait stages — transmission poll and display refresh — ignore it, because their spread is already known exactly: anywhere from zero to one full interval.
Keyboard side
From the moment the switch starts to close until the controller accepts it as a stable press. On most keyboards the debounce window dominates this figure, and it is a firmware setting rather than a property of the switch alone.
Keyboards read their key matrix on a repeating cycle. A press that lands just after a scan has to wait for the next one, so this behaves like a small periodic delay layered on top of the switch itself.
Turning a detected key into a report to send: layers, remapping, macros, tap-hold logic and rollover handling. Feature-heavy firmware configurations generally cost more here than plain ones.
Transmission to the computer
Polling interval 1.00 ms. A report that is ready just after a poll waits almost a whole interval; one that is ready just before waits almost nothing. Average wait is half an interval, worst case is a full one. Convert any polling rate to milliseconds.
Typical delay in milliseconds for the report to cross the radio link and reach the host through its receiver. It depends on the radio protocol, the channel conditions and any retry the link performs, so it is not a single fixed number for any product.
Typical delay in milliseconds across a Bluetooth link. Bluetooth devices negotiate a connection interval with the host and the host stack adds its own processing, so this term varies widely between adapters, operating systems and power-saving states.
How the key report physically reaches the computer. Each connection type pre-fills a different plausible starting value; all of them remain fully editable.
Computer side
The driver and input stack accepting the report, and the window system routing it to whichever application has focus. Under heavy CPU load this term grows, and it is the first thing that inflates when a machine is busy.
The application noticing the input and producing a frame that reflects it. In a game this is tied to the render loop and any queued frames, so it tracks frame rate far more than it tracks keyboard quality.
Display
One frame lasts 16.67 ms at this refresh rate. A finished frame has to wait for the next refresh before it is scanned out, so the wait is zero at best, half a frame on average and a full frame at worst. This term is derived arithmetically, not guessed.
Pixel response is how long the panel takes to actually change the pixels once the frame reaches it. Manufacturer figures are usually measured under favourable conditions, so a real transition often takes longer.
Estimated end-to-end input delay
Enter your values to build an estimate.
Show the full calculation
Every row is the value you supplied, or a value derived from it by the rule named in the last column. The running total adds the typical column from top to bottom.
| Stage | Best | Typical | Worst | Share | Running total | Rule |
|---|---|---|---|---|---|---|
| Total estimate | — | — | — | 100% | — | Sum of all stages |
Exports record your assumptions so you can revisit them later. They are generated in your browser and nothing is uploaded.
What if you changed one thing?
Adjust any field above and this compares the new model against the baseline. The baseline starts as the default model; capture your own whenever you want a fixed reference point.
Baseline
Current
Both bars share one scale.
| Stage | Baseline | Current | Change |
|---|
What this calculator cannot tell you
It cannot tell you the latency of your keyboard, your computer or your screen. It adds up numbers you typed in, so its output is only as good as those numbers — and for most stages nobody publishes a trustworthy figure for a specific product. It also assumes the stages happen strictly one after another, when in reality they overlap, queue, batch and occasionally miss a cycle entirely.
Nothing here is measured. There is no benchmark database behind this page, no table of named keyboards, and no claim about which product is faster. A real end-to-end number requires hardware instrumentation that watches the switch and the screen at the same time.
Read the full methodology and limitations · Run the browser-based latency test
How the estimate is calculated
The model treats the chain as a series of stages and adds them up. Two of those stages are waits for something periodic, and they are handled differently from the rest, because their spread is a matter of arithmetic rather than guesswork.
total = sum of every stage periodic wait stage: best = 0 typical = interval ÷ 2 worst = interval every other stage: best = v × (1 − a) typical = v worst = v × (1 + a) interval (transmission) = 1000 ÷ polling rate in Hz interval (display) = 1000 ÷ refresh rate in Hz v = the value you entered · a = the variation allowance
The two periodic stages are the polling interval on a wired connection and the display refresh. Everything else uses your value as the typical case and the variation allowance to open a window either side of it. That allowance is a statement about your confidence, not a measured tolerance, which is why it is a control rather than a constant.
Why the display is usually the largest term
People expect the keyboard to dominate. It rarely does. A 60 Hz display changes what you see only once every 16.7 ms, so a frame that is ready a moment too late waits for the next refresh, and the panel then takes further time to physically change the pixels. Together those two terms frequently exceed everything the keyboard contributes.
That is why the stacked bar is the useful part of this page. Doubling a polling rate from 500 to 1000 Hz removes half a millisecond of average wait. Going from a 60 Hz panel to a 144 Hz one removes roughly five milliseconds of average frame wait. Both are real, but they are not the same size, and the bar makes the difference impossible to miss.
Where a simple sum stops being accurate
Real systems do not queue politely in a single line. Firmware can start assembling a report while the matrix is still being scanned. An operating system may deliver several inputs in one batch. A game engine may already have a frame in flight, so your key press affects the frame after next rather than the next one. Compositors add a buffer, and some add a whole frame.
Each of those effects can make the true figure smaller or larger than the sum of the parts. Adding stages is the honest way to build intuition about which stage matters, and a dishonest way to claim a precise total. Read the number as an order of magnitude with a shape, not as a result.
Choosing values you can actually defend
Three inputs are usually knowable: whether the keyboard is wired or wireless, the polling rate it is configured for, and your monitor's refresh rate. Set those accurately first, because between them they control the two periodic stages and most of the range.
The remaining stages — debounce, matrix scan, firmware, OS and application — are far harder to pin down for a specific setup. If you leave them at their defaults, widen the variation allowance so the range reflects that uncertainty instead of hiding it. A narrow range around numbers you guessed is worse than a wide range around the same guesses.
What a browser test adds, and what it does not
A browser can time the gap between a keyboard event being created and your JavaScript handler running. That is genuinely useful: it captures browser-side event delivery and main-thread scheduling, which sit inside the application stage of this model. It cannot see anything that happened before the operating system handed the event over, so it cannot separate switch, firmware or transmission delay.
If you want that browser-side figure for your own machine, the keyboard latency test measures it with full statistics, and the event cadence test shows how regularly events arrive. Both report browser-observed timing only. For the background, what keyboard latency actually means and how latency and polling rate relate cover the distinctions this calculator depends on.
How to get a real end-to-end number
Two approaches work. A high-speed camera films the keyboard and the screen in one shot; you count frames between the keycap bottoming out and the screen changing, and the camera's frame rate sets your resolution. Alternatively, a measurement rig closes the switch electrically and a photodiode on the display reports when the light changes, which removes the human and the camera from the loop entirely.
Both approaches measure the physical chain, including everything this calculator can only assume. If the number matters to you — for competitive play, for accessibility work, or for engineering — that is the route. If you simply want to know which stage to spend money on, the stacked bar above will usually answer that in a few seconds. Practical changes are collected in how to reduce keyboard input lag.
Related tools
Frequently asked questions
Does this calculator measure my keyboard?
No. It performs arithmetic on values that you supply. Nothing on this page reads your hardware, times a key press or inspects your devices. If you change a number, the estimate changes — that is the whole mechanism. Treat the output as a model of your assumptions, not as a measurement of your setup.
What values should I enter if I do not know them?
Start from a preset, then replace the numbers you actually know: your polling rate, your monitor refresh rate and whether the keyboard is wired or wireless are usually easy to confirm. Leave the rest at the default and widen the variation allowance so the range honestly reflects how little you know about those stages.
Why is the display usually the largest component?
A display only changes what you see at fixed refresh intervals. At 60 Hz a frame lasts about 16.7 ms, so a finished frame waits on average half of that and at worst a full frame before it is scanned out, and the panel then needs time to change the pixels. Those two terms together are often larger than everything the keyboard contributes.
Why is the result a range instead of one number?
Two stages in the chain are waits for a periodic event — the transmission poll and the display refresh — so their contribution is anywhere between zero and one full interval depending on when the press lands. The other stages vary with temperature, load and firmware. A single number would imply a precision this model does not have.
How do I get a real end-to-end latency number?
You need hardware instrumentation: a high-speed camera filming the keyboard and screen together, or a measurement rig that triggers the switch electrically and watches a photodiode on the display. Both measure the physical chain from finger to photons. No software running inside that chain, including a browser, can substitute for it.