How to Handle Keyboard Events in React

To handle keyboard events in React, attach onKeyDown or onKeyUp to the element that has focus and read which key was pressed from e.key. Buttons and inputs support keyboard interaction out of the box, while custom controls need a handler of their own. Read the key, compare it, and run the matching action.

Read keys with onKeyDown

onKeyDown fires when a key is pressed and repeats while the key is held. Use e.key for the key's meaning, like Enter or Escape, or e.code for the physical key position.

App.jsx

function SearchInput() {
  function handleKeyDown(e) {
    if (e.key === "Enter") {
      alert("Searching for " + e.target.value);
    }
  }
  return <input onKeyDown={handleKeyDown} />;
}

Type a query and press Enter to trigger the search. The handler branches on the key and reads the input's current value from the event target. For a real search form, a submit handler is usually the better fit, but key checks are the right tool for shortcuts inside a single control.

onKeyUp fires once when the key is released, which suits actions that should happen after the press ends, like stopping a repeated action. onKeyDown is the default for most shortcuts because it responds immediately.

e.key and e.code

e.key reports the key's meaning and respects the keyboard layout, so pressing the Q key reports q. e.code reports the physical position, like KeyQ, and stays the same across layouts.

Use e.key for shortcuts that follow the layout and e.code for game controls or layout-independent keys. Most shortcuts read e.key and ignore the physical position, because users think in characters, not key locations.

Common keys to check

Most key handling branches on a handful of values. Enter confirms, Escape cancels, Tab moves focus, and the arrow keys navigate lists and menus.

Tab and the arrows usually move focus, so check them only when building custom menus or lists that keep their own focus. Checking for one key at a time keeps the handler readable.

Keep it accessible

Only fire keyboard handlers on elements the keyboard can reach. A div needs a tabIndex and a role before it behaves like a control, and you still must implement every key behavior a native button gives for free.

A native button already opens on Enter and Space, so adding those keys to a div re-implements the browser. Keyboard support is part of the interface, not an extra feature bolted on later.

What to learn next

When a custom control takes over keyboard behavior, making clickable elements accessible covers the missing pieces, and keyboard navigation patterns shows the standard key maps for common widgets.