Keyboard Map

Draft Community Group Report,

This version:
Issue Tracking:
Keyboard Map Explainer


This specification defines an API that allows websites to convert from a given code value to a valid key value that can be shown to the user to identify the given key. The conversion from code to key is based on the user’s currently selected keyboard layout. It is intended to be used by web applications that want to treat the keyboard as a set of buttons and need to describe those buttons to the user.

Status of this document

This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

This document is an editor’s draft proposed as a First Public Working Draft.

1. Introduction

On a KeyboardEvent, the code attribute encodes a value that represents the physical location of the key that was pressed. This value ignores the current locale (e.g., "en-US"), layout (e.g., "dvorak") and modifier state (e.g., "Shift + Control"), so it is ideally suited for applications (like games) that want to use the keyboard as a set of generic buttons. The idea behind the code attribute is that it provides a platform-neutral scancode for each physical key.

The key attribute, on the other hand, contains the value that is generated by the key press, accounting for the locale, layout, and modifier keys. Almost every Unicode character is a valid `key` attribute, along with a number of special named values (see KeyboardEvent key attribute values), so there are thousands of possible key values.

Because most users have a physical keyboard that matches their locale and layout, we can reasonably assume that the key value is a good stand-in for the glyph printed on the keycap. While this does not hold true when the user has selected a different layout, in that case the user is well-aware of the mismatch between the glyph on the keycap and the character generated by a key press.

The API described in this document provides a simple way of obtaining this basic code to key mapping.

2. Keyboard Map API

The Keyboard Map API extends the Keyboard interface to add attributes and methods related to the current keyboard layout.

The keyboard attribute on the Navigator object is specified in Keyboard-Lock.

2.2. KeyboardLayoutMap Interface


In only one current engine.

Edge (Legacy)NoneIENone
Firefox for AndroidNoneiOS SafariNoneChrome for Android69+Android WebView69+Samsung Internet10.0+Opera Mobile48+
interface KeyboardLayoutMap {
  readonly maplike<DOMString, DOMString>;

The KeyboardLayoutMap is a readonly collection of mappings from code values to key values.

2.3. Keyboard Interface


In only one current engine.

Edge (Legacy)NoneIENone
Firefox for AndroidNoneiOS SafariNoneChrome for Android68+Android WebView68+Samsung Internet10.0+Opera Mobile48+
partial interface Keyboard {
  Promise<KeyboardLayoutMap> getLayoutMap();

  attribute EventHandler onlayoutchange;

Note: The base Keyboard interface is specified in [Keyboard-Lock].

2.3.1. getLayoutMap()


In only one current engine.

Edge (Legacy)NoneIENone
Firefox for AndroidNoneiOS SafariNoneChrome for Android69+Android WebView69+Samsung Internet10.0+Opera Mobile48+

When getLayoutMap() is called, the user agent must run the following steps:

  1. Let p be a new Promise.

  2. If this's relevant global object's associated Document is not allowed to use the policy-controlled feature named "keyboard-map"

    1. Reject p with a "SecurityError" DOMException.

    2. Return p

  3. Run the following steps in parallel:

    1. Let map be a new KeyboardLayoutMap that is initially empty.

    2. For each value code in the "KeyboardEvent code" column of the Writing System Keys table

      1. Let layout be the highest priority ASCII-capable keyboard layout, or the highest priority keyboard layout if none of the available layouts are ASCII-capable.

      2. If code is not a valid key in the layout, then continue

      3. Let key be the key value that would be generated by layout if the key identified by code was pressed with no modifiers.

      4. If key is a dead key, then

        1. Set key to the standalone character that corresponds to the dead key, as defined in the Standalone Equivalents for Dead Keys table.

      5. Create a map entry e from the pair < code, key >

      6. Add e to map.

    3. Resolve p with map.

  4. Return p.

User agents may choose to cache the map and return the cached value as long as the cache is updated (or invalidated) whenever the keyboard layout changes.

To show instructions about which key to press in a game:
navigator.keyboard.getLayoutMap().then(function(map) {
  var keyUp = map.get("KeyW");
  showUserDialog("Press " + keyUp + " to move up.");
On a "US International" keyboard where the single-quote (') key is a dead key that adds an acute accent to the following character. The keyboard map would contain an entry mapping Quote (the code for this key) to "'" (the single-quote character U+0027).

2.4. Dead Keys and Combining Characters

Since the intent of the keyboard map API is to provide human-readable descriptions for keys on the user’s keyboard, dead keys or combining characters need to be converted into standalone forms so that they can be used directly.

The following table defines how to map from common dead keys and combining characters into standalone characters.

Table 1: Standalone Equivalents for Dead Keys
Dead Key
Grave U+0300 "`" U+0060
Acute U+0301 "'" U+0027
Circumflex U+0302 "^" U+005e
Tilde U+0303 "~" U+007e
Diaeresis U+0308 "¨" U+00a8

2.5. ASCII-Capable Keyboard Layouts

An ASCII-capable keyboard layout is one that:

The common writing system keys are those that are common to all keyboard layouts, as shown in blue in Figure 13 of the [UIEvents-Code] specification.

3. Keyboard Events

3.1. The layoutchange Event

When the user agent detects that the current keyboard layout has changed, then it MUST fire a layoutchange event. The exact timing of a layout change depends on the underlying platform but it is commonly triggered either directly by a user action (for example, when the user selects a new layout), or indirectly (such as when switching to an application that has a preferred layout).

Note the following:

If the keyboard layout changes while the user agent is not the foreground application, then the user agent MUST fire a layoutchange event when it regains focus.

To handle this event:
navigator.keyboard.addEventListener("layoutchange", function() {
  // Update user keyboard map settings

3.1.1. fire a layoutchange event

To fire a "layoutchange" event, fire an event named layoutchange at the keyboard attribute on the user agent’s Navigator object.

4. Integrations

4.1. Permissions Policy

This specification defines a feature that controls whether the getLayoutMap() method is exposed on the Keyboard interface.

The feature name for this feature is "keyboard-map".

The default allowlist for this feature is "self".

5. Mobile Device Considerations

Since this is a keyboard-focused API and mobile devices do not commonly have physical keyboards, this API will not typically be present or supported on mobile devices.

However, mobile devices may choose to support this API if they allow physical keyboards to be connected. In this case, they may return a subset of the Writing System Keys that are appropriate for the platform.

Mobile platforms that require the user to configure their physical keyboard layout (and don’t provide a reasonable default), may support this API by returning a layout map that contains no entries.

6. Security Considerations

This API returns static data and does not change any system state, so there are no special security concerns.

7. Privacy Considerations

As with all APIs that return information about the current device state, there is a risk of using this API to create a larger "fingerprint" of the user than if this API was not available.

By returning info from the highest priority ASCII-capable keyboard layout instead of the active layout, the value of this information for fingerprinting is reduced since users are more likely to share the same values.

Note the following situations where this layout information might be used to identify individuals:

Without this API, similar fingerprinting can still be attempted, but it is more difficult since it would require the user to interact with the page by typing characters and analyze the resulting KeyboardEvents.

7.1. Privacy Mitigations

As a first line of defense for the user, this specification requires that the API is only available from secure contexts and can only be called from the currently active top-level browsing context or granted access via policy-controlled feature.

User agents that are concerned about the privacy impact of providing this keyboard mapping information can also consider the following mitigations:

7.2. Privacy Mode

If a user agent provides an "incognito" or "privacy mode", then this API should act the same as it does outside of "privacy mode". The reason for this is that there is no universal neutral value that can be returned to ensure the user’s privacy.

User agents may choose to give the user the option to specify what value should be returned when in this mode, although care must be taken to ensure that the user does not get a false sense of security since this value would need to be updated when if they travel outside their home region.

8. Acknowledgements

Thanks to the following people for the discussions that lead to the creation of this proposal:

Hadley Beeman (W3C TAG), Joe Downing (Google), Masayuki Nakano (Mozilla), Julien Wajsberg (Mozilla)

9. Glossary


A value that the keyboard hardware assigns to each key so that it can be identified uniquely. See for additional information.


Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.


Terms defined by this specification

Terms defined by reference


Normative References

Anne van Kesteren. DOM Standard. Living Standard. URL:
Anne van Kesteren; et al. HTML Standard. Living Standard. URL:
Keyboard Lock. cg-draft. URL:
Ian Clelland. Permissions Policy. 16 July 2020. WD. URL:
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL:
Gary Kacmarcik; Travis Leithead. UI Events. 1 June 2022. WD. URL:
Gary Kacmarcik; Travis Leithead. UI Events KeyboardEvent code Values. 1 June 2017. CR. URL:
Gary Kacmarcik; Travis Leithead. UI Events KeyboardEvent key Values. 1 June 2017. CR. URL:
Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL:

IDL Index

interface KeyboardLayoutMap {
  readonly maplike<DOMString, DOMString>;

partial interface Keyboard {
  Promise<KeyboardLayoutMap> getLayoutMap();

  attribute EventHandler onlayoutchange;