JavaScript Key Code Tester

Keyboard shortcuts, game controls and form shortcuts all start from the same browser event: keydown. Its properties describe the key in several different ways, and picking the wrong one is why shortcuts work on your keyboard and fail on a colleague’s. This tester shows every property for any key you press, builds a shortcut name and generates the handler code.

The properties that matter

event.key is the meaning of the key press: the character it produced, such as "K" or "a", or a name for non-printing keys such as "Enter", "Escape" or "ArrowLeft". event.code is the physical key, such as KeyK, Digit1 or ArrowLeft, regardless of layout. event.location says which copy of a key it was: 0 for standard, 1 for the left Shift, Ctrl, Alt or Meta key, 2 for the right one, and 3 for the numeric keypad.

Modifiers, repeat and composition

The boolean fields ctrlKey, shiftKey, altKey and metaKey tell you which modifiers were held. On macOS the Command key is metaKey, on Windows the Windows key is. repeat is true when the event comes from holding a key down. isComposing is true while an input method is building a character, such as when typing Japanese, and handlers should normally ignore those events.

Why keyCode is deprecated

keyCode and which are old numeric codes, and the standards now mark them deprecated. The numbers are not consistent: the same key can have different values between browsers, between keydown and keypress, and between layouts, and letters on the top row differ from the numeric keypad. They remain in the tester because old code still uses them and you may be reading a handler that checks for 13 or 27, but new code should use key or code.

Choosing key or code

Use event.key for shortcuts that depend on meaning, such as Ctrl+S for save or ? for help, because the character is what the user expects whatever the layout. Use event.code for controls that depend on position, such as the WASD cluster in a game, because on AZERTY the same physical keys are labelled ZQSD but still report KeyW, KeyA, KeyS and KeyD.

A worked example

Click the box, hold Shift and press K. The page shows the shortcut Shift+K, event.key as "K", event.code as KeyK and keyCode as 75, with only shiftKey set. The generated handler reads if (e.shiftKey && e.code === 'KeyK') { followed by e.preventDefault();, ready to paste into a keydown listener on document. Releasing the key adds a keyup row when that option is on.

Shortcuts a page cannot receive

Some combinations never reach web content. Browsers and operating systems keep Ctrl+W, Ctrl+T, Ctrl+N, Alt+F4, Cmd+Q, the Windows key combinations and many function keys to themselves. A page also cannot override them, and trying to take common ones over, such as Ctrl+F, annoys people. Choose shortcuts that avoid the browser’s own, and let users see and change them.

Accessibility

Custom shortcuts should not be the only way to do something, should not interfere with screen readers or with single-character shortcuts typed in text fields, and ideally can be turned off. WCAG 2.1 criterion 2.1.4 asks for a way to turn off or remap shortcuts made only of letters, punctuation or numbers.

Privacy

Key presses are read in the page only while the box has focus, and they are never sent anywhere or stored.

Related tools

• User-Agent Parser identifies the browser and operating system behind unusual key values.
• Browser Storage Inspector checks what a web app can save between visits.
• ANSI Escape Codes explains the control characters terminals receive from keys.
• HTML Accessibility Checker finds elements that keyboard users cannot reach.