Press any key inside a JavaScript Key Code Finder's focused capture area and the tool returns the standard KeyboardEvent fields developers need for shortcut handling, game input, and accessibility diagnostics: key (the layout-aware character or named action), code (the layout-independent physical key), location (left, right, standard, or numpad), the modifier list, the repeat flag, the composition flag, and the deprecated numeric keyCode for compatibility diagnosis. This is a practical way to inspect what the browser actually reports, because KeyboardEvent values depend on the active keyboard layout, the operating system, the browser engine, and any input method editor that may be active at the moment the key is pressed. Rather than guessing at numbers or relying on outdated ASCII tables, you get the exact property values the browser assigns to that single keydown event in your current environment. The capture area is local and ephemeral: only the latest event is retained, no history is recorded, and nothing is uploaded, which makes the tool safe to use while debugging real shortcut handlers.
What the JavaScript Key Code Finder Captures
A focused JavaScript Key Code Finder listens for one keyboard event inside a deliberately focused test area and maps that single keydown to the values developers commonly need. It shows the modern key and code fields, the location property, the active modifier list, the repeat flag, the composing flag, and the legacy numeric keyCode for compatibility diagnosis. The page records only the most recent event and never installs a global listener, so typing outside the capture area is never observed.
That narrow scope is intentional. A keyboard diagnostic should never see passwords, recovery codes, or other secrets, and the tool is designed so that confidential input is never required to exercise it. Press a letter, number, navigation key, modifier, function key, or numpad key and the corresponding KeyboardEvent object is displayed in place. Nothing is sent to a server, so you can safely use the same browser tab while the rest of your development environment stays logged in.
Why a Live Inspector Beats Static Tables for KeyboardEvent Work
Static references cannot answer the question "what does pressing my key produce right now, in this browser, on this layout, with these modifiers held". The key and code fields answer different questions. key represents the meaning produced after the current keyboard layout and modifier state are applied. On a US layout the same physical key may report 2 or @ depending on Shift, and other layouts can report a completely different character. code represents the physical key position, such as Digit2 or KeyW, and normally stays stable across layout changes.
The legacy numeric keyCode is shown only for compatibility diagnosis. According to the MDN KeyboardEvent.keyCode reference, keyCode is deprecated and implementation-dependent, and the W3C UI Events specification does not define reliable modern values for it. Printable-key behavior has historically differed across browsers and layouts, so new code should use key or code with feature-specific tests rather than inferring ASCII, Unicode, or a typed character from keyCode. A live inspector lets you see exactly which of these three properties changed when you switched layouts, swapped browsers, or held a modifier.
How to Use the JavaScript Key Code Finder
Follow these steps to inspect any key combination without leaving the browser.
- Click or tab to the bordered capture area so it has focus.
- Press the key or combination you want to inspect, including any modifier you want to verify at the same time.
- Compare key for layout-aware meaning with code for physical position, then review location, the modifier list, the repeat flag, and the composing flag.
- Copy the displayed JSON record only as a diagnostic for a bug report or local test fixture, and verify the same shortcut on the real target browsers, layouts, operating systems, and input method editors your feature supports.
Reading the Output: key, code, and the Legacy keyCode
The three fields that usually cause confusion sit on the same line. The table below summarizes how they differ in practice for one keydown captured inside the test area.
| Property | What it represents | Depends on layout? | Status |
|---|---|---|---|
| key | Meaning of the key after layout and modifiers are applied, such as a, A, Shift, or ArrowUp | Yes | Recommended for shortcuts that follow a character or named action |
| code | Physical key position, such as KeyA, Digit2, or ArrowUp | No, in normal use | Recommended when placement matters, such as WASD movement or numpad handling |
| keyCode | A legacy numeric identifier | Implementation-dependent | Deprecated; do not use in new code, and do not infer ASCII or Unicode from it |
A reading of 0 from keyCode does not necessarily mean that no key exists; it can mean the legacy property cannot identify it. Treat any numeric value as diagnostic only, and prefer key or code in production handlers.
Modifiers, Location, Repeat, and Composition Flags
Four additional pieces of the same KeyboardEvent shape how a shortcut handler should respond. The modifier list (shiftKey, ctrlKey, altKey, metaKey) reports the state included in the captured event, not a global history of everything you have ever pressed. If a modifier does not appear in the list, the browser did not include it in this particular event, and your handler should branch on the value rather than assume a default.
The location property distinguishes standard, left, right, and numpad variants. This matters for Shift, Control, Alt, Meta, Enter, and numeric keys that can exist in more than one place, because a user pressing the right Shift and the left Shift should produce the same shortcut but may report different location values. The repeat flag becomes true when the operating system or browser emits repeated keydown events while a key is held, so a handler that triggers expensive work on every event should gate against repeat when appropriate. The composing flag indicates that an input method editor or dead-key composition may be producing text, so shortcut handlers should often avoid acting until composition is complete, particularly in fields that accept CJK or other IME-based input.
Common Pitfalls and What to Test Before Shipping
Browser-reserved shortcuts, operating-system shortcuts, accessibility technology, password managers, remote desktops, and input methods can all intercept events before a page receives them, which means a handler that works on a developer machine may never fire on a user's machine. Mobile virtual keyboards can expose fewer code values because no physical key position exists, so any feature that depends on code needs a touch fallback.
For automated tests, construct KeyboardEvent fixtures carefully because synthetic events are not trusted user input and may not reproduce native platform behavior. A standard set of fixtures covers letters, shifted digits, left and right Alt, numpad Enter, and dead-key composition, while the four unique location labels should be asserted independently. Real devices remain the final compatibility check: test the exact layouts, operating systems, browsers, assistive technologies, and IMEs your feature supports, document known conflicts, provide an alternate clickable control for essential shortcuts, and never make a single physical keyboard layout the only way to complete a critical action.
For a deeper look, see Properties to JSON: Escape Rules and Duplicate Key Handling.