Keycode Info

How to use this keycode tool

1. Click anywhere on this page to make sure it has focus.
2. Press any key on your keyboard.
3. All the JavaScript event properties for that key appear instantly.

Why does key and code differ?

event.key reflects the character produced (affected by Shift or keyboard layout), while event.code identifies the physical key position regardless of layout — useful for game controls where you want the same physical key to work on any keyboard.

Why event.code matters so much for keyboard shortcuts and games

The distinction between event.key and event.code becomes concretely important the moment users on different keyboard layouts are involved. On an AZERTY keyboard, common in France, the physical key positioned where "A" sits on a QWERTY keyboard actually produces the letter "Q" — so event.key correctly reports "q" for a French user pressing that physical key, exactly reflecting what character actually appears on screen. event.code, in contrast, reports "KeyA" regardless of keyboard layout, since it identifies the physical key's fixed hardware position rather than the character it currently produces. This is precisely why game controls (WASD-style movement, for instance) should generally bind to event.code rather than event.key — a game wants the same relative physical key positions to control movement consistently for every player, regardless of which keyboard layout or language that specific player happens to be typing in.

Why the same physical-looking key can report different location values

Several keys exist in more than one physical position on a standard keyboard — Shift, Ctrl, and Alt each commonly appear on both the left and right sides, and Enter, along with several digit and operator keys, appears a second time on the numeric keypad. The event.location property exists specifically to distinguish between these duplicate physical keys when event.code or event.key alone wouldn't tell them apart clearly enough for an application that genuinely needs to know which specific one was pressed. This matters for things like distinguishing a left-Shift-triggered shortcut from a right-Shift-triggered one, or correctly recognizing that a "1" came from the number row versus the numeric keypad — a distinction some specialized applications, particularly games and numeric data-entry tools, genuinely rely on getting right.

Modifier keys and why checking them correctly requires more than one property

Detecting whether Shift, Ctrl, Alt, or Meta (the Cmd key on Mac, Windows key on PC) was held down during a keypress requires checking the corresponding boolean properties directly on the event object (event.shiftKey, event.ctrlKey, event.altKey, event.metaKey) rather than trying to infer it from event.key or event.code alone. This matters specifically for building correct cross-platform keyboard shortcuts, since conventional modifier choice differs by operating system — Ctrl is the standard modifier on Windows and Linux, while Cmd (Meta) fills that same functional role on Mac — meaning a shortcut handler that only checks ctrlKey will silently fail to trigger its shortcut for Mac users who correctly press Cmd instead, unless the application code explicitly checks for both modifiers depending on the detected platform.

Why event.keyCode was deprecated — inconsistency across browsers and layouts

event.keyCode represents a numeric code for the pressed key, but it was deprecated in the web standards specification for genuinely good reasons rooted in real historical inconsistency. Different browsers, and different keyboard layouts within the same browser, sometimes assigned meaningfully different numeric codes to what a developer would consider the "same" key, making keyCode an unreliable foundation for keyboard handling logic that needed to behave identically and predictably across a wide range of environments. event.key and event.code were introduced specifically to replace it with clearer, standardized, and far more predictable string values instead of these inconsistent legacy numbers — modern code should prefer them, even though keyCode remains supported in all major browsers today purely for backward compatibility with older existing code that still depends on it.

Limitations of this tool

This tool displays the raw JavaScript keyboard event properties (key, code, keyCode, which, location, and modifier states) exactly as your specific browser reports them for whatever key you press — since browser and operating system behavior can genuinely differ at the margins for certain unusual or special keys, results may vary slightly across different browsers or platforms for those specific edge cases. It captures standard physical keyboard input specifically — it doesn't capture input from on-screen virtual keyboards, IME (Input Method Editor) composition used for typing certain non-Latin languages, or other alternative, non-physical-keyboard text input methods.