DeviceBenchFree online keyboard latency test
Keyboard latency test from keypress to painted pixel
Tap one key thirty times and this page times the gap between the keydown your browser was handed and the first frame it managed to paint in response, then reports the best press, the median and the slowest one in twenty. That window is the browser’s share of the delay and nothing more — switch travel, the debounce inside the keyboard’s controller, the wait for the next USB report, the cable and your panel’s response all happen where no web page can watch them. Which is why the useful move is two runs on one computer minutes apart: swap the board, or move the same board from its cable to Bluetooth, and the gap between the two medians is a real difference you can act on.
- 100% free
- No signup
- 30-press run
- Median and 95th
- Two runs compared
Nothing is being timed yet. Press Start, or click the panel below.
—
Press any key with this tab in front of you and the gap appears here.
The bar changes color on every press. That color change is the pixel being timed.
Where the milliseconds went
- Event waiting for JavaScript
- —
- JavaScript waiting for the frame
- —
- Display rate while timing
- —
The second row can never go below zero and can rarely go below half a frame: a color only reaches your eyes when the compositor next draws, so measuring the display. Shorten the first row by closing the tabs doing work behind this one; the second row moves only if the display does.
How the presses were spread
Nothing plotted yet. The shape is the useful part: a keyboard has one latency, a busy computer has two.
Compare two keyboards
Numbers from different computers cannot be held against each other. Numbers from the same computer, minutes apart, with one thing changed, can — so name this run, save it, plug in the other keyboard and do it again.
No runs saved. They live in this tab only and go when you reload.
This window opens when your operating system hands the browser a keydown and closes when the browser has finished compositing the next frame. Everything before that opening — the two millimeters a switch travels, the debounce the controller waits out, the interval before the host next asks the keyboard for a report — and everything after that closing — the cable, the scaler and the milliseconds the panel needs to change a subpixel — is invisible to every web page ever written, including this one.
How to measure keyboard latency in a browser
Thirty presses of one key, then a second run with exactly one thing changed.
Click the panel, then tap one key thirty times
Use a single key at a steady rhythm rather than typing words: different switches on the same board can differ by a millisecond or two, and mixing them widens the spread for a reason that has nothing to do with the keyboard as a whole. Do not hold the key down — an auto-repeat is generated by the operating system on a timer and carries no useful timestamp, so held keys never reach the timer here.
Quote the median, and read the tail beside it
Your best press is the floor of the method, not the behavior of the hardware, and every rival page shows it because it is the flattering number. The middle of thirty presses is what you actually live with. The slowest one in twenty is the one you notice, and a large gap between the two says the delay is coming from whatever else this computer is doing rather than from the board.
Save the run, change one thing, run it again
Name the run, save it, then swap the keyboard or move the same keyboard from its cable to Bluetooth and collect thirty more presses. The saved table puts the medians side by side. Change one variable per run — a different browser, a different display or a different machine invalidates the comparison, and a gap under roughly two milliseconds is inside the noise of the method rather than a real difference.
Technical specifications
| What is timed | KeyboardEvent.timeStamp to the task scheduled behind the first composited frame, reached with requestAnimationFrame followed by a MessageChannel message |
|---|---|
| Presses per run | 30 requested before the median stops being labeled provisional; the ring keeps the newest 200 |
| Figures reported | Best, median, 95th percentile, and the split between event-to-script and script-to-pixel |
| Clock | performance.now(), monotonic and sub-millisecond; Date.now() is never used because it can step backwards on a clock correction |
| Floor of the method | Roughly half a display period on average — 8.3 ms at 60 Hz and 3.5 ms at 144 Hz — because a color only reaches the glass on a refresh |
| Outside the measurement | Switch travel, controller debounce, the USB report interval, the compositor's own pipeline, the cable and the panel's response time |
| Presses discarded | Any press whose frame arrived while the tab was hidden, where the browser throttles animation callbacks to about one a second |
| Data kept | Two millisecond figures per press, in memory for as long as the tab is open; which key you pressed is never recorded |
Frequently asked questions
The box said 1 ms latency. Why does this page show 20-something?
Because the two numbers describe different things. A keyboard advertised at 1 ms is describing how often it is allowed to send a report to the computer — a thousand times a second — which is the start of the journey. This page measures the end of it: from the moment the browser was handed the keypress to the moment a color it changed was composited onto your screen. Most of what stands between those two points is the wait for the next display refresh, not the keyboard, which is why a 1 ms board and a 125 Hz office board can measure within a few milliseconds of each other here.
Why does the number change when I drag the window to my other monitor?
Because a pixel can only change when the display next draws, so the refresh rate sets the floor. A 60 Hz panel draws every 16.7 ms and a keypress that lands just after a refresh has to wait almost all of that before anything can appear; a 144 Hz panel makes the same wait 6.9 ms at worst. Averaged over thirty presses that difference shows up as roughly half a frame of median, which is around 5 ms between those two panels, and it is the single largest thing you can change about the result.
Does a gaming keyboard's polling rate show up in this measurement?
Only faintly, and it is worth knowing why. Polling rate is how often the computer asks the keyboard whether anything has happened; at the old default of 125 times a second a keypress can sit in the keyboard for up to 8 ms before anyone asks, and at 1,000 times a second that worst case is 1 ms. That saving is real, but it happens before the browser is told anything at all, so it never appears inside the window this page can see. What you can do is measure the same keyboard at both settings and watch whether the medians separate by more than the noise.
Is Bluetooth actually slower than a cable, or is that folklore?
It is usually slower and this is the cheapest way to see it for yourself. A Bluetooth keyboard negotiates a connection interval with the host, commonly between 7.5 ms and 15 ms, and a keypress waits for the next one of those before it is transmitted at all — on top of which the radio can retry a lost packet. Run thirty presses on the cable, save the run, unplug it, pair the same board over Bluetooth and run thirty more. A median that moves by 5-10 ms is the link; a median that moves by half a millisecond is measurement noise.
One press came back at 90 ms. Should I throw the run away?
No — that press is the most useful one on the page. The browser runs your keypress handling on the same thread as everything else the tab is doing, so a garbage collection, a script in a background tab or the operating system deciding to schedule something else all show up as a single very late press. That is why the slowest-one-in-twenty figure is shown next to the median instead of being quietly trimmed: it is the honest description of the worst you will feel. If it happens on every third press, close the other tabs and run it again.
Am I really feeling this delay, or imagining it?
Both are possible, and the way to settle it is to change one thing and compare medians rather than to trust the feeling. Human variation dwarfs everything on this page: the spread between your own fastest and slowest genuine reaction runs into tens of milliseconds, while the honest difference between two decent keyboards is a handful. So a keyboard that feels sluggish next to one that feels crisp is a claim worth testing, and a keyboard that feels sluggish on Tuesday and fine on Wednesday is almost certainly the machine underneath it.
Does the browser I run this in change the answer?
Yes, by a few milliseconds, so compare browser to browser only if that is the thing you are testing. Engines differ in how quickly an input event is dispatched to a page and in how they schedule compositing afterwards, and a browser with hardware acceleration disabled can add a whole frame. Extensions matter too: anything that listens on every keystroke is another handler that has to run before this page is reached.
About the chain between a switch and a pixel
A keypress crosses about eight stages before you see anything, and only three of them are visible from a web page. The stem falls two millimeters or so until the contact closes; the keyboard’s controller waits out a debounce window, typically five milliseconds, to be sure the contact has stopped bouncing; the host asks the keyboard for a report on its polling interval, 8 ms apart on an ordinary board and 1 ms on a fast one; the operating system’s input thread wakes and routes it; the browser queues an event and dispatches it to this page; the page changes a color; the compositor builds a frame; the panel takes its own few milliseconds to actually change the subpixels. The stopwatch here starts at the fifth stage and stops at the seventh. Four of the eight are behind the curtain, and every browser-based tester that quotes a total without saying so is quoting a partial answer as a whole one. It is worth holding the whole chain against the scale of the person at the end of it: a good human reaction to something appearing on screen is around 200 milliseconds, an order of magnitude larger than anything argued about here, which is why a test of you rather than of your hardware — the number memory test is one — answers a completely different question and should never be compared with this one.
The stage most such pages get wrong is the last one they can see. It is tempting to time a keypress to the next requestAnimationFrame callback, because that is the frame hook every tutorial reaches for — but a rAF callback runs before the browser performs style, layout, paint and compositing for that frame, so stopping the clock there understates the result by most of a frame and makes slow machines look fast. What this page waits for instead is a task queued through a MessageChannel inside the rAF callback: that message is delivered after the frame’s rendering steps have finished, which is the earliest instant a page can honestly claim the pixel exists. The measurement also needs something to paint, which is why the strip under the counter flips color on every press rather than merely counting them.
What to do with the number depends on which half of it is large. If the wait for JavaScript dominates, the problem is load on this computer rather than your keyboard — close the tabs working in the background and the figure drops. If the wait for the frame dominates, you are looking at your display, and the input lag test takes that side of the chain apart properly. If the delay only appears once you are playing against other people, none of this is the cause and the jitter test is measuring the part that is: a connection whose round trip wanders by 40 ms swamps everything a keyboard could contribute. And a keyboard can time perfectly and still be broken in the two ways this page cannot detect — a switch that no longer fires at all, which is what the keyboard test colors in, and a board that drops keys when several are held together, which the key rollover test provokes on purpose. If the lateness you feel is in words rather than in single keys, measure it where it happens, on the typing speed test.
What the stopwatch stores
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
Each press leaves behind two numbers in milliseconds and nothing else. The identity of the key is read to check that the event was a real press rather than an auto-repeat and is then discarded in the same function, so no sequence of keys exists anywhere on this page — not in a variable, not in storage, and not in the summary the Copy button builds.