The Devs Tools

Developer's Guide to Keycode Info: Best Practices and Examples

August 18, 2026 · The Devs Tools Team

Handling keyboard input correctly in JavaScript means understanding that a single KeyboardEvent exposes several different, easily confused properties describing the key that was pressed. The key property reports the character or logical key name the browser resolved after applying the user's active keyboard layout and modifier state — pressing Shift+A gives key: "A", while an unshifted a gives key: "a". The code property, by contrast, reports the physical position of the key on the keyboard, independent of layout or modifiers — the key physically labeled "A" always reports code: "KeyA", whether the active layout is QWERTY, Dvorak, or AZERTY, and regardless of Shift state. The older which and keyCode properties return a numeric code and are considered legacy — they predate standardization across browsers and behave inconsistently for some keys, which is why modern code should prefer key and code instead. Finally, location distinguishes keys that appear more than once on a keyboard, such as the left and right Shift keys or the numeric keypad's Enter key versus the main Enter key. Choosing the wrong property for a given task is a common source of subtle keyboard-shortcut bugs, especially for applications used internationally where keyboard layouts vary widely.

[!TIP] Need to inspect exactly what a key press reports? Try our free, local Keycode Info to view live keyboard event properties completely offline.

key vs. code: Pick Based on Intent

  • Use key when you care about what character or logical action the user intended — for example, detecting whether the user typed "?" to open a help dialog, since that depends on their actual layout and Shift state.
  • Use code when you care about physical key position regardless of layout — for example, WASD movement controls in a game should bind to KeyW, KeyA, KeyS, KeyD by physical position, not to whatever character those keys happen to produce under a non-QWERTY layout, or the controls silently break for those users.
window.addEventListener("keydown", (e) => {
  console.log(e.key);   // "a", "A", "?", "Enter", "ArrowUp"...
  console.log(e.code);  // "KeyA", "Digit1", "Enter", "ArrowUp"...
});

Note that for non-alphanumeric keys like Enter, Escape, or the arrow keys, key and code often report similarly-named values — the distinction matters most for character keys affected by layout and modifiers.

Modifier Keys and location

Every keyboard event also carries boolean modifier flags — ctrlKey, shiftKey, altKey, and metaKey (the Cmd key on macOS, Windows key elsewhere) — which is how shortcut handlers detect combinations like Ctrl+S or Cmd+K. The location property adds precision when a physical key exists in more than one place: 0 for standard keys, 1 for the left-side variant, 2 for the right-side variant, and 3 for the numeric keypad. This matters if your application needs to distinguish, say, the numpad Enter key from the main Enter key, or bind a shortcut specifically to the right Shift key.

Common Pitfalls

  • Using key for physical-position shortcuts: binding game controls or layout-independent shortcuts to key instead of code breaks for users on non-QWERTY layouts.
  • Relying on which/keyCode: these are deprecated, numeric-only, and inconsistent across older browsers — prefer key and code, which are both strings with clear, standardized meanings.
  • Forgetting location: treating all Shift or Enter presses as identical can cause bugs in interfaces that intentionally differentiate left/right modifiers or numpad input.

Conclusion

key, code, which, and location each answer a different question about a keypress — what character, what physical position, what legacy numeric code, and which instance of a duplicated key. Picking the property that matches your actual intent, rather than whichever one happens to work in casual testing, is what keeps keyboard handling correct across layouts and devices.