The modern JavaScript alternative to the deprecated keyCode property is KeyboardEvent.key or KeyboardEvent.code, selected according to whether a shortcut follows meaning or physical position. In a browser application, read those values from the KeyboardEvent delivered to your own handler. The JavaScript Key Code Finder supports that workflow by capturing one focused keydown locally and exposing the fields needed to compare and diagnose event behavior; it is a diagnostic tool, not a drop-in programmatic API.

Use key when an action should follow the character or named action produced under the active layout and modifier state. Use code when a control must remain attached to a physical position, such as WASD movement. Confusing these two models is a common cause of shortcuts that work on the developer’s keyboard but fail on another layout.

javascript keycodes api alternative
JavaScript Keycodes API Alternative: Inspect Browser Events

Choose key or code by behavior

The values answer different questions. On a US layout, the same physical key may report 2 or @ depending on Shift, while another layout can report a different character. The code value identifies positions such as Digit2 or KeyW and normally stays stable when the layout changes.

Property What it represents Best fit Important limitation
key The meaning produced after the current layout and modifier state are applied Character input and named-action shortcuts Its value can change with the layout or modifiers
code The physical key position Games, movement controls, and layout-independent hardware positions It normally remains stable, but it does not describe the resulting character
location Standard, left, right, or numpad placement Distinguishing side-specific Shift, Control, Alt, Meta, Enter, and number keys Not every key has multiple possible locations
Modifier booleans The modifier state included in the current event Handling Ctrl, Alt, Shift, and Meta combinations They are not a history of every key pressed
repeat Whether the event represents a repeated keydown Preventing one action from firing repeatedly while a key is held The operating system or browser controls repeated event delivery
composing Whether an input method or dead-key composition may be producing text Deferring shortcut actions until composition is complete Composition behavior depends on the active input method
keyCode A legacy numeric identifier Diagnosing compatibility problems in older code It is deprecated and implementation-dependent

For most new handlers, key and code resolve the central design decision. The remaining fields let you narrow that decision when duplicate keys, modifiers, held keys, or text composition make an event ambiguous.

Implement a JavaScript keyboard handler

Use the modern fields directly in the handler that owns the interaction rather than translating a browser event into a custom numeric code system.

  1. Scope the keydown handler. Attach it to the control or region responsible for the shortcut so unrelated typing does not accidentally trigger an action.
  2. Choose one primary field. Compare event.key with a character or named value when behavior should follow the current layout. Compare event.code with a physical code when placement matters.
  3. Resolve duplicate and modifier cases. Check event.location for standard, left, right, or numpad placement, and inspect the modifier state included in the event.
  4. Define repeat and composition rules. Ignore repeated events if the feature should run once per physical press, and defer an action when the event reports active composition.
  5. Keep an accessible alternative. Provide a clickable control for an essential shortcut, and do not make one physical keyboard layout the only way to complete a critical action.

When migrating legacy logic, replace numeric keyCode branches with an explicit key or code comparison. A captured value can reveal what the old branch expected, but it should not become the basis of a new portable mapping.

Inspect a real key event locally

Use a real browser capture when you need to see the values produced by a particular keyboard rather than guessing from a keyboard illustration.

  1. Open the JavaScript Key Code Finder and click or tab to the bordered capture area.
  2. Press the key or key combination you want to inspect.
  3. Compare key for meaning with code for physical position, then review the reported location and modifiers.
  4. Review repeat, composing, and the legacy numeric keyCode when those details matter.
  5. Copy the displayed JSON only as a diagnostic, bug-report attachment, or local test fixture.
  6. Test the same interaction on the real target browsers, operating systems, and keyboard layouts supported by the application.

The finder observes a keydown only inside its deliberately focused capture area. Nothing typed outside that area is observed, and keystrokes or text are not sent to a server. It retains only the latest event in page state until the page changes or reloads; it does not maintain an event history or install a global listener.

While the capture target is focused, default actions for keys other than Tab are canceled, which prevents Space or arrow keys from scrolling the page during inspection. Tab is never canceled, so keyboard users can move focus away rather than becoming trapped in the capture control.

Interpret location and event state

A useful event report separates the key’s identity, physical placement, and the state attached to that particular event.

  • Location identifies the standard, left, right, or numpad variant. It matters when the same named key exists in more than one place, including modifier keys, Enter, and some numeric keys.
  • Modifiers report the state included in the event, not a global history of everything pressed. A Ctrl-based shortcut should check the actual modifier state rather than assume that a previous key remains active.
  • Repeat becomes true when the operating system or browser emits repeated keydown events while a key is held. Use it to suppress repeated actions where one activation is intended.
  • Composing indicates that an input method editor or dead-key composition may be producing text. Shortcut handlers should often wait until composition is complete so they do not interrupt text entry.

These fields describe one event at a time. They do not reveal the keyboard model, fingerprint the hardware, or reconstruct a sequence of earlier keystrokes. While composition is active, also avoid assuming that the final typed character is identical to the key’s immediate value.

Use keyCode only for compatibility diagnosis

The W3C UI Events specification defines modern keyboard event fields, while MDN’s KeyboardEvent.keyCode reference identifies keyCode as deprecated and implementation-dependent. UI Events does not provide reliable modern values for that legacy property.

Printable-key behavior has differed across browsers and layouts, so a numeric value should not be interpreted as ASCII, Unicode, or the exact character typed. A value of zero does not necessarily mean that no key exists; it may mean that the legacy property cannot identify the key. The keyCode displayed by the finder is therefore most useful when checking how older code behaves, not when defining new behavior.

Build a real compatibility test plan

Keyboard handling is part of the application’s compatibility surface. Test the exact environments listed in the feature requirements rather than assuming desktop behavior represents every supported device.

  • Test layouts: Include every supported keyboard layout, along with any layout-dependent character or shortcut expectations.
  • Test browsers and operating systems: Check each supported browser and platform because key handling can differ.
  • Test input methods and assistive technologies: Verify supported IMEs, dead keys, accessibility tools, and the behavior of composition events.
  • Use fixtures carefully: For automated checks, the finder includes eight standard-derived fixtures covering letters, shifted digits, left and right Alt, numpad Enter, and dead-key composition, while four unique location labels are asserted independently.
  • Finish on real devices: Synthetic KeyboardEvent objects are not trusted user input and may not reproduce native platform behavior. Real devices remain the final compatibility check.

Copied JSON can help reproduce a value in a local test, but it does not reproduce the browser’s full event pipeline. Keep the real-device checks in the release process for the layouts, operating systems, browsers, assistive technologies, and input methods your feature promises to support.

Recognize events the page may not receive

A focused capture cannot reveal a keystroke that the browser or platform never delivers. Browser-reserved shortcuts, operating-system shortcuts, accessibility technology, password managers, remote desktops, and input methods can intercept an event before the page receives it. Mobile virtual keyboards may also expose fewer code values because they do not correspond to a physical key position.

Do not type passwords, recovery codes, or other secrets into the capture area, even though the event remains local. A keyboard diagnostic does not need confidential content. When a shortcut is important, document any known conflicts and retain a non-keyboard control so an intercepted or unavailable key cannot block the task.

For a migration, replace numeric keyCode branches with key or code, use location and state fields to resolve ambiguity, and confirm the result with native events on every target platform you support.

Related reading: Public NTP Server List Alternative: 4 Practical Options.

Related reading: PowerPoint Shortcuts API Alternative: Local Reference.