UseToolSuite UseToolSuite

Keyboard Event Viewer

Inspect keyboard events in real time: event.key, event.code, keyCode, modifiers, and location. Press any key and copy a ready JS listener snippet.

Click here & press a key

event.key

—

event.code

—

event.keyCode

—

event.which

—

event.location

—

event.type

—

repeat

—

Modifiers

—

document.addEventListener('keydown', (e) => );

Waiting for key events...

What is Keyboard Event Viewer?

Keyboard Event Viewer is a free online tool that displays all JavaScript keyboard event properties in real time as you press keys. It shows event.key, event.code, event.keyCode, event.which, modifier states, key location, and repeat status — everything you need when building keyboard shortcuts, accessibility features, or game controls. It also generates a ready-to-use JavaScript event listener code snippet for the key you pressed and maintains a scrollable event log. All processing happens locally in your browser.

When to use it?

Use the Keyboard Event Viewer when you need to look up the exact event.key or event.code value for a specific key, debug keyboard shortcuts across different keyboard layouts, check whether the deprecated keyCode property matches your expectations, or understand the difference between left and right modifier keys using event.location. It is especially useful when building keyboard-driven interfaces where you need to know the precise event properties before writing your handler code.

Common use cases

Developers use the Keyboard Event Viewer to debug hotkey implementations in web apps, verify that arrow keys and function keys produce the expected event codes, test modifier key combinations (Ctrl+Shift+S, Cmd+K) for custom shortcuts, check keyboard behavior in accessibility testing, understand key repeat behavior for game-like interactions, and generate boilerplate JavaScript code for event listeners. It is also a valuable reference tool for understanding the differences between the modern event.key/event.code API and the deprecated event.keyCode/event.which properties.

key vs code vs keyCode — the three identities of a keypress

Press one key and the event carries several different descriptions of it. Knowing which to read is most of the battle:

PropertyTells youLayout-dependent?Status
event.keyThe character/value produced ("a", "A", "Enter")YesUse this
event.codeThe physical key position ("KeyA", "Space")NoUse this
event.keyCodeLegacy numeric codeYesDeprecated

keyCode is deprecated and shouldn’t be used in new code, but it’s still shown here for maintaining legacy systems. For everything new, it’s key (what was typed) and code (which physical key) — and the FAQ above explains which to pick.

Detecting combinations

A shortcut like Ctrl+Shift+S is just a key/code check combined with the modifier booleans the event always carries: event.ctrlKey, event.shiftKey, event.altKey, and event.metaKey (Command on macOS, Windows key on Windows). This viewer generates the exact condition for whatever combination you press, including the cross-platform nuance that “Ctrl” on Windows is often “Cmd” (metaKey) on macOS — a detail that trips up a lot of shortcut code.

Why some keys never reach your handler

If a key seems “dead,” it may be intercepted before JavaScript sees it. PrintScreen is grabbed by the OS, F11 toggles browser fullscreen, and Ctrl+W closes the tab — and preventDefault() can’t always override these reserved combinations. When designing shortcuts, prefer combinations (Ctrl+Shift+letter) that browsers don’t already claim, and test on the platforms you support, since the reserved set differs between OSes and browsers.

The focus gotcha

Key events fire on the focused element first. A document-level listener may not behave as expected when an <input>, <textarea>, or contenteditable has focus and consumes the event. For global shortcuts, check event.target.tagName to decide whether to act or defer, or attach the listener with { capture: true } to see the event on the way down. Combined with the isComposing guard above, that’s the recipe for shortcuts that don’t fight with text entry.

Keyboard Event Viewer Powered by UseToolSuite — free browser tools

Keyboard Event Viewer processes your text in the browser, which means even sensitive strings stay private. It's one of the free String & Text Tools on UseToolSuite.

Last updated

How helpful was this tool?

Click to rate

Embed this tool on your site

Paste this snippet into any HTML page or blog post to embed a live, fully working copy of Keyboard Event Viewer. Free for any use.

Key Concepts

KeyboardEvent

A DOM event fired when the user interacts with the keyboard. Three event types exist: keydown (key pressed), keyup (key released), and the deprecated keypress (character produced). KeyboardEvent provides properties like key, code, keyCode, location, and modifier states (ctrlKey, shiftKey, altKey, metaKey) that describe the key interaction.

event.key

A string representing the key value of the key pressed. For printable characters it returns the character itself ("a", "A", "1", "/"). For non-printable keys it returns a descriptive name ("Enter", "Escape", "ArrowDown", "Shift"). The value is affected by the active keyboard layout and modifier key state.

event.code

A string representing the physical key on the keyboard, independent of keyboard layout. It uses a standard naming convention: letter keys are "KeyA" through "KeyZ", digit keys are "Digit0" through "Digit9", and special keys have descriptive names like "ShiftLeft", "ArrowUp", "Space". The same physical key always produces the same event.code regardless of language or layout.

Key Repeat

When a key is held down, the operating system generates repeated keydown events after an initial delay (repeat delay) at a configurable rate (repeat rate). The event.repeat property is false for the first keydown and true for all subsequent auto-repeated events. This is useful for distinguishing initial key presses from held keys in games and keyboard-driven interfaces.

Frequently Asked Questions

Will my shortcut clash with a browser or OS shortcut?

Press the combination and the tool tells you. It checks against the shortcuts the browser and the desktop already own — closing a tab, DevTools, Spotlight, the tab-number jumps, zoom, back and forward — and separates the two cases that matter: combinations preventDefault() can take back (Cmd/Ctrl+S, Cmd/Ctrl+F, Cmd/Ctrl+P) and the ones it cannot (Cmd/Ctrl+W, Cmd/Ctrl+T, F12, Cmd+Space), where binding is simply not possible. It reads the primary modifier as Cmd on macOS and Ctrl elsewhere, so the answer matches the machine you are on. A bare key with no modifier is reported as free, with the reminder that it will still fire while someone is typing unless you ignore events coming from inputs and textareas.

What is the difference between event.key and event.code?

event.key returns the character or key name produced by the key press, affected by the current keyboard layout and modifier keys (e.g., "a" or "A"). event.code returns the physical key identifier on the keyboard regardless of layout (e.g., "KeyA" whether your layout is QWERTY, AZERTY, or Dvorak). Use event.key for text input handling and event.code for keyboard shortcuts that should work on any layout.

Is event.keyCode deprecated? What should I use instead?

Yes, event.keyCode and event.which are deprecated in the DOM specification and should not be used in new code. Use event.key for the logical key value (character or key name) and event.code for the physical key position. However, keyCode is still widely supported in browsers for backward compatibility, and this tool shows it for reference when maintaining legacy code.

Why do some keys not trigger keydown events?

Certain keys may be intercepted by the operating system or browser before they reach your JavaScript event handler. Common examples include PrintScreen (captured by the OS), F11 (browser fullscreen toggle), and Ctrl+W (close tab). Some accessibility tools and browser extensions also intercept keys. The keys that reach your handler depend on the user's OS, browser, and installed extensions.

How does event.location work for modifier keys?

event.location indicates the physical position of the key: 0 (Standard — general area), 1 (Left — left Shift, left Ctrl), 2 (Right — right Shift, right Alt), 3 (Numpad — numpad keys). This is essential for distinguishing between left and right modifier keys in applications like games or accessibility tools where the physical key position matters.

Can I detect key combinations like Ctrl+Shift+S?

Yes. Check the modifier properties (e.ctrlKey, e.shiftKey, e.altKey, e.metaKey) together with e.key in your keydown handler. This tool automatically generates the correct JavaScript condition for any key combination you press, including multi-modifier combinations.

Should I use event.key or event.code for keyboard shortcuts?

It depends on whether the shortcut is about the CHARACTER typed or the PHYSICAL key. Use event.code for position-based shortcuts that must work on any layout — game controls (WASD should be the same physical keys whether the user has QWERTY, AZERTY, or Dvorak), or a shortcut you think of as 'the key in that spot.' Use event.key when you care about the actual character produced — 'Ctrl+S to save' should fire on whatever key produces 's' in the user's layout. A common bug is using event.key for game movement: an AZERTY user pressing the physical 'W' position gets 'z', and your WASD handler breaks. Match the property to the intent.

Why do my shortcuts misfire while someone is typing in another language?

Input Method Editors (IMEs) — used for Chinese, Japanese, Korean, and other scripts — compose characters from multiple keystrokes, and during composition the browser fires keydown events with event.key === 'Process' or the legacy keyCode 229. If your shortcut handler reacts to those, it triggers in the middle of someone composing text. The fix: check event.isComposing (true while an IME is active) and bail out early, or ignore keyCode 229. Always guard global shortcut handlers with `if (event.isComposing) return;` so you don't hijack keys that are part of text composition.

Troubleshooting & Technical Tips

Key event not firing inside an input or textarea element

When an input, textarea, or contenteditable element has focus, key events fire on that element first. If the element handles the event (e.g., typing text), it may not bubble to your document-level listener as expected. Use event capturing (addEventListener with { capture: true }) or attach the listener directly to the target element. For global shortcuts, check e.target.tagName to decide whether to handle or ignore the event.

event.key returns "Unidentified" for some keys

The "Unidentified" value is returned when the browser cannot map the physical key to a known key value. This commonly happens with non-standard keys on specialized keyboards (gaming, multimedia), some IME composition states on non-Latin keyboards, or browser bugs on certain platforms. In these cases, fall back to event.code (physical key position) or event.keyCode (legacy numeric value) for identification.

Keyboard shortcuts conflict with browser defaults (Ctrl+S, Ctrl+P)

Call e.preventDefault() in your keydown handler to override the browser default. However, some shortcuts cannot be overridden in all browsers (Ctrl+N, Ctrl+T, Ctrl+W). For maximum compatibility, choose shortcuts that do not conflict with common browser actions, or use modifier combinations like Ctrl+Shift+key that are less likely to conflict.

Related Guides

Web Accessibility Checklist: A Practical Guide for Developers

A no-nonsense web accessibility checklist: WCAG 2.1 essentials, semantic HTML, keyboard navigation, color contrast, screen readers, ARIA, and testing.

Related Tools

Regex Tester

String & Text Tools

String Case Converter

String & Text Tools

Word Counter & Text Counter

String & Text Tools