Guide · Input
Key Rollover and Ghosting, Explained
By Device Bench · Published · Reviewed
When you hold a strafe, sprint, and jump together and one event never reaches the page, the missing input can come from matrix ambiguity, report format, firmware, transport, the operating system, or browser handling. This guide explains rollover and ghosting, then shows what a browser can observe without claiming it can see the hidden layer that dropped a key.
Rollover is a number, and you can read yours directly. Hold key combinations and watch the Held and Max rollover counters respond live — everything runs in your browser and nothing you press leaves your device.
What rollover actually measures
Rollover is the number of keys a keyboard can register simultaneously and report correctly. The naming convention is n-key rollover: a 2KRO board guarantees any two keys at once, a 6KRO board guarantees six, and NKRO — n-key rollover in the literal sense — means every key on the board can be held at the same time and each one still registers.
Every keyboard has some limit, and the limit is a property of two separate things: how the keys are wired inside the keyboard, and how the keyboard reports presses to the computer. Both matter, and they fail in different ways — which is why the same board can behave differently on different combinations. To understand either, you have to look at the wiring first.
How a keyboard matrix works
A full-size keyboard has over a hundred keys. Giving each one a dedicated wire to the controller would be expensive and bulky, so nearly every keyboard instead wires its keys into a grid: a set of row lines crossing a set of column lines, with one key switch sitting at each intersection. Pressing a key closes its switch and electrically bridges one row to one column.
The controller finds pressed keys by scanning: it energizes one row at a time and reads which columns carry current, then moves to the next row, sweeping the whole grid many times per second. If row 3 is energized and column 7 reads active, the key at that intersection is down. With one key held, this is unambiguous. The trouble starts when several keys are held at once, because current doesn't care about the controller's intentions — it flows through every closed switch it can reach.
Why ghosting happens — and why you rarely see a ghost
Picture three held keys whose intersections form three corners of a rectangle in the grid: two keys sharing a row, one of them also sharing a column with the third. When the controller energizes a row, current sneaks through the three closed switches in series and comes back up a line it was never meant to reach — making the fourth corner of the rectangle read as pressed. Electrically, that phantom press is indistinguishable from a real one. The keyboard cannot tell three real keys plus one ghost apart from four real keys. That phantom fourth key is ghosting in the original sense.
Matrix firmware can prevent a phantom key by suppressing an ambiguous combination instead of reporting the electrically plausible fourth corner. That produces the common symptom of a combination-specific omission rather than a visible ghost. It is one design response, not proof that every keyboard or every missing event used the same rule.
A diode in series with each switch blocks the reverse current path in the QMK example and lets that matrix distinguish its intersections independently. Per-key diodes address the electrical ambiguity; report format and firmware behavior remain separate limits between the matrix and the browser.
6KRO, NKRO, and why modifiers don't count
The classic USB boot-keyboard report format has six ordinary key slots plus modifier bits. A keyboard can use a different report format after the operating system loads, and its matrix, firmware, transport, operating system, and browser still determine which events reach this page. The six-slot format explains one possible six-key plateau; it does not let a browser prove that plateau's cause from the count alone.
An NKRO design needs the physical sensing, firmware, and report path to represent the intended combinations. Many laptop and compact-board Fn functions are handled inside firmware and the physical Fn press itself may not reach the operating system, though a resulting media or function action can. Testers can display only the events that arrive.
Rollover limits matter most for deliberate chords such as movement plus modifiers and action keys. The useful question is not whether a marketing label is large, but whether the combinations you actually use arrive reliably.
How to test yours
Open the keyboard tester and hold combinations down. The Held readout shows how many keys the browser currently sees, and Max rollover records the highest count reached in the session. Start with combinations that matter to you—movement keys plus Shift and Space, a rhythm-game chord, or a real shortcut—rather than assuming one synthetic spread represents the whole board.
Read the result as an observation. If Held stops climbing at six, the pattern is consistent with a six-slot report mode, but firmware, transport, operating-system, or browser handling can produce the same count. If one combination repeatedly omits a key while each key works alone, matrix ambiguity or firmware blocking is plausible, not proven. Compare another connection mode or the vendor's diagnostic before assigning the cause.
Test the combinations you actually use rather than chasing the biggest number. A board that blocks some exotic ten-key spread but handles every chord you play is, for you, a keyboard without a rollover problem. The measurement, not the spec sheet, is the answer.
A matrix example you can trace
The table below separates what the keyboard scans from what the browser receives. The ambiguous case is a rectangle of switches without a diode at every switch: three closed corners can make the fourth intersection electrically plausible. Firmware may suppress that fourth corner, which looks like a missing key, or report it, which is the classic ghost. A browser can record only the result of that decision.
| Closed positions | Matrix evidence | Browser consequence |
|---|---|---|
| R1C1 | One row-column intersection | One key event |
| R1C1 + R1C2 | Two intersections on one row | Two events if rollover permits |
| R1C1 + R1C2 + R2C1 | Three corners make R2C2 ambiguous without isolation | Firmware may suppress a real key or emit a ghost |
Sources and standards
QMK documents matrix scanning, ambiguous intersections, ghosting, and diodes; USB-IF publishes the HID specifications behind keyboard report formats; W3C defines only the keyboard events that reach a web page. The browser test can reveal an omitted or extra event, but not which earlier layer caused it.
- QMK: How a Keyboard Matrix Works — matrix scanning, ambiguous intersections, ghosting, and the role of diodes.
- W3C UI Events — the keyboard events a web page can observe after firmware has reported a key.
- USB-IF Human Interface Device specifications — the official USB HID specification and usage-table index behind keyboard report formats.
See a mistake or a changed standard? Report a correction.