JavaScript Keycode Explorer

Press any key to instantly see event.key, event.code, keyCode, charCode, location, repeat, and modifier states. Ready-to-copy JS snippet. Runs in your browser, no setup.

Runs in your browser
Your data never leaves your browser
Free · No Sign-Up

Capture pad Click the pad, then press a key; it also takes focus on first load. Tab, Space, Backspace, arrows and F1–F12 prevent their default actions here. Some browser or system shortcuts never reach the page.

Click here, then press any key

⌨

0 keys captured

Event properties

Read the raw key, physical code, legacy keyCode/which/charCode, location, repeat and isComposing values from the latest keydown. The legacy numeric properties are deprecated.

event.key —

event.code —

keyCode (deprecated) —

which (deprecated) —

charCode (deprecated) —

location —

repeat —

isComposing —

Modifier keys

Shift, Ctrl, Alt and Meta indicators reflect the modifiers on the latest captured keydown. They update on the next captured key.

Shift Ctrl Alt Meta

Ready-to-copy JS snippet

The snippet matches event.key and the captured modifiers. It changes immediately with each captured key; it does not use event.code.

Recent keys

Recent keys keeps the latest eight captures, newest first. The pad count includes every capture since Clear.

Read the full guide Why event.keyCode Lies to You: A Modern Guide to JavaScript Keyboard Events

Examples, details and FAQ Worked examples, how it compares with other tools, and answers to common questions.

event.key vs event.code vs keyCode

Most front-end keyboard bugs come from mixing these three. Use this table as a reference:

Property	Layout-aware	Recommended	Example for A on QWERTY
event.key	Yes (reflects active layout)	Yes — semantic checks	”a” or “A” with Shift
event.code	No (physical position)	Yes — game / shortcut bindings	”KeyA”
keyCode	No	No — deprecated	65
which	No	No — deprecated	65
charCode	No	No — deprecated, 0 on keydown	0

Common Use Cases

Debugging keyboard handlers — paste the exact event.key into your conditionals to fix typos.
Building game controls — prefer event.code so WASD works on AZERTY layouts.
Wiring command palettes — combine event.key with e.ctrlKey / e.metaKey checks.
Auditing legacy code — read keyCode / which to map old handlers to event.key.
Identifying composing state — e.isComposing = true means an IME is active, so single-key handlers should bail out.

Preventing Default Behavior

The capture pad calls preventDefault() only on Tab, Space, Backspace, Arrows, and F1-F12 — keys the browser would otherwise consume for navigation or page actions. System shortcuts like Ctrl+W / Cmd+Q are not intercepted; they continue to do their default thing.

Keyboard Layouts and Input Methods

event.code names the physical key after its position on a US keyboard. The UI Events KeyboardEvent code Values spec lists “KeyQ” as the key labelled q on a US keyboard and a on a French AZERTY keyboard. So on AZERTY, typing a gives key: “a” and code: “KeyQ”. Use code for shortcuts that depend on where a key is (WASD movement) and key for shortcuts that depend on what the key types (Ctrl+Z for undo).

Japanese and Korean keyboards add keys that a US keyboard does not have: “IntlYen”, “IntlRo”, “NonConvert”, “Convert” and “KanaMode” on a Japanese 106/109 keyboard, and “Lang1” (한/영) and “Lang2” (한자) on a Korean keyboard. Press them on the pad to see the values your browser reports.

While an input method is composing text, UI Events sets keyCode to 229 on keydown and the event has isComposing: true. Check isComposing before you act on Enter, or the key that confirms a Japanese or Chinese conversion will also submit your form.

Limits

On phones and tablets, on-screen keyboards usually send an input event with the typed text instead of a full keydown. The fallback field below the pad shows that text as key and leaves code, keyCode, which and charCode empty, because the input event does not say which key was used.
The browser and operating system keep some shortcuts, such as Ctrl+W or Cmd+Q, so the page never sees them.

FAQ

What's the difference between event.key, event.code, and keyCode?

event.key is the printable character or named key value after the keyboard layout is applied (so the 'A' key on a Dvorak layout reports event.key = 'a' even though the physical position is different). event.code is the physical key position on a standard US QWERTY layout (KeyA, Digit1, ArrowUp) and stays constant regardless of layout. keyCode is the legacy numeric code (e.g. 65 for A) — it's deprecated but still emitted for backward compatibility.

Why are keyCode, which, and charCode deprecated?

All three are inconsistent across browsers and ambiguous for non-Latin layouts. Modern code should use event.key (semantic) or event.code (physical). The MDN spec marks keyCode and charCode as 'deprecated, not recommended for production' but mainstream browsers still emit them for compatibility — this tool shows the raw values so you can audit legacy code.

How do I check for Shift / Ctrl / Alt / Meta modifier keys?

Read e.shiftKey, e.ctrlKey, e.altKey, and e.metaKey directly on the KeyboardEvent — each is a boolean reflecting whether the modifier was held while the key fired. Note: e.metaKey is the Windows / Command key. The generated snippet on this page composes the right modifier clause for you.

Does this work on mobile?

Physical keyboard events differ across mobile platforms — many on-screen keyboards do not emit keydown for individual characters and you only get an 'input' event with the resulting string. This tool is built for desktop browsers where physical key signals are reliable. A mobile fallback input is available for partial readout, but for full event property inspection use a desktop browser. By design, no mobile-keydown emulation is attempted.

Is any keypress data sent to a server?

No. All event handling runs in your browser via the KeyboardEvent API. Nothing about which key you pressed leaves your device. Open DevTools → Network to confirm.