Keyboard Comparison
Put two sessions you saved in this browser side by side and check whether the difference between them is bigger than the noise inside each one.
Saved sessions are unavailable in this browser. Local storage is blocked, so results cannot be kept between page loads. Private windows and strict privacy settings usually cause this. Anything you save now will be lost when you leave.
You need two saved sessions before you can compare
This page does not run a test of its own. It reads sessions that other tests on this site saved into this browser, so the first step is to record two of them.
- Run the keyboard latency test and save the result when it finishes.
- Change one thing — plug in the other keyboard, switch from Bluetooth to the cable, close the app that was pinning a CPU core — and run it again.
- Come back here. Both runs will be in the two selectors, and you can rename them.
The keyboard performance test also saves a session, and its combined report gives you more metrics to compare.
Choose two sessions
Session A
Session B
Both selectors point at the same saved session. Pick two different sessions, or every difference below will be zero by construction.
These two sessions were not recorded under the same conditions
A difference between them is therefore a difference between two measurement conditions, not between two keyboards. To compare keyboards, record both sessions on the same machine, in the same browser, with as little else changed as possible.
Is the difference bigger than the noise?
Select two sessions to see a verdict.
Show the arithmetic
This is a plain ratio of the median gap to the combined spread of the two sessions — an effect-size check you can redo by hand from the numbers above. It is not a significance test and no p-value is calculated. How we measure.
Recorded conditions
| Condition | Session A | Session B | Same? |
|---|
Metric by metric
| Metric | Session A | Session B | Difference (B − A) | Change | Better | Direction |
|---|
Key metrics, side by side
Session ASession B
Distribution and run order
Both sessions saved their individual samples, so the shape of each run can be drawn. The two charts in each pair are scaled to their own data — read the shapes, and take the actual values from the table above.
No per-sample data in these sessions. One or both of them saved summary statistics only, so the distribution and run-order charts cannot be drawn. The comparison above still works — it just relies on the medians and spread figures that were saved.
Measurement environment
Timer resolution: — High-resolution timing: — Browser: — Platform: —
This describes the browser you are reading in now, not the browser each saved session was recorded in — those are listed in the recorded conditions table above. A browser that rounds its clock to 1 ms cannot resolve sub-millisecond differences, so jitter recorded there will look artificially quantised. How we measure.
What this comparison cannot tell you
Both sessions were measured in a web browser, so both can only see keyboard events after the operating system has already delivered them. Comparing them cannot isolate switch actuation, keyboard firmware, matrix scanning, USB or Bluetooth transmission, driver behaviour, OS scheduling, or display response. A difference here tells you that the two runs produced different browser-observed timing — it does not tell you which part of the chain changed, and it is not a hardware latency measurement of either keyboard.
It also cannot rank keyboards in general. Two sessions are two samples of two moments on one machine. Anything running in the background during either run is inside the result.
How this comparison works
Every metric that both sessions saved is lined up in one row: the value from A, the value from B, the absolute difference, the percentage change, and — only where the metric has a defined direction — which session came out ahead. Median latency has an obvious direction, because lower is better. A sample count does not: collecting more samples makes the test better, not the keyboard. Metrics like that get a dash instead of a winner, because guessing a direction would be inventing a result.
Why a difference has to be bigger than the noise
Keystroke timing is not one number, it is a cloud. Within a single session, individual samples routinely vary by a millisecond or more depending on what the main thread was doing at that instant. If the two sessions overlap heavily, a gap between their medians can easily be an accident of which moments you happened to sample.
So we compare the gap to the noise. We take the difference between the two medians, divide it by the combined spread of the two sessions, and read the result off this fixed rule:
| Separation | What the page says |
|---|---|
| 1.00 or more | Clearly different — the gap is at least as large as the noise |
| 0.40 to 1.00 | Possibly different — collect more samples |
| Below 0.40 | No meaningful difference at this sample size |
Spread is the standard deviation when the session saved one, or the interquartile range divided by 1.349 when it did not — that divisor converts an IQR into a comparable standard-deviation-like figure. If either session has fewer than ten valid samples, a "clearly different" result is downgraded to "possibly different", because a handful of keystrokes cannot establish a stable median. The full arithmetic is printed on the page so you can check it.
When two sessions cannot be compared at all
Each saved session records the browser, the platform and the measured timer resolution it ran under. If those differ, this page says so before anything else. Firefox without cross-origin isolation rounds its clock to a whole millisecond; Chromium-based browsers round far more finely. Comparing a session recorded under a 1 ms clock with one recorded under a 0.1 ms clock compares two clocks. Different machines add different scheduling behaviour, different background load and different display pipelines on top of that. In those cases the honest conclusion is that the comparison is not about keyboards.
How to record two sessions worth comparing
Change exactly one thing. Same machine, same browser, same window, same power state, same background applications, ideally minutes apart rather than days. Run the same test with a similar number of samples in both — thirty or more valid presses each is a reasonable floor. Then swap the single variable you actually care about: the other keyboard, the cable instead of the dongle, the other USB port, the game overlay turned off.
Rename both sessions as soon as you record them. Six unnamed runs from the same afternoon are indistinguishable a week later, and a comparison you cannot label is a comparison you cannot trust. If you want a broader picture, see why latency results vary between systems.
What a difference here does and does not prove
A clear difference means the browser observed consistently different input timing in the two runs, under the conditions each one recorded. If you controlled everything else, the change you made is the most likely explanation — but "most likely" is not "proved". Repeating both runs and getting the same direction twice is far stronger evidence than one pair of sessions.
A result of "no meaningful difference" is equally informative and often the more useful answer: it means that whatever you changed did not move the browser-observed timing enough to stand out from the variation already inside each run.
Reading the table: absolute, percent and direction
Absolute difference is the one that matters for input timing, because milliseconds are what you feel. Percentage change is there for scale — a 40% improvement sounds dramatic until you notice it is 0.4 ms on a number that varies by 1 ms between keystrokes. Read both together, and read them next to the sample counts: a large percentage from a twelve-sample run is a weaker claim than a small percentage from two hundred samples.
The direction column states the assumption being applied to each row, so nothing is judged silently. Where it says "no defined direction", the numbers are still shown — there is simply no honest way to call one of them better.
Related keyboard tests
Frequently asked questions
How do I get sessions to compare?
Run a test that saves a result, then run another one. The Keyboard Latency Test and the Keyboard Performance Test both save a session to this browser when you finish a run. Once two saved sessions exist, they appear in the two selectors on this page. Give each one a name such as "wired board" or "laptop on battery" so the comparison is readable later.
What does "clearly different" mean on this page?
It means the gap between the two medians is at least as large as the combined spread of the two sessions. We divide the difference in medians by the combined spread and read the result off a fixed three-band rule that is printed on the page along with the arithmetic. It is a transparent effect-size comparison, not a statistical significance test, and no p-value is calculated.
Can I use this to compare two keyboards?
Only in a limited sense. Both sessions measure browser-observed input timing, which includes your operating system, browser and machine load as well as the keyboard. If you record both sessions on the same machine, in the same browser, minutes apart, with nothing else changed, then a difference is more likely to be about the two keyboards. It is still not a hardware latency measurement.
Why does it warn me when the browsers or platforms differ?
Each saved session records the browser, platform and timer resolution it was measured under. Browsers coarsen their clocks by different amounts and schedule work differently, so two sessions recorded in different browsers or on different machines can differ by more than the keyboards ever would. When the page detects that mismatch it says so prominently, because such a comparison is not a keyboard comparison.
Where are my saved sessions stored?
In this browser only, in localStorage, under the key klt.history.v1. Nothing is uploaded and there is no account. Clearing site data, using a private window, or switching browser or device means the sessions are not there. The delete control on this page removes a single saved session immediately.
Why is there no p-value or confidence interval?
Because a p-value from browser timing samples would imply more rigour than the data supports. Keystroke samples are not independent draws from a stable distribution: background load, thermal state and typing rhythm all drift during a run. A ratio of the median gap to the combined spread is honest about what it is — a rough signal-to-noise check you can verify by hand from the numbers shown.