Keyboard test

Two things this is for

Testing hardware. Press every key in turn. A key that produces nothing is not reaching the browser; a key that fires repeatedly on one press is chattering; a key that reports the wrong character has a layout problem rather than a hardware one.

Finding the right key code. If you are binding a shortcut and need to know what to compare against, press the key and read it off.

key, code and keyCode

Every key press carries three ways of naming what happened, and picking the wrong one is the single most common reason a shortcut works for its author and not for anyone else.

So:

• Binding to a character — a shortcut like Ctrl+S for save, where the letter is a mnemonic — use event.key. It follows the layout, which is what the user expects: S means save on every keyboard.
• Binding to a position — WASD movement in a game — use event.code. It follows the physical key, so the same shape of hand position works on AZERTY, QWERTZ and Dvorak.

Getting this backwards is why some browser games are unplayable on a French keyboard: they bound WASD to key, and on AZERTY those letters are in the wrong places.

Why keyCode is shown but should not be used

keyCode is deprecated in the UI Events specification and has been for years. It is still here because every browser still fires it and a great deal of existing code still reads it, so seeing the number is genuinely useful when debugging that code.

It should not be used in anything new. It conflates character and position, its values were never fully standardised across browsers, and it has no meaning at all for keys that produce no character.

Keys that never reach a web page

Some of the keyboard is not the page’s to see, and this is by design rather than a fault:

• System shortcuts. Cmd+Tab, Alt+Tab, Cmd+Space are taken by the operating system before any application sees them.
• Fn. On most laptops the Fn key is handled in the keyboard’s own firmware and never generates an event at all. The keys it modifies do.
• Browser shortcuts. Ctrl+T, Ctrl+W, Ctrl+N and the function keys that open developer tools are claimed by the browser. A page cannot override them, which is deliberate — a page that could intercept Ctrl+W could refuse to be closed.
• Media and hardware keys. Volume, brightness and keyboard backlight are handled below the browser.

If a key produces nothing here, check it in a text editor before concluding the keyboard is faulty.

Dead keys and input methods

On a layout with dead keys — the accent keys on many European layouts — the first press fires with key set to Dead and produces no character. The character appears only when the following key is pressed.

With a Chinese, Japanese or Korean input method active, keystrokes go to the IME first. event.key reports Process, and the text that eventually arrives comes through composition events instead. This is why a keyboard handler that only listens for keydown loses CJK input entirely, and why text fields should listen for input rather than assembling characters from key events.

Capturing Tab and the arrows

Those keys are off by default here. Tab moves focus and the arrow keys scroll, and a page that swallows them has taken keyboard navigation away from anyone who relies on it. Turn capture on to see them reported, and off again to use the page normally.

Everything stays in the browser

Key presses are read and displayed. Nothing is logged, stored or sent — which for a page that watches everything you type is worth stating plainly.