The short answer
A keyboard key that does not work may be affected by application focus, layout, remapping, accessibility settings, a connection problem or a physical issue. Check whether the browser receives a deliberate press and release before assuming the key is broken. One missing browser event cannot identify a damaged switch or keyboard circuit.
Start the Testpartout Keyboard Test, keep the page focused and press the affected key on its own. Compare a known working key, then release both. The test lists observed key events, held states, modifiers and repeats. It does not record a typing passage, store the diagnostic state or certify every special key the operating system may handle outside the browser.
Run the Keyboard Test first, then compare the checks below. Explore Input Device Tests for related checks.
Quick diagnostic checklist
- Start Keyboard Test and keep the browser window focused.
- Press and release the affected key once; compare a known working key.
- Check whether the physical key code and produced character match your selected layout.
- Test Shift, Ctrl, Alt and Meta individually before testing combinations.
- Distinguish a held-key repeat from repeated events after a brief tap.
- Check remapping, keyboard layout and accessibility settings.
- Reconnect a USB or wireless keyboard and compare another browser or device when available.
- For debris, follow manufacturer cleaning guidance without opening or modifying the keyboard.
First separate missing events from wrong characters
A key can generate an event but produce a different character from the printed label. Keyboard Test shows the browser’s physical-key identifier where available and the produced key value. The code and character answer different questions: a physical location may stay the same while the active keyboard layout changes what it types. Compare both before treating an unexpected symbol as a broken key.
If no event appears at all, check that the browser window has focus and listening has started. Compare a nearby key that normally works. Clicking into another application or opening a system panel changes where input goes. The page cannot receive an event that the operating system never delivers to the browser. Repeat the simple press with the test area focused instead of testing through several shortcuts at once.
One key does not register: make the comparison controlled
Press the affected key alone, release it fully and repeat a few separated taps at normal force. Compare a working key using the same action. Do not pound the key or use a complicated combination to provoke an event. A missing ordinary letter across several applications is a different observation from a missing media key or system shortcut; those may never be exposed as ordinary browser keyboard events.
Try the same key in a simple text field outside the diagnostic page, then another browser if practical. If the key works there, compare focus, browser restrictions and the test’s visible event representation. If it fails across independent applications and another compatible device, hardware involvement becomes more plausible. That comparison still does not reveal whether the cause is a key mechanism, firmware, connection or another internal component.
Repeating keys versus normal held-key repeat
Holding a letter normally generates repeated keydown events after the system’s repeat delay. The browser repeat flag describes that behavior and the test distinguishes repeated events from initial presses. A high repeat count during a deliberate hold is not automatic evidence of keyboard failure. Release the key and observe whether the held indicator clears before trying isolated taps.
An unwanted repetition symptom is more concerning when a single brief tap produces extra characters in multiple applications. System repeat settings, remapping software or accessibility controls can also influence what you see. Compare a brief tap with an intentional hold, keeping the conditions consistent. Browser events do not directly inspect switch bounce or decide whether a mechanism is worn; avoid treating an event count as a guaranteed hardware diagnosis.
A held indicator is not always a physically stuck key
A key can remain physically depressed, but software can also miss the corresponding release when focus changes. Testpartout clears held states when the window loses focus or the page becomes hidden to avoid leaving a misleading stuck indicator. If a held state persists while the page remains focused, release the key deliberately and compare the displayed last event.
Check whether the key visibly returns to its normal position without forcing it. If a cap or mechanism catches, follow the manufacturer’s instructions rather than pulling parts off a laptop keyboard. A liquid spill, cracked mechanism or battery damage calls for supported service, not repeated presses. The browser can show a received release; it cannot determine whether every mechanical part moved correctly inside the keyboard.
Modifiers, layouts and browser-reserved shortcuts
Test Shift, Ctrl, Alt and Meta separately, then combine them with an ordinary key. Left and right modifiers may expose different physical codes but similar character values. AltGr and language input methods can involve platform-specific combinations. Check the active system layout if the produced character surprises you; the printed cap alone does not tell the browser which layout to use.
Some shortcuts are reserved for the browser or operating system. Tab remains available for navigation, and combinations that open browser tools, switch applications or trigger system actions may be handled outside the page. Testpartout does not deliberately trap all shortcuts. A missing shortcut event is therefore not proof that one modifier failed. Use standalone modifier observations and an ordinary typing comparison instead of relying on a reserved combination.
USB keyboards, ports and reconnecting safely
For a USB keyboard, reseat the connector and wait for recognition. Compare another compatible direct port if one is available. A hub, dock, adapter or extension cable adds another path that can influence connection reliability. Observe whether the entire keyboard disconnects or only one key behaves differently; those are useful distinctions to report rather than a diagnosis of the port or switch.
Restarting an application or the computer can help compare a transient software state, but it is not a universal repair. Save work before restarting and repeat the same basic press afterward. If a manufacturer recommends firmware or configuration updates, use its official guidance rather than a generic driver-repair site. Do not install software merely because an unknown webpage claims it can identify every keyboard problem.
Wireless and Bluetooth keyboards
Check battery charge, pairing and whether the keyboard is connected to the device you are testing. Multi-device keyboards may be switched to another computer or tablet. A dedicated USB receiver and Bluetooth are different connection modes; check the mode selected by the keyboard. Receiver placement and distance can influence wireless reliability, but browser events alone cannot measure radio interference.
If the keyboard supports another connection method, compare it using the manufacturer’s instructions. A problem that disappears when connected by cable suggests a different path deserves investigation; it does not automatically prove a radio component failed. Keep the test action and selected device the same. Do not reset pairing or firmware without checking what settings will be lost, particularly on shared or managed equipment.
Laptop keyboards and software settings
A laptop’s function row may switch between media controls and function keys depending on an Fn setting. Those controls can be handled by firmware or the operating system instead of ordinary browser events. Check the exact model’s keyboard guidance and compare the same key in an application where its intended action is obvious. A missing brightness-key entry on this page does not establish hardware failure.
Inspect remapping utilities, active layouts and accessibility options such as slow-key, filter-key or sticky-key behavior where your platform provides them. Those options may intentionally ignore brief presses, delay acceptance or keep modifiers active. Change one relevant setting at a time and remember its previous value. Do not disable accessibility features indiscriminately; they may be important to the person using the device.
Debris, safe cleaning and when hardware becomes plausible
Dirt around a key can interfere with its movement, but a webpage cannot inspect that mechanism. Disconnect or power off the keyboard as recommended and follow the manufacturer’s cleaning instructions. Avoid applying liquid directly, using force, removing laptop keycaps without authorization or inserting metal tools. If the device was exposed to liquid or shows damage, stop and seek supported advice rather than continuing an aggressive test.
Persistent failure of the same ordinary key across browsers, applications and another compatible computer makes a keyboard-side issue more plausible. Record which key, what action failed and whether another connection changed the symptom. That evidence is useful to support without claiming an exact electrical fault. A successful run likewise shows observed events, not a promise that intermittent faults will never recur.
Methodology and privacy of this event check
After Start, the current implementation listens for keydown and keyup events while the test is active. It records physical codes where available, key values, repeat flags and modifier states in page memory. Plain scrolling keys can be prevented from moving the page while the test area has focus, but navigation and system shortcuts are not universally suppressed. Stop removes active listening; lost focus clears held states.
The diagnostic state is not scored, saved or uploaded. Keyboard events used by this test are not sent to analytics. Do not type passwords or private text to troubleshoot a key; an isolated non-sensitive press is sufficient. This is not a hardware circuit test, a key-logging service or a universal keyboard-layout certification. Read the input-device hub for mouse and controller comparisons when your symptom affects more than one input device.
Frequently asked questions
Why does a key type the wrong symbol?
The active layout, modifiers or input method can differ from the printed key label. Compare the physical code and produced character and check your system layout before assuming a key fault.
Are repeat events a sign of a broken key?
Not during an intentional hold: operating-system key repeat is normal. Extra events from brief taps deserve comparison across applications but do not establish a specific hardware cause.
Can this page test every function or media key?
No. Firmware, the operating system or browser may handle certain keys and shortcuts without exposing ordinary events to the page.
Does the Keyboard Test save what I press?
No. Diagnostic events stay in the current page state and are not saved or uploaded. Use isolated, non-sensitive key presses rather than private text.
Keep the next step specific
Repeat the Keyboard Test after changing one relevant setting. Read our methodology for browser measurement limits and privacy policy for current data handling. If you find a mismatch between this guide and the test, send the non-sensitive details through Contact.