How to See Exactly What Keycode a Key Press Sends

You’re building a keyboard shortcut handler and it’s not firing for a specific key, or it’s firing for the wrong one — and the fix requires knowing exactly what values the browser actually reports for that key press, not what you assumed they’d be. The key, code, and deprecated keyCode properties on a JavaScript keyboard event are easy to conflate, and getting the wrong one in a conditional check is a common, quiet source of bugs.

Different keyboard layouts, operating systems, and even browser versions can report these values slightly differently, which makes guessing risky — actually pressing the key and watching what fires is a faster path to a correct fix than reasoning from memory.

What keyboard events actually report

The key property reports the character or logical name the key represents (like “a” or “Enter”), which can change based on modifier keys like Shift. The code property reports the physical key’s position on the keyboard (like “KeyA”), which stays consistent regardless of layout or modifiers — useful when you care about which physical key was pressed rather than what character it produces. The older keyCode property, a numeric code, is deprecated but still shows up in legacy code and needs to be understood when maintaining it. Location and active modifier keys (Shift, Ctrl, Alt, Meta) round out the full picture of what a single key press actually communicates to JavaScript.

Choosing the wrong property for a given use case is a subtle, common source of keyboard handler bugs — a shortcut checking key when it should check code (or vice versa) can behave differently across keyboard layouts in ways that are hard to reproduce without physically testing on a different layout.

Why people get stuck here

• key, code, and keyCode are easy to conflate. They serve different purposes — logical character, physical position, and legacy numeric code — and using the wrong one produces bugs that only show up in certain layouts or contexts.
• Keyboard layout differences aren’t obvious from documentation alone. A handler that works correctly on a QWERTY layout might behave unexpectedly on a different layout, and that’s hard to predict without actually testing.
• Modifier key state matters and is easy to overlook. A shortcut handler that doesn’t correctly check active modifiers can fire when it shouldn’t, or fail to fire when it should.
• Cross-browser inconsistencies exist for some edge-case keys. Certain keys have historically had inconsistent reporting across browsers, which is easier to catch by testing directly than by assuming spec compliance.

What a good keyboard event tester looks like

Reports key, code, keyCode, and location together

Seeing all the relevant properties for a single key press side by side makes it immediately clear which one actually matches what your handler needs to check.

Shows active modifier keys live

Displaying Shift, Ctrl, Alt, and Meta state as they’re held helps verify a shortcut handler’s modifier-checking logic against real key combinations.

Updates in real time as you press keys

Immediate feedback lets you quickly test several keys and combinations in sequence without any setup per key.

Common mistakes to avoid

• Using keyCode in new code when key or code would be more appropriate and future-proof, since keyCode is deprecated.
• Checking key when you actually need layout-independent physical key position, which code reports instead.
• Forgetting that key values change with Shift or other modifiers, while code stays consistent regardless.
• Assuming a keyboard handler behaves identically across all layouts and browsers without actually testing it on more than one.
• Not accounting for modifier key state in a shortcut handler, causing it to fire in unintended combinations.

How to do it with Keyboard Event Tester

Online Tool Store’s Keyboard Event Tester reports a pressed key’s key, code, keyCode, location, and active modifiers live, entirely in your browser.

1. Press any key or key combination.
2. Review the reported key, code, keyCode, and location values.
3. Check which modifier keys are shown as active.
4. Use the exact reported values to fix or verify your keyboard event handler’s logic.

Because it reports every relevant property live as you press keys, you can confirm exactly what your handler will actually receive instead of guessing from documentation or memory.

Frequently asked questions

What’s the difference between key and code?

key reports the logical character or name the key represents, which can change with modifiers like Shift. code reports the physical key’s position on the keyboard, which stays the same regardless of layout or modifiers — useful when you need to identify which physical key was pressed.

Should I still use keyCode in new code?

Generally no — keyCode is deprecated in favor of key and code, which are more descriptive and reliable. It’s still useful to understand when maintaining legacy code that references it.

Why does my keyboard shortcut work on my keyboard but not someone else’s?

Different keyboard layouts can report different key values for the same physical key, so a handler checking key instead of the layout-independent code can behave inconsistently across layouts.

Final thought

Keyboard event debugging goes faster when you stop guessing at property values and just press the key and read what the browser actually reports. Match the right property to your actual use case, and cross-layout bugs get much easier to catch.

Try the free Keyboard Event Tester