The JavaScript KeyboardEvent.code field is the browser-reported identifier for the physical position of a key on a keyboard, and it stays stable across keyboard layouts and modifier states. When a developer searches for "the code for my car key," they almost always mean this property, not the number stamped on a metal car key blank — those are two very different questions. A real automotive key has a cut code etched on the bow, recorded by the dealer, or stored with a locksmith, and that physical code is matched against the ignition cylinder by a locksmith or the dealership's database. A web developer's "car key" question, by contrast, usually points at a shortcut handler, a game input, or an accessibility control that needs to know which physical key the user pressed. That distinction matters because KeyboardEvent.code returns values like KeyW, Digit2, ArrowLeft, or NumpadEnter, while KeyboardEvent.key returns what that physical position produced after layout and Shift were applied — for example 2 versus @, or ArrowLeft versus its named action. The JavaScript Key Code Finder is built to show both fields side by side from a single focused keydown, so you can stop guessing and inspect the exact values your browser emits.
What the JavaScript Key Code Finder actually captures
The tool listens to exactly one keydown event inside a deliberately focused capture area, then renders the values developers most often need for shortcut handlers, game input, accessibility controls, and input diagnostics. Nothing typed outside the bordered area is observed, no global listener is installed, and no event history is kept — only the latest event is held in React state until the page changes or reloads. That keeps the tool safe for everyday debugging without exposing passwords, recovery codes, or other secrets, because the page never uploads a keystroke to a server; there is no server round-trip in the capture path.
You can press a letter, number, navigation key, modifier, function key, or numpad key and immediately see key, code, location, the active modifiers, the repeat flag, the composing flag, and the legacy numeric keyCode. The capture area remains keyboard accessible, so Tab moves focus away instead of trapping you, and other keys only lose their default action while the capture target is focused — Space and arrow keys will not scroll the page during inspection.
How to inspect any key with the JavaScript Key Code Finder
The four-step workflow below mirrors the verified operating steps of the tool. It is the fastest way to settle arguments about whether a key reports KeyW or KeyA, whether a layout produces 2 or @, or whether keyCode returns anything meaningful at all.
- Click or tab to the bordered capture area. The area has a visible border so you can confirm focus before pressing anything. Focusing other page elements intentionally disables capture so normal typing is unaffected.
- Press the key or combination you want to inspect. A single tap is enough. Holding a key produces additional events with repeat: true, and pressing a dead key produces a composing: true event followed by the composed character — both useful for IME and auto-repeat testing.
- Compare key for meaning with code for physical position, then review location and modifiers. On a US layout, the same physical key reports 2 when unmodified and @ when Shift is held, but the code field stays Digit2. Location tells you whether the Enter came from the main keyboard, the numpad, or a side-specific Control or Alt.
- Copy the JSON only as a diagnostic and test the real target browsers and layouts. The formatted JSON record is convenient for a bug report or a local test fixture, but a single in-browser inspection cannot replace compatibility testing on the actual layouts, operating systems, browsers, assistive technologies, and input methods your feature supports.
How key, code, and the rest of the event relate
The two most important fields answer different questions, and the rest of the captured record fills in the edge cases that catch handlers in production. The table below summarises the contrast that the W3C UI Events specification makes between meaning and physical placement.
| Question | key | code |
|---|---|---|
| Reflects the current keyboard layout? | Yes | No |
| Changes when Shift is held? | Yes (for example 2 → @) | No (stays Digit2) |
| Identifies a physical key position? | No | Yes (for example KeyW, Digit2) |
| Best for character-based shortcuts? | Yes | No |
| Best for layout-independent shortcuts such as WASD movement? | No | Yes |
location distinguishes standard, left, right, and numpad variants of the same logical key, which matters for Shift, Control, Alt, Meta, Enter, and the numeric keys because each can exist in more than one place on a real keyboard. The modifier list reflects only the modifier state included in the current event, not a global history of every key the user has pressed. repeat becomes true when the operating system or browser emits repeated keydown events while a key is held — useful when you want to throttle autorepeat in a game or scroll handler. composing indicates that an input method editor or a dead-key sequence may still be producing text, which is the strongest signal that a shortcut handler should wait until composition ends before acting.
Choosing between key, code, and keyCode in production code
Match the field to the question your feature is actually asking. The matrix below condenses the practical guidance that MDN documents for KeyboardEvent.keyCode together with the W3C UI Events definitions of key and code.
| Scenario | Recommended field |
|---|---|
| Detect Ctrl+S to save, regardless of layout | code (for example KeyS) plus a modifier check |
| WASD movement in a game where the user's layout may be non-QWERTY | code with location confirmation |
| Distinguish numpad Enter from main Enter | code (or key) together with location |
| Capture the typed character for a text field | key (and input events when possible) |
| Wait for an IME composition to finish | key plus the composing flag |
| Diagnose a legacy library that still reads keyCode | keyCode only as a diagnostic, never in new code |
The tool shows keyCode for compatibility diagnosis only. UI Events does not define reliable modern values for it, MDN marks it deprecated and implementation-dependent, and printable-key behavior has differed across browsers and layouts for years. New code should use key or code, backed by feature-specific tests. Do not infer ASCII, Unicode, or a typed character from keyCode: a returned value of zero does not necessarily mean that no key exists — it can also mean the legacy property cannot identify the key that was pressed on that browser or layout.
Limits, mobile keyboards, and real-device testing
Browser-reserved shortcuts, operating-system shortcuts, accessibility technology, password managers, remote desktops, and input methods can all intercept events before a page ever sees them, so a handler that works in a quiet local browser can silently fail in production. Mobile virtual keyboards may expose fewer code values because no physical key position exists to report — a soft keyboard's code field can be empty or a coarse label. Input method editors fire composing: true while a sequence is in progress, so any shortcut that would mutate document state should defer until composition ends.
For automated tests, construct KeyboardEvent fixtures carefully because synthetic events are not trusted user input and may not reproduce native platform behavior. A compact set of eight standard-derived fixtures is enough to cover letters, shifted digits, left and right Alt, numpad Enter, and dead-key composition, while four unique location labels can be asserted independently. Even with good fixtures, real devices remain the final compatibility check: test the exact layouts, operating systems, browsers, assistive technologies, and IMEs your feature supports. Always provide an alternate clickable control for essential shortcuts, document known conflicts, and never make a single physical keyboard layout the only way to complete a critical action.
Because the capture area retains only the latest event locally, you can rerun any inspection as many times as you like without leaving a trace on a server — the JavaScript Key Code Finder exists to make a property you can already read in DevTools faster to read, with a layout-aware record you can paste straight into a bug report.