Skip to content
Testpartout

Device tests · Input devices

Keyboard Test

This keyboard test shows which keys your browser actually receives. Start the test, press keys one at a time, and each key that produces an event appears in the detected list with the values the browser reported for it.

It is a detection check, not a repair tool. It tells you whether an event arrives, what physical key position the browser assigned to it, which character it produced, and whether modifiers or auto-repeat were involved.

  • No time limit
  • Physical key positions
  • No permissions required

Not listening

Start the test, then press keys one at a time. Nothing is recorded until you start.

The keyboard test is not listening.

Detection summary

Stopped
Keys detected
0
Currently held
0
Repeat events
0

keydown events flagged as auto-repeat

Last key
—

No events yet

Last event detail

event.key
—
event.code
—
State
—
event.repeat
—

Modifier state

  • Shift: off
  • Ctrl: off
  • Alt: off
  • Meta: off

Modifier state is read from the most recent key event, so it updates when you press or release a key while holding a modifier.

Keys detected in this session

No key events yet. Start the test and press a key.

A key that produces no event here is not proof of broken hardware. The browser or operating system may reserve that key, a different keyboard layout may report it differently, or the key may genuinely be failing. Treat a missing key as a reason to check further, not as a verdict.

Your result

What your result means

Every key you press should appear in the detected list within a moment of pressing it. If a key appears, the whole chain from the switch under your finger to the browser is working for that key.

If a key never appears, the chain is broken somewhere — but the browser cannot tell you where. A reserved system shortcut, a keyboard-layout difference, a driver, a stuck switch and a dead switch all look identical from inside a web page: no event arrives.

  • event.code identifies the physical position of the key, so it stays the same across layouts. It is the value to trust when checking hardware.
  • event.key is the character or name the key produced, which changes with your layout, language and any modifier you are holding.
  • A key that shows as held after you released it usually means the release event was lost, most often because focus left the page. Reset clears the state.
  • Repeat events are counted separately: holding a key normally produces one initial event and then a stream of auto-repeat events.
  • No key is judged good or bad here, and no result is scored or compared against anyone.

Procedure

How the test works

  1. 01

    Start the test

    Nothing is recorded until you press “Start keyboard test”. Starting focuses the test area and begins listening for key events.

  2. 02

    Press keys one at a time

    Press each key you want to check. Every key that produces an event is added to the detected list and stays there for the rest of the session.

  3. 03

    Watch the held state

    Keys you are holding down are marked as held, and the count of currently held keys updates as you press and release.

  4. 04

    Check the reported values

    The last event panel shows the physical code, the produced key value, whether it was a keydown or a keyup, and whether auto-repeat was active.

  5. 05

    Check modifiers

    Shift, Ctrl, Alt and Meta are reported from the most recent event, so you can confirm a modifier is registering even when it produces no character of its own.

  6. 06

    Reset or stop

    Reset clears the session and starts from an empty list. Stopping ends listening so normal typing on the page behaves as usual.

Methodology

How Testpartout measures this

The method below is exactly what the code on this page does — nothing is described that is not implemented.

What the implementation does

  • The test listens for the browser's keydown and keyup events while it is active, and ignores everything before you start it.
  • Keys are identified by KeyboardEvent.code, which describes the physical key position rather than the character produced.
  • If a browser or input method reports no code, the produced key value is used instead, so the key is still visible in the detected list.
  • A key is added to the detected list the first time it is seen and is never added twice, so the count is a count of distinct keys.
  • Currently held keys come from keydown and keyup pairs: a key is held from its keydown until its matching keyup.
  • keydown events flagged as auto-repeat are counted separately and do not add duplicate keys to the list.
  • Modifier state is read directly from each event's shift, ctrl, alt and meta flags, not inferred from the keys in the list.
  • If the page loses focus or becomes hidden, held keys are cleared, because release events can be missed while the page is not active and a key must never look permanently stuck.
  • Only plain presses of keys that would scroll the page are prevented while the test area is focused. Browser and system shortcuts are not intercepted.
  • Nothing is scored, no personal best is stored and no result is written to your browser or sent anywhere.

Limits of a browser measurement

  • The browser only sees the events your operating system passes to it. A key reserved by the system or by the browser itself may never reach this page.
  • The absence of an event is not proof of a hardware fault. It is a reason to test the same key in another application or on another machine.
  • KeyboardEvent.key depends on your keyboard layout, language and the modifiers you are holding, so the same physical key can report different values.
  • Some keys never produce standard key events at all, including certain media, function-layer and vendor-specific keys handled entirely in firmware.
  • On phones and tablets, on-screen keyboards often report generic or empty values, so physical-key diagnosis is not meaningful there.
  • Remote desktop sessions, virtual machines, key-remapping utilities and accessibility tools can change or swallow events before the browser sees them.

Privacy

What happens to your data

This section describes the behaviour of the code on this page, not an intention.

  • The test runs entirely in this page. No key, no code and no timing is sent anywhere.
  • No key log is stored: the detected list exists only in the page and disappears when you reset, stop or leave.
  • Nothing is written to your browser's local storage by this test, and no personal best is kept.
  • No account, sign-in or permission is required to run the test.
  • No device fingerprint is built and no keyboard identifier is collected. The test reads the events of the keys you choose to press, nothing more.
  • Because key events can contain anything you type, avoid typing passwords or other sensitive text while the test is listening.

Troubleshooting

If the test does not behave as expected

No keys are being detected

Check that the test is listening — the panel says so in words — and click inside the test area once to give the page focus. A page that does not have focus receives no key events.

A key stays marked as held

The release event was probably lost while the window was inactive. Held keys are cleared automatically when the page loses focus or is hidden, and Reset always clears them.

One specific key does nothing

Try the same key in a plain text field and in another application. If it works elsewhere, the key is likely reserved by your browser or system rather than broken.

The reported character is wrong

That is event.key, which follows your active keyboard layout and language. Compare the code value instead: it describes the physical position and does not change with layout.

Function or media keys are missing

Many laptops handle brightness, volume and similar keys in firmware or require a function-layer combination, so no key event ever reaches the browser.

Nothing works on my phone

On-screen keyboards do not behave like physical keyboards and often report empty or generic values. Use this test with a physical keyboard for a meaningful result.

Factors

Common problems this test can and cannot show

A missing key event has several possible causes. These are the usual ones, and what each looks like here.

Reserved shortcuts

Browsers and operating systems claim some combinations for themselves. Those presses may never reach the page, so a key can look undetected while working perfectly.

Keyboard layout differences

The same physical key produces different characters on different layouts. The code value stays stable; the key value does not.

Stuck or dirty switches

A stuck key can report a continuous stream of events, or a held state that never releases. Both are visible here as an unusually high repeat count or a key that stays held.

Worn or failing switches

An intermittent key produces an event sometimes and not others. Pressing the same key several times is more informative than a single press.

Remapping and accessibility tools

Key remappers, sticky keys and similar tools can rewrite or suppress events before the browser sees them, which changes what this page can observe.

Virtual and remote sessions

Remote desktops, virtual machines and streaming clients pass keyboard input through extra layers that can drop or alter events.

FAQ

Frequently asked questions

Can this test prove a key on my keyboard is broken?
No. A web page can only report the key events the browser receives. If a key produces no event it may be failing, but it may also be reserved by your browser or operating system, handled in firmware, or reported differently by your keyboard layout. Test the same key in another application before concluding it is broken.
What is the difference between event.key and event.code?
event.code identifies the physical position of the key and does not change with your layout or modifiers, which makes it the better value for hardware checks. event.key is the character or name the key produced, which depends on layout, language and any modifier you hold.
Why does one key show a large number of repeat events?
Holding a key down makes the operating system send auto-repeat events, and those are counted separately here. A key that produces repeat events without being held may be sticking.
Why did a key stay marked as held?
Its release event never arrived, usually because the window lost focus mid-press. Held keys are cleared when the page loses focus or becomes hidden, and Reset clears them at any time.
Does the test block my browser shortcuts?
No. Only plain presses of keys that would scroll the page are prevented while the test area is focused. Shortcuts that use Ctrl, Alt or the Meta key are left alone, and Tab still moves focus.
Is anything I type recorded or uploaded?
No. Everything stays in this page, nothing is written to your browser's storage by this test and nothing is sent to a server. Even so, avoid typing passwords or sensitive text while the test is listening.
Can I use this test on a phone or tablet?
The page works, but on-screen keyboards often report generic or empty values instead of physical key positions, so the results are not a meaningful keyboard diagnosis. Use a physical keyboard.
Which keys should I expect to be missing?
Media and brightness keys, laptop function-layer keys, vendor keys and some system shortcut combinations frequently never reach a browser. Their absence here says nothing about their condition.

Found an issue with this test? Report it.