JavaScript Keycode Finder

What event.key and event.code Report and How They Differ

Keyboard events report more information than most developers realise, and picking the wrong property is why a shortcut works on your machine and fails on a colleague. This tool listens for a keydown and shows every value the browser exposes: event.key, event.code, the deprecated keyCode and which numbers, the physical location index, and the state of the Ctrl, Shift, Alt and Meta modifiers. You click the capture area and press a key. Developers building keyboard shortcuts, game authors mapping controls, and anyone implementing accessible navigation with arrow keys and Escape all need to know precisely what arrives in the handler rather than what they assume arrives. The distinction that matters is between what a key produces and where a key sits. event.key reports the produced character or action, so it respects the keyboard layout and any modifiers: pressing the A key gives the string a, and holding Shift while pressing it gives A. event.code reports the physical key position using a fixed naming scheme based on a US layout, so that same key reports KeyA whether the user has QWERTY, AZERTY or Dvorak configured. The practical rule is to use event.code for shortcuts tied to a hand position, such as WASD movement in a game, and event.key for anything about text or named actions like Enter and Escape. The location property disambiguates duplicated keys, telling you whether Shift came from the left or right side and whether a digit came from the main row or the numeric keypad. Press a few keys and the pattern becomes clear. Press the letter a on its own and event.key is a, event.code is KeyA, the legacy keyCode is 65 and no modifier flags are set. Hold Shift and press the same physical key: event.key changes to A, but event.code stays KeyA because the physical key has not moved, and shiftKey is now true. Press Enter on the main keyboard and event.key is Enter with event.code also Enter and keyCode 13; press Enter on the numeric keypad instead and event.key is still Enter but event.code becomes NumpadEnter. That last pair is exactly why event.code exists: two keys, one meaning, distinguishable only by their code. Try the arrow keys as well and you will see ArrowUp reported identically in both key and code, which is why arrow-key navigation is one of the few cases where either property works safely. Real uses. A developer building a command palette binds Ctrl plus K by checking event.ctrlKey together with event.key, and discovers on a Mac they also need metaKey for the Cmd variant. A game author maps WASD with event.code so a French AZERTY user does not end up steering with ZQSD. Someone adding accessibility to a modal listens for event.key equal to Escape, which is layout-independent and correct everywhere. A form developer needs Enter to submit but Shift plus Enter to insert a newline, which requires reading both key and shiftKey in the same handler before deciding. Two cautions. keyCode and which are shown for reference because you will meet them in older tutorials and legacy codebases, but they are deprecated and inconsistent across layouts, so do not reach for them in new work no matter how many Stack Overflow answers still use 13 for Enter. The other pitfall is assuming Ctrl is universal: macOS uses Cmd, which surfaces as metaKey rather than ctrlKey, so a shortcut checking only ctrlKey silently does nothing for Mac users. Test both, or normalise the two into one check. Note also that browsers reserve some combinations for themselves, such as Ctrl plus W to close a tab, so your handler may never receive them at all no matter how you register the listener. Detection runs entirely in your browser and no keystroke is logged, stored or transmitted anywhere.

🔥 Trending Tools