How It Works

When you press a key, the browser fires a keydown (and often keyup) event. This tool listens for those events in your page context and records the fields developers most commonly need for keyboard handling. The focusable capture area helps ensure the event is generated by a deliberate key press rather than an unrelated page interaction.

Captured fields

• Event.key – The character or action name (for example "a", "A", "Enter", "Escape").
• Event.code – The physical key location on the keyboard (for example "KeyA", "Digit1", "NumpadEnter").
• Modifiers – ctrlKey, shiftKey, altKey, metaKey and repeat state.
• Location – event.location to distinguish left/right modifiers and numpad keys.
• Legacy values – keyCode / which for older codebases and quick comparisons (shown as legacy).

Because modern keyboard handling should prefer key and code, the tool emphasizes those values while still surfacing legacy fields for compatibility checks and migrations.

Tip: If you are debugging a shortcut inside an input field (like a text editor), keep in mind that some keys are handled differently depending on focus. For example, Arrow keys may move a caret inside a text field, while the same keys can trigger navigation in a grid when focus is elsewhere. Capturing the event in a dedicated focus area reduces ambiguity.

Key Features

Instant key and code readout

For printable keys, key reflects the character that would be produced (taking Shift and layout into account). For non-printable keys, it becomes a standardized name like "Enter" or "ArrowLeft". Meanwhile, code stays anchored to the physical key, which is why it is invaluable for games and muscle-memory shortcuts.

See the latest pressed key immediately, including the normalized key string and the hardware-based code. This is essential for deciding whether your logic should be character-based (use key) or physical-position-based (use code).

Modifier-aware hotkey debugging

When people say “Ctrl+Shift+K doesn’t work,” the real issue is often that one of the modifiers is missing or the OS maps the key differently. The tool shows each modifier flag separately and also presents a combined label so you can quickly see the intended chord. If you need to support both Windows/Linux (Ctrl) and macOS (Meta / Command), this view is especially helpful.

Hotkeys frequently depend on modifiers. The tool displays modifier flags and the combined “chord” so you can verify that your OS, browser, and keyboard are sending the expected states for Ctrl/Shift/Alt/Meta.

History log for sequences

Some interactions depend on timing and order: think Vim-style commands, multi-step shortcuts, or modal editors. A short rolling history lets you verify that your application receives the correct sequence, and helps you identify cases where key repeat or focus shifts inject extra events.

Keyboard UX often involves sequences (for example “Ctrl+K” then “Ctrl+F”). The history panel helps you inspect a short series of events without reloading the page. You can copy the log as JSON for issue reports.

Copy and download for documentation

Teams often struggle to reproduce keyboard bugs because the reporter can’t easily describe their layout, the key they pressed, or which modifiers were held. Exporting the snapshot as JSON provides an unambiguous, machine-readable record. You can also include it in automated test cases or fixture files during development.

Export your captured snapshot or full history. Copy to clipboard for quick pasting into GitHub issues, QA tickets, or chat messages. Download as a JSON file when you want to attach a reproducible trace to a bug report.

Legacy field visibility

If you are migrating from old code, you may need a transition period where you log both legacy and modern fields. Seeing them side by side helps you confirm your mapping rules, such as translating a legacy numeric code into a modern code string or a normalized key name.

If you maintain older libraries that still rely on keyCode or which, the tool makes it easy to see what values are being produced in your current browser so you can map them to modern equivalents during refactors.

Use Cases

• Building cross-layout shortcuts – Decide whether to use key (user-intended character) or code (physical key) when supporting QWERTY, AZERTY, QWERTZ, and other layouts.
• Debugging non-printable keys – Confirm values for Enter, Tab, Backspace, arrow keys, function keys, and media keys.
• Numpad and modifier differences – Distinguish numpad keys from top-row digits and detect left/right modifier locations.
• Web app hotkeys – Validate that your key combinations aren’t blocked by browser or OS shortcuts and that your handlers receive the expected modifier states.
• QA and bug reports – Provide exact event payloads when reporting keyboard issues, making triage faster for developers.
• Educational demos – Teach students or teammates how browser keyboard events work with a visual, hands-on tool.

In practice, most teams use this tool to settle one decision: should the feature be character-based or position-based? Once you see how key changes with layout while code stays stable, the correct approach becomes clearer for your particular feature.

Another common use is validating accessibility behavior. Keyboard navigation should be predictable for users who rely on it, and certain keys (like Space and Enter) have semantic meanings on buttons and links. By verifying what the browser reports, you can implement respectful overrides that don’t break native expectations.

Finally, the tool helps when you work with embedded contexts such as iframes, remote desktops, or virtual keyboards. Those environments sometimes translate or filter key events. Capturing the output in your target environment is often the only reliable way to know what your application will receive.

Optimization Tips

Prefer Event.key for text intent

If your shortcut or behavior should follow what the user means to type (for example “/” to open search), use event.key. It respects keyboard layout and modifier effects like Shift. This typically produces the best UX for global audiences.

Prefer Event.code for physical-position shortcuts

If you want a shortcut to behave like a physical key (for example WASD movement in a game), use event.code. It stays tied to the same physical key regardless of layout, which reduces surprises for players.

Handle modifiers and repeat carefully

For held-down keys, browsers can emit repeating keydown events. Check event.repeat and decide whether to ignore repeats, throttle actions, or treat repeats as intentional input (for example holding ArrowDown to scroll).

Normalize before comparing

For letters, event.key can be "a" or "A" depending on Shift and Caps Lock. If your shortcut should not be case-sensitive, normalize with toLowerCase() before comparing. Keep punctuation in mind as well: on many layouts, the same physical key yields different symbols.

Respect focused inputs

Global shortcuts can be disruptive if they fire while the user is typing. Many apps disable global handlers when focus is inside text inputs, or require an additional modifier. Use the tool to test your rules by focusing different elements and ensuring your key handling remains intuitive.

Know your reserved shortcuts

Browsers and operating systems reserve popular combinations. For example, printing, saving, refreshing, opening new tabs, or showing developer tools may not be interceptable. When you design shortcuts, pick combinations that are unlikely to collide, and provide a configurable shortcut UI for advanced users.

FAQ