What’s the keyCode for the spacebar again?
- But here’s the catch: you probably shouldn’t be using
keyCodeat all anymore. Press the spacebar in this tool and you’ll see four different ways the browser describes that one keypress, and only two of them are the ones you actually want in 2026.
Wiring up a keyboard shortcut is one of those tasks that looks trivial until you open the console and start logging events. event.key? event.code? keyCode? which? They all return something, they’re all subtly different, and picking the wrong one means your shortcut breaks the moment someone switches to a French keyboard. This finder shows every property side by side for whatever key you press, so you can stop guessing.
How it reads your keypress
There’s a single keydown listener on the window. Hit a key and the big panel up top shows the resolved character, while the table underneath breaks out each property: event.key, event.code, keyCode, which, location, and whether it’s a repeat from holding the key down. The four modifier chips (Ctrl, Alt, Shift, Meta) light up live, so you can confirm that, yes, Cmd+Shift+P really does fire all the booleans you expect.
A small history keeps your last 12 keys. Handy when you’re testing a sequence and want to scroll back. Copy any single value with the button next to it, grab the whole event dump with Copy all, or download it as a text file to paste into a bug report.
key vs code vs keyCode
These trip people up constantly, so here’s the plain version.
event.key is the character the key produces. Press Shift+A and you get "A". Press it without Shift and you get "a". It respects the layout and the modifiers, which is exactly what you want for text input.
event.code is the physical button, independent of layout. The key where QWERTY puts Q always reports "KeyQ", even on an AZERTY board where it types an A. This is the one you want for game controls and WASD movement, because it maps to position, not letter.
keyCode and which are the old numeric codes (32 for space, 13 for Enter, 65 for A). Both are flagged deprecated in the spec. They still work everywhere and probably will for years, but the MDN guidance is clear: write new code against key and code. The tool tags those two rows so you don’t forget.
One quick gotcha worth knowing. Holding a key fires keydown over and over, and event.repeat flips to true on those extra events. If your shortcut feels like it’s triggering a dozen times, that’s why. The history list here ignores repeats so it doesn’t flood.
FAQ
Why is keyCode deprecated if it still works?
Because it was never standardized cleanly across browsers and didn’t handle non-US layouts or international input well. The replacements, key and code, are properly specced. Old code keeps running, but new code should use the modern properties.
Which property should I use for a keyboard shortcut?
Use event.code when you care about physical position (think WASD or a key in a fixed spot). Use event.key when you care about the actual character a user typed. Reach for keyCode only when supporting an ancient browser, which is rare now.
Does Ctrl+W or Cmd+Q get captured?
The page calls preventDefault() so it can read most combinations, but some shortcuts are owned by the browser or OS and close the tab before JavaScript ever sees them. Cmd+Q and Ctrl+W are common escapees.
Why do dead keys or IME input look weird?
On some layouts a single physical press starts a composition (accents, CJK input). The key value may show "Dead" or "Process" until composition finishes. That’s expected, and it’s a good reason to handle text via input events rather than raw keydown.
Is anything sent to a server?
Nope. It’s a plain client-side keydown listener. Nothing you press leaves the page.
Can I tell left Shift from right Shift?
Yep. Check event.code (ShiftLeft vs ShiftRight) or the location field, which reports 1 for left and 2 for right. The plain key value just says "Shift" for both.