JavaScript Keycode Finder

Press any key to see its event.key, code, and keyCode.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Press any key and this page reports the three identifiers a keyboard handler can test — the legacy numeric keyCode, the character-level event.key, and the physical event.code — along with which modifiers were held and whether the browser is auto-repeating.

How to use it

1Just press the key. There is no field to focus first — the listener sits on the window.
2Read the large keyCode figure, then the event.key and event.code cards below it; those two each have their own Copy button.
3Hold Shift, Ctrl, Alt or Cmd while pressing to see the matching pills light up, and hold a key down to watch Repeat light up too.

Example

Input: the 1 above the letters, then the 1 on the numeric keypad
Output: event.code Digit1, keyCode 49 — then event.code Numpad1, keyCode 97, with event.key 1 both times

That pair is the clearest way to see which identifier you should be testing. event.key is the character produced, so it moves with Shift and with the layout — a becomes A when Shift is held. event.code names the position and never changes, which is why WASD movement or any positional shortcut should compare code while a text-entry shortcut compares key. keyCode is the deprecated numeric form: worth recognising in an older handler, but a bare number with no name to read and no future guaranteed. One display detail — the space bar shows the word Space in the event.key card, because the real value is a single space and would look like an empty box.

What happens to your data

A single keydown listener on window backs this page, and each press overwrites the one stored object — no array, no transcript, no counter, so the only keystroke that exists at any moment is the one on screen, and the listener goes when you navigate away. The handler swallows the browser's default action for most keys, with two exemptions: Tab and Escape stay functional so the page cannot trap a keyboard user, and any Ctrl or Cmd chord is left to the browser while still being reported.

Last updated August 2026

A shortcut you wrote fires on your machine and does nothing on a colleague's, or a handler you are sure is correct never runs at all. At that point the useful move is to stop reasoning about what the browser ought to send and watch what it actually sends when that key goes down — on that keyboard, on that operating system, in that browser build.

Settle one thing before you start: whether you should be listening for keys at all. Key events describe commands — a shortcut, a game control, an Escape that closes a dialog. They are a poor way to learn what somebody typed, because a great deal of text arrives with no meaningful keydown behind it. Pasted, dictated, autofilled and input-method text all land in the field without a press you can read. If your question is what the field contains now, the input event answers it and keydown will mislead you.

The other thing to know up front is that a page only ever sees what the operating system and the browser have already passed down. Combinations those two claim for themselves — switching windows, closing a tab, the screenshot chord — are handled above the page and never arrive at all, so a key that produces nothing on screen is telling you something real about where your shortcut is allowed to live.

The common mistake is reading the old numeric codes as character codes. They are not ASCII. The same number comes back whether or not Shift is held, the values for punctuation and symbols were never agreed between browsers, and a table copied out of a fifteen-year-old tutorial may not describe any keyboard you own.

How it works

Toolvore reads the properties the browser has already attached to the keyboard event and prints them unaltered. There is no lookup table of names sitting in between, so what appears is what your own handler would receive on this machine, with this layout, in this browser — which is the value of it and also the limit. It is a mirror rather than an authority: a number you read here is evidence about your setup, not a specification that other browsers are obliged to follow. The weak spots follow from that. It watches keydown alone, so a key coming back up is invisible, and a shortcut meant to fire on release cannot be tested. Nothing separates a left modifier from a right one beyond the name in the code field. There is no flag for whether an input method was mid-composition, so the placeholder value many browsers report during composition has to be recognised from the number itself. And a key the operating system has taken for itself never reaches the listener, which looks on screen exactly like a key that produced no event.

Common use cases

Working out why a keyboard shortcut fires on your machine and not on a colleague's
Choosing which identifier a keydown handler should compare before you write the condition
Checking whether the browser or the OS is swallowing a chord before your page ever sees it
Reading the modifier flags for a shortcut that must work with both Cmd and Ctrl
Confirming what an unfamiliar key on a compact or external keyboard actually reports
Seeing what the numeric keypad sends with Num Lock on and off
Making sense of a bare numeric code found in an inherited handler

Frequently asked questions

Is event.keyCode deprecated, and what should new code use instead?＋

It is. keyCode came out of the standard years ago and survives only because so much existing code still reads it. No browser has announced a removal, and none has promised to keep it either. The trouble with writing new code against it goes beyond the deprecation, though. A bare number carries no name you can read in a diff, its values for punctuation and symbols were never agreed between browsers, and it cannot describe keys that appeared after it was frozen. Its behaviour for letters is coarser than people expect, too — the same value comes back whether or not Shift is down. Use the named properties for new work and keep the number for reading old handlers.

What is the keycode for Enter, Escape, Space and the arrow keys?＋

The numbers quoted most often are 13 for Enter, 27 for Escape, 32 for Space, 9 for Tab, 8 for Backspace, and 37 through 40 for Left, Up, Right and Down in that order. Letters use the uppercase ASCII range, so A to Z is 65 to 90 regardless of the case of the character produced. Those particular values are consistent enough across browsers that they persisted, which is why they turn up in so much old code. The named equivalents are more readable and worth preferring — Enter, Escape and ArrowLeft rather than 13, 27 and 37. One catch: Enter on the numeric keypad has its own position name while reporting the same key name as the main one.

Why does my keyboard shortcut break on an AZERTY or Dvorak layout?＋

Because the comparison is against the wrong thing. A layout maps physical positions to characters, so the key that sends A on QWERTY sends Q on AZERTY. A shortcut written against the character therefore moves around the board when somebody changes layout, and a shortcut written against the position stays put. Neither is right in every case. Movement keys want the position, so the cluster keeps its shape. A mnemonic wants the character, because the user expects Ctrl and the key labelled S to save no matter what is underneath it. Decide which of the two your shortcut is actually about, then compare that property. Numeric codes make this harder, since they describe a position but read like a character.

Why do some keys never reach my handler at all?＋

Two layers get there before you do. The operating system takes the first cut — window switching, screenshots, volume and brightness, and on many laptops the Fn key, which is wired into the keyboard's own controller and frequently produces no event whatsoever. The browser takes the second: opening and closing tabs, focusing the address bar, full screen and the developer tools chord are reserved, and a page cannot cancel them. Whatever survives both reaches your listener. So when a combination produces nothing at all, that is your answer rather than a bug — it belongs to something above you, and no amount of preventDefault will claim it. Choose a different chord instead of fighting for one people already expect to behave a certain way.

How do I write one shortcut that uses Cmd on a Mac and Ctrl on Windows?＋

Read the modifier flags rather than the key. The meta flag is Command on a Mac and the Windows key on a PC; the control flag is Control on both. The usual approach is to decide once, from the platform, which of the two counts as the command modifier, and expect only that one — accepting either everywhere means Ctrl and the letter W trigger your app's action on a Mac, where the user meant nothing of the sort. Watch AltGr on European layouts as well: pressing it sets the control and alt flags together, so a Control-based shortcut can fire while somebody is calmly typing an accented letter or a currency symbol.

Why does holding a key down fire my handler over and over?＋

That is the operating system's auto-repeat, the same mechanism that fills a text field with a row of identical letters. After an initial delay it sends keydown again at the repeat rate, and each one is a genuine event as far as the page is concerned. Those repeated events are marked as repeats, so a handler that should act once — opening a menu, toggling a panel, firing a weapon — can ignore anything carrying that mark and respond only to the first press. Continuous movement usually wants the opposite arrangement: record the key as held on the first press, keep moving on your own animation frames, and stop on release, rather than tying motion to a repeat rate the user sets in their system preferences.

Why does keydown not tell me which character was typed?＋

It reports which key went down, which is a different question, and the two diverge further the more the input relies on the operating system. Dead keys on European layouts announce themselves as dead and produce nothing until the following press resolves the accent. Input methods for Chinese, Japanese and Korean run a composition session in which presses are candidate selection rather than text, and browsers report a placeholder value throughout. Paste, autofill, dictation and most mobile soft keyboards deliver text with no faithful keydown behind it at all. For anything that ends up as characters in a field, listen to the input or composition events and read the value; keep keydown for commands.

Does this page record what I press, or send it anywhere?＋

No, and there is nothing in it that could. No field is focused, no request goes out when you press a key, and no record accumulates — each press replaces the previous reading in the page's memory, and that memory goes when the tab does. Nothing is transmitted, which matters more here than on an ordinary page, because a keystroke inspector is precisely the shape of thing worth being suspicious of. Two habits are still sensible. Do not test a shortcut by typing part of a real password to see what the keys report. And remember that anything you copy out with the copy buttons lands on your system clipboard, where other applications on the machine can read it.