Keyboard Keycode Viewer

Introduction

Keyboard handling can be confusing because different properties describe different aspects of the same key press. This single-page viewer helps you debug keyboard shortcuts, game controls, accessibility interactions, and cross-platform differences by showing the values from the browser’s KeyboardEvent object.

When you press a key, browsers typically provide multiple properties. This viewer focuses on the three values that most developers search for when something “doesn’t work on my machine”: the semantic key value, the physical key location, and the legacy numeric code.

• event.key — the meaning of the key press (for example "a", "A", "Enter", "Escape", "ArrowUp").
• event.code — the physical key location (for example "KeyA", "Digit1", "Space"), usually stable across keyboard layouts.
• event.keyCode — a legacy numeric identifier used by older code; it is deprecated but still encountered in existing projects.

This page is designed for quick verification: confirm what your current browser/OS/layout reports, then use those values in your own JavaScript logic. It is also useful when writing documentation or bug reports because you can copy a one-line summary of the last key event.

How to use

1. Move focus to the Key capture area (click it, or press Tab until it is focused).
2. Press any key on your keyboard. The viewer listens for keydown and updates immediately.
3. Read the results table that appears inside the capture area.
4. Use Copy Key Details to copy a one-line summary for bug reports, commit messages, or documentation.

Tip: Try modifier combinations such as Shift+letter, Alt/Option, or Ctrl/Cmd. You can also test non-character keys like arrows, function keys, and navigation keys. If a key does not show up, it may be reserved by your operating system or browser.

What the viewer displays (properties and meaning)

This tool does not compute a mathematical result; it reports values directly from the browser’s event object. Conceptually, the output is a mapping from property name to the value observed on the most recent keydown:

event.key     → a string describing the key meaning
event.code    → a string describing the physical key position
event.keyCode → a legacy number (deprecated)

In other words, the “result” is the tuple (key, code, keyCode) captured at the moment you press a key while the capture area is focused. The values come from your current environment, so they are ideal for verifying real behavior rather than relying on memory or outdated tables.

Worked examples (practical checks you can copy into code)

The fastest way to use this page is to press a key and then decide which property you should check in your own JavaScript. The examples below show common patterns and the reasoning behind them.

Example 1: Enter to submit or confirm

If you are implementing a shortcut that should trigger when the user presses Enter, you can verify the correct check like this:

1. Focus the capture area.
2. Press Enter.
3. You will typically see something like:

• event.key: "Enter"
• event.code: "Enter"
• event.keyCode: 13

For new code, prefer event.key === "Enter". Use event.code when you care about physical placement (for example, games), and treat keyCode as a compatibility aid for older code.

Example 2: Layout-aware typing vs layout-independent controls

Suppose you want to implement a “press the A key to move left” control. If you check event.key, the value can change with keyboard layout (for example, on some layouts the physical key labeled A may produce a different character). If you check event.code, you can target the physical key position instead.

Try this experiment: press the key that produces the letter A on your keyboard. You may see event.key as "a" or "A" depending on Shift, while event.code is often "KeyA". In a game, you might use event.code === "KeyA" so the control remains consistent even if the user changes layout. In a text editor, you would use event.key because you care about the character that will be inserted.

Example 3: Detecting a shortcut with modifiers

Many shortcuts are combinations, such as Ctrl+S (save) or Cmd+K (focus search). This viewer shows the base key values, and you can combine them with modifier flags in your own code. While this page does not list modifier booleans, it helps you confirm the correct key/code value for the non-modifier key.

A typical pattern is: check e.ctrlKey or e.metaKey plus e.key. For example, you might implement “save” as (e.ctrlKey || e.metaKey) && e.key === "s". Use this viewer to confirm whether your browser reports "s" or "S" when Shift is held, and decide whether you want a case-insensitive comparison.

Assumptions and capture behavior

The capture area listens for keydown events. That choice is intentional: keydown fires for most keys, including non-printable keys such as arrows and function keys. Some applications use keyup to avoid repeated firing when a key is held down, and some use keypress (now largely obsolete) for character input. If you are debugging a specific issue, confirm which event type your own code uses and compare it to what you see here.

The viewer also calls preventDefault() on the event while the capture area is focused. This prevents the page from scrolling when you press arrow keys or space, and it helps ensure the capture area remains a stable testing surface. If you are testing browser-native shortcuts (for example, Ctrl+L to focus the address bar), those may still be intercepted before the page receives the event.

Additional reference: choosing between key, code, and keyCode

Troubleshooting and common surprises

If you are not seeing the values you expect, the issue is usually one of the following. These notes are written to be practical: they describe what to check and why it matters.

1) The capture area is not focused

The viewer only receives keyboard events when the capture area has focus. Click the capture box, or press Tab until it is focused, then try again. If you are using a screen reader or keyboard-only navigation, the capture area is focusable and announces updates via a live region.

2) Your browser or OS intercepts the shortcut

Some key combinations never reach the page. Examples include OS-level shortcuts (like switching apps) and browser-level shortcuts (like opening a new tab). If a combination does not appear here, try a different browser, disable conflicting extensions, or test a simpler key press to confirm the capture area is working.

3) Differences between laptops, external keyboards, and international layouts

The same physical key can produce different characters depending on layout, language, and modifier keys. That is exactly why event.code exists. If you are building a control scheme that should be consistent across layouts, prefer code. If you are building a text feature, prefer key.

4) Repeated keydown events when holding a key

When a key is held down, many systems generate repeated keydown events. If your application should only act once per press, you may need to check e.repeat in your own code. This viewer shows the latest event only, so you may notice the table updating rapidly when a key is held.

Notes on character codes (context)

Developers sometimes confuse keyCode with character encodings (ASCII/Unicode). While characters do have numeric code points, this viewer intentionally reports keyboard event properties rather than raw Unicode values. If you need a Unicode code point for a printable key, you can often derive it from event.key (when it is a single character) using event.key.codePointAt(0). For example, if event.key is "A", the code point is 65; if it is "€", the code point is 8364.

For completeness, encodings can be described as numeric representations of bytes. In base 256, a multi-byte value can be expressed as a sum of bytes times powers of 256:

You generally do not need this formula for keyboard shortcuts; it is included only as background for how numeric representations can be constructed. For keyboard work, the practical takeaway is: keyCode is not a Unicode code point, and it should not be used as one.

Limitations

• Focus is required: the viewer only captures keys when the capture area is focused.
• System-reserved keys: some keys/shortcuts are intercepted by the OS or browser and may never reach the page.
• Mobile/virtual keyboards: on-screen keyboards may not emit the same events or properties, so results can be incomplete.
• Browser differences: values can vary across browsers and platforms, especially for function/media keys.
• keyCode is deprecated: it may be inconsistent or absent in some environments.

Despite these constraints, the viewer is a reliable way to see what your current environment reports, which is often the most practical information for debugging.

Privacy and data handling

This viewer runs entirely in your browser. The key values are displayed on the page and can be copied to your clipboard only when you click the copy button. The page does not ask you to type into a text field, and it does not transmit key presses to a server. Still, avoid testing sensitive passwords or private information: treat any debugging tool as a place to test keys and shortcuts, not confidential content.