Understanding Keyboard Event Properties in Web Development
When a user presses a physical key, modern web browsers generate a KeyboardEvent containing distinct properties that describe the action. The Keyboard Test tool captures these events in real time and exposes three primary identifiers in the "Latest key event" readout: "Key", "Code", and "Legacy keyCode".
These properties serve different purposes for developers building web applications or browser-based games:
KeyboardEvent.key: This value represents the character or action produced by the key press. It is dynamic and adapts to the active keyboard layout, language settings, and modifier states. For example, pressing the physical "A" key on a standard QWERTY layout yields "a", but holding Shift changes the value to "A".KeyboardEvent.code: This value represents the physical position of the key on the keyboard, completely independent of the active language layout or modifier keys. Pressing the physical "A" key always outputs "KeyA", regardless of whether the operating system is set to QWERTY, AZERTY, or another layout.KeyboardEvent.keyCode: This is a legacy numerical identifier used in older web applications. While modern specifications deprecate its use in favor ofkeyandcode, many legacy systems still rely on these numeric codes for input handling.
The tool also tracks the physical "Location" of the key, categorizing it into "Standard", "Left", "Right", or "Numpad". This distinction is crucial for identifying whether a user pressed the left or right Shift key, or used the number keys on the dedicated numeric keypad versus the main alphanumeric row.
Physical Layouts vs. Software Mapping
A common point of confusion during keyboard testing is the discrepancy between the physical key printed on the keyboard and the character that registers on the screen. This occurs because the operating system maps physical key codes to software-defined characters based on the active language layout.
The Keyboard Test tool visualizes this relationship by displaying both the static physical identifier ("Code") and the dynamic software output ("Key"). While the physical switch sends a constant hardware signal, the operating system translates this signal before it reaches the browser.
The visual keyboard map on the page is fixed to a standard full-size ANSI layout. Because of this design, certain keys—such as ISO-specific keys (like the extra key next to the left Shift on European layouts), laptop Fn layers, or dedicated media keys—will not light up on the visual map. However, these keys are still fully functional; when pressed, their technical properties register successfully in the "Latest key event" readout and are recorded in the "Event log".
Diagnosing Keyboard Hardware Failures
Keyboard Test serves as a diagnostic utility to distinguish between normal hardware behaviors and actual physical failures.
| Symptom | Observed Behavior in Tool | Likely Cause |
|---|---|---|
| Dead Key | No event registers in the "Latest key event" readout or the "Event log" when the key is pressed. | Broken switch, damaged membrane trace, or debris blocking the contact point. |
| Key Chattering | A single physical tap generates multiple "Down" and "Up" events in rapid succession within the "Event log". | Worn or dirty mechanical switch contacts causing double-registration. |
| Key Ghosting | Pressing multiple keys simultaneously prevents certain keys from registering. | Hardware limitation in the keyboard's internal matrix circuitry, failing to route concurrent signals. |
| Normal Auto-Repeat | Holding a key down displays a "Repeat" badge with an incrementing counter (e.g., "Repeat ×{count}"). |
Standard operating system behavior that continuously fires press events while a key is held. |
By monitoring the "Event log", users can analyze the exact sequence of "Down" and "Up" events to confirm whether a switch is operating reliably or failing under normal usage.
Browser Event Interception and Capture Modes
Web browsers operate within the security and functional boundaries of the host operating system. Consequently, certain key combinations reserved by the browser or OS—such as switching tabs, closing windows, entering full-screen mode, or triggering system search—are intercepted before they can be processed by the web page. These intercepted shortcuts will not register in the tool. To verify the physical functionality of these keys, users must test them individually rather than in combination.
To capture standard keys without triggering their default browser actions, the tool offers different capture states indicated by the Capture Status Indicator:
- "Press any key to begin": The default idle state before any input is detected.
- "Capturing key input": Active when keys are pressed anywhere on the page.
- "Full capture — Esc releases the keyboard": Initiated by clicking directly on the on-screen keyboard map. This mode captures keys like Space, Tab, and function keys, preventing them from executing default browser actions (such as scrolling the page or moving focus). Pressing the Esc key exits this mode.
Mobile Browser Input Challenges
Testing virtual or on-screen keyboards on mobile devices, particularly Android, presents unique technical challenges. Mobile operating systems handle text input differently than desktop platforms. Instead of sending discrete physical key events, virtual keyboards often rely on predictive text engines and input method editors (IMEs).
This software layer frequently results in generic events where the browser reports the key value as "Unidentified". To address this limitation, the tool includes a dedicated "On-screen keyboard check" area. This section features a text input field with the placeholder "Tap and type…" and the instructional hint "Tap the field and type — whatever the browser reports appears above.". This allows mobile users to verify what input data their browser actually transmits during active typing.
Privacy and Local Processing
The Keyboard Test tool processes all inputs locally within the user's web browser.
- Local Execution: Key presses are read only by the active web page to populate the visual map, statistics, and the "Event log".
- No External Storage: No data is stored or uploaded to external servers.
- Data Volatility: Clearing the log via the "Clear log" button or leaving/refreshing the page permanently erases all captured event data.
Frequently Asked Questions
Why don’t some key combinations show up?
Shortcuts reserved by the browser or operating system — closing or switching tabs and apps, full screen, system search — are intercepted before the page can see them, so they never appear here. That silence is normal, not a dead key: test the same keys one at a time and each will register on its own.
What is the difference between the key and code values?
The key value is the character or action the press produces right now — it changes with your layout and modifiers, so the same physical key reports “a” or “A”, or a different letter entirely on another language layout. The code value names the physical position (KeyA, ShiftLeft, Space) and never changes, which is why games and apps bind their shortcuts to code.
A key fires over and over while I hold it — is it faulty?
No. Holding a key makes the system send repeated press events, shown here with a Repeat badge and counter — that is normal auto-repeat. The real warning signs are the opposite pattern: several events from a single quick tap, or a tap that produces none, which points to a worn or sticking switch.
Why does my phone’s keyboard show “Unidentified”?
On-screen keyboards — especially on Android — often send generic events without real key values, and the page can only show what the browser reports. Open the on-screen keyboard check under the layout to see what your keyboard does send; an external or laptop keyboard reports full details.