Keyboard Event Tester

key, code and keyCode: what each one actually means

event.key is the value the active keyboard layout produces — a character like "q", or a named value like "Enter", "ArrowLeft" or "Shift". It changes when the user switches layout, and it changes when a modifier is held: the same key gives "a" and "A".

event.code is the physical key position, named after where that key sits on a US QWERTY board. It does not change with the layout, the modifiers or the language. If you want WASD movement to work for a French user without remapping, code is the property you want.

One physical key, four layouts, one code.

Values shown are the unshifted event.key for a standard variant of each layout. Regional variants exist and can differ — press the key on your own machine and read the inspector above rather than trusting any table, including this one.

The third property, event.keyCode, is a legacy number. It predates both of the others, never behaved the same way in every browser, and is derived differently depending on the layout and the browser's compatibility rules. It is marked deprecated in the UI Events specification. Browsers still populate it for old code, but there is no reason to write new code against it.

Event order, and why keypress is deprecated

A single press of a character key normally produces keydown, then keypress, then keyup. Holding the key produces a stream of extra keydown events with repeat === true, at the interval your operating system's key-repeat setting defines — that is an OS setting, not a hardware property of the keyboard.

keypress is deprecated: it only fired for keys that produced a character, it never had consistent behaviour for modifier and function keys, and it does not handle text produced by input methods at all. For text input, listen to the input event on the field instead; for key handling, use keydown.

Modifier state is more than four booleans

ctrlKey, shiftKey, altKey and metaKey cover the common cases, but event.getModifierState(name) answers questions the booleans cannot. getModifierState('CapsLock') is how you detect the classic "your password looks wrong because Caps Lock is on" case. 'NumLock' and 'ScrollLock' report lock state the same way.

getModifierState('AltGraph') matters on European layouts, where AltGr produces characters such as @, € and #. On Windows, AltGr is commonly reported as Ctrl and Alt held together, so a shortcut bound to Ctrl+Alt+E can steal a character a German or Polish user was simply trying to type. Checking getModifierState('AltGraph') and bailing out is the fix.

Shortcuts a web page can never capture

Some key combinations are consumed before any web page sees them. When that happens there is no event to inspect and no event to cancel — preventDefault() has nothing to act on, because your handler was never called. Which combinations are reserved depends on the operating system, the browser and the user's own settings, so treat the table below as typical behaviour rather than a guarantee.

Combinations that do reach the page, such as Ctrl+S or Ctrl+P, can be intercepted with preventDefault() — but do it sparingly. Screen reader users depend on key combinations that look unremarkable to everyone else. Turn on shortcut capture above and try a few: anything that appears in the inspector is yours to claim, and anything that does not never will be.

Dead keys, IME composition and the 229 problem

A dead key produces no character on its own — it waits for the next keystroke to combine into an accented letter. Browsers usually report the dead key itself as event.key === "Dead", then deliver the composed character afterwards. Code that assumes one keystroke equals one character will mis-handle it.

Input method editors, used for Japanese, Chinese, Korean and other scripts, go further: a whole sequence of keystrokes belongs to an in-progress composition. While that is happening, event.isComposing is true, and many browsers report event.key as "Process" with the legacy keyCode set to 229. If your shortcut handler ignores that, pressing Enter to confirm a candidate word will also fire your "submit" shortcut. Guard with if (event.isComposing) return; and prefer the compositionstart and compositionend events when you need the boundaries. The scratch field above logs all three so you can see the real sequence your browser emits.

What event.timeStamp is and is not

KeyboardEvent.timeStamp is a DOMHighResTimeStamp on the same monotonic timeline as performance.now(), stamped when the browser creates the event object. Subtracting it from a performance.now() reading taken at the top of your handler gives you the browser-side queueing and main-thread scheduling delay — the handler delay figure in the inspector above.

It is not the moment the switch closed. Everything before the browser — the keyboard's own scanning and firmware, the USB or Bluetooth link, the OS input stack — is already finished by the time that number exists, and none of it is visible from JavaScript. Some engines also hand back an epoch-scale value instead of a page-relative one, which is why this page normalises the timestamp before showing it. The browser input latency test uses the same normalised figure across many samples, and browser keyboard event timing explains the pipeline in full.