Keyboard Keycode Viewer

How to Use the Keyboard Event Viewer

1. Locate the key capture area on the page (it is focusable and labeled for screen readers).
2. Click inside the capture area, or move focus there using the keyboard (for example, by pressing Tab until it is selected).
3. Press any key on your physical keyboard. The viewer listens for a keydown event.
4. Read the results table, which displays the latest event.key, event.code, and event.keyCode values.
5. Optionally, use the Copy Key Details button to copy a text summary of the most recent key event to your clipboard.

The results are updated each time you press a key, so you can hold a key, test combinations with modifiers such as Shift, Alt, or Control, or try keys like function keys and arrows to see how they are reported by your browser.

Modern Keyboard Event Properties: key and code

Modern browsers follow the DOM Level 3 Events (now part of UI Events) specification, which introduces KeyboardEvent.key and KeyboardEvent.code as the primary ways to identify key presses in JavaScript. These two properties serve different but complementary purposes.

event.key: The meaning of the key press

The key property represents the logical meaning of the key press. For character keys, it is usually the text that would be inserted into an input field. For control keys, it is a descriptive string. Examples include:

• "a" or "A" for the A key, depending on whether Shift is held.
• "Enter" for the Enter/Return key.
• "ArrowUp", "ArrowDown", "ArrowLeft", "ArrowRight" for the arrow keys.
• "Escape" for the Esc key.

Because key reflects the character produced, it automatically accounts for keyboard layout and active modifiers. This makes it ideal for implementing shortcuts that depend on letters or symbols, such as pressing s to save, regardless of where that letter is located on the keyboard.

event.code: The physical key on the keyboard

The code property represents the physical key position, expressed in a layout-agnostic identifier. Examples include:

• "KeyA" for the physical key where the A key is located on a standard US keyboard.
• "Digit1" for the number 1 key above the letters.
• "Space" for the spacebar.
• "ArrowLeft" for the left arrow key.

Unlike key, the code value does not change if the user switches layouts (for example, from QWERTY to AZERTY). This makes it especially useful for games and applications that care about physical key placement rather than the character generated.

Legacy keyCode and Backward Compatibility

Before key and code were widely supported, developers depended on KeyboardEvent.keyCode, which is a numeric value associated with the key press. Typical values include:

• 65 for the A key.
• 13 for Enter.
• 27 for Escape.

The keyCode property is now deprecated. Modern code should avoid introducing new dependencies on these numbers. However, many existing frameworks, libraries, and legacy applications still use them. This viewer shows keyCode alongside the modern properties to help you:

• Understand which numeric codes your older code is checking against.
• Verify how a particular browser maps keys to keyCode values.
• Plan migrations from numeric checks to key or code-based logic.

Character Codes and Numeric Representations

Inside the browser and operating system, characters are ultimately represented as numbers. For example, in the ASCII character set, "A" corresponds to decimal 65, "B" to 66, and so on. Modern systems typically use Unicode, which extends this mapping to many more symbols and scripts.

You can think of a character’s numeric code as being built from its underlying bytes. In base 256, the code for a multi-byte character can be expressed as a polynomial in powers of 256:

Here, each c_i is the numeric value of a byte, and the entire sum reconstructs the code point. JavaScript hides these details behind APIs like String.prototype.charCodeAt, so you seldom need to work directly with this formula in application code. Still, it is useful when reasoning about encodings and how characters are stored.

The key viewer on this page does not expose raw byte values or Unicode code points directly; instead, it surfaces what the browser reports in key, code, and keyCode. If you need to work with Unicode values, you would typically convert characters from event.key using methods like event.key.codePointAt(0).

Interpreting the Results

When you press a key, the results table shows one row for each property. You can use this information in several ways:

• Confirm shortcut behavior: When wiring keyboard shortcuts in a web app, check event.key to ensure the expected letter or control key is being detected, and verify how modifier keys affect it.
• Verify layout sensitivity: On international keyboards, compare key (which changes with layout) to code (which does not) to decide which property best matches your design.
• Audit legacy checks: If you maintain older code that checks numeric values such as if (e.keyCode === 13), use the viewer to confirm those numbers still map to the intended keys in current browsers.

Treat the output as a snapshot of how your current browser, operating system, and layout report that key at this moment. Different platforms may produce slightly different values, which is one of the reasons to favor the standardized key and code properties whenever possible.

Worked Example: Inspecting the Enter Key

Suppose you want to handle the Enter key in a form, and you need to ensure your code will behave correctly across browsers. You can use the viewer as follows:

1. Click inside the key capture area.
2. Press the Enter key on your keyboard.
3. Observe the results table.

On a typical modern desktop browser, you will see values similar to:

• event.key: "Enter"
• event.code: "Enter" (or a layout-specific code for the main Enter key)
• event.keyCode: 13

With this information, you might decide to write new code that checks only event.key === "Enter". If you are refactoring legacy code, you could replace a condition such as if (e.keyCode === 13) with the more descriptive and future-proof check on key.

For non-character keys like arrows or function keys, the viewer provides the same clarity: you can see immediately which strings and numeric values are being produced without needing to consult external tables.

Comparison of key, code, and keyCode

The three properties this viewer exposes answer slightly different questions. The table below summarizes their roles:

Keyboard Event Flow and Common Patterns

A full key press can involve several events: keydown, keypress (deprecated in many contexts), and keyup. This viewer focuses on keydown, which is typically used for shortcuts and commands because it fires as soon as the key is pressed.

A minimal pattern for listening to keyboard events in JavaScript looks like this:

document.addEventListener("keydown", function (event) {
  if (event.key === "Escape") {
    // Close a dialog, cancel an action, etc.
  }

  if (event.code === "ArrowLeft") {
    // Move a player or cursor left, regardless of layout.
  }
});

When you use this viewer, you are effectively inspecting the same event object that your own application code would receive, just in a structured, human-readable format.

Limitations and Assumptions

This keyboard event viewer is a practical debugging and learning tool, not a formal specification. Keep these limitations and assumptions in mind when interpreting the results:

• Browser differences: While modern browsers broadly agree on key and code values, there can still be differences for certain keys, especially function keys, media keys, or vendor-specific keys.
• Deprecated keyCode behavior: Because keyCode is deprecated, its presence and values are not guaranteed long term. Some environments may not expose it, or may treat it inconsistently.
• Hardware keyboard assumption: The tool is designed primarily for devices with a physical, hardware keyboard (desktop and laptop computers). On some mobile devices and virtual keyboards, the relevant events may not fire, or they may omit certain properties, making the viewer appear inactive.
• System-reserved keys: In many operating systems, some keys are handled at a system level (for example, certain global shortcuts or brightness and volume controls). Browsers may not receive events for those keys, so this viewer cannot show information for them.
• Focus requirement: The viewer only captures keys while the capture area has focus. If you press keys while focus is on another element (such as the address bar, another tab, or a different window), no new results will appear.
• Non-authoritative reference: For precise, up-to-date definitions of keyboard event behavior, refer to the official UI Events and DOM specifications and the documentation for your target browsers.

Within these limits, the page should still give you a reliable, concrete picture of how your current environment is reporting key presses, which is often all you need to debug real-world issues.