This Keyboard Tester runs in a web browser, not as a native Android app, so testing an Android-connected physical keyboard depends on whether the browser reports its key events.

Its documented platform support covers modern browsers on Windows, macOS, Linux, and Chromebooks; Android is not listed as a verified platform. You can try the browser workflow on an Android phone or tablet when external keys reach the page, but use a desktop or laptop for a fully supported test. The steps below show the conditional Android workflow, explain what each result proves, and identify cases where Android or the browser prevents a complete check.

keyboard tester on android
Keyboard Tester on Android: Test a Physical Keyboard

Browser-Based Testing, Not an Android APK

The visual QWERTY keyboard in this tool is an event display, not the keyboard you normally type with on an Android touchscreen. It shows which physical key events the active browser page receives. It therefore tests an external Bluetooth or USB keyboard when one is connected, rather than assessing the quality of Android’s built-in touch keyboard.

  • No Android installation: The tester is a web page, so there is no APK to download and no requirement to install an extension or create an account.
  • Physical-key focus: The page captures presses only after its on-screen keyboard has been clicked or focused.
  • Visible pass status: A tested key stays marked, making keys that never lit up easy to identify.
  • Event details: The last-key panel shows the reported key, code, and keyCode values.

A successful on-screen response proves that the browser received that particular press. It does not establish every internal behavior of the keyboard, and an Android browser may not expose keys that the operating system or hardware handles first.

Prepare the Android Device and External Keyboard

Connect the physical keyboard to the Android device using a supported Bluetooth or USB connection, then open an ordinary text field. Press the key you want to check. This preliminary comparison shows whether Android itself receives the input before involving the tester.

If the key produces text in the plain text field but does not appear in the Keyboard Tester, the likely issue is focus, page handling, or an intercepted browser event. If it fails in the plain text field too, the cause may be a physical, connection, or operating-system problem that exists before the tester receives anything.

Use the browser’s normal navigation controls to leave the tool page when needed. Keys such as Space, Tab, Backspace, arrows, and function keys are held in place only while the tester’s on-screen keyboard is focused, so an active test session does not unexpectedly scroll or navigate away.

Run the Keyboard Test on Android

  1. Connect and verify the keyboard. Attach the external keyboard to the Android device and confirm in a plain text field that a sample key produces the expected character.
  2. Open the tester. Load the Keyboard Tester in a modern browser on the Android device. The page itself requires no installation, sign-up, or extension.
  3. Activate event capture. Click or tap the tester’s visual on-screen keyboard area. Where keyboard navigation is available, you can also tab into it. Until this area is focused, the page may not capture physical-key presses.
  4. Press one key at a time. Work across letters, numbers, symbols, modifiers, Space, Enter, Backspace, arrows, and other available keys. The matching on-screen button should light up and remain marked as tested; a held key glows while you hold it.
  5. Check the latest event. Read the last-key panel after each press. It reports the key value, code value, and numeric keyCode associated with the most recent event.
  6. Review missing responses. Look for keys you physically pressed that never lit up. Hold several keys together as well when investigating rollover or ghosting, and note which combinations register every press.
  7. Reset for another pass. Select Reset to clear all tested marks and the last-key readout. This is useful after cleaning beneath a troublesome key or when you want a clean second check.

If no on-screen key responds, return to the focus step rather than continuing through the entire keyboard. A single missed focus can make an otherwise working keyboard appear completely unresponsive.

Read Key, Code, and keyCode Correctly

The three values describe different parts of a key event. Reading them together helps separate a layout or remapping issue from a physical key-position problem.

Reported value What it represents How it behaves
key The character or key name produced by the press. It can change with the active language layout or held modifiers. Examples include a, Enter, or ArrowUp.
code The physical position of the key on the keyboard. Values such as KeyA or Space stay the same even when the character layout changes.
keyCode An older numeric identifier for the key. Some older software and games still rely on this value when interpreting keyboard input.

For example, a key value of a paired with a code of KeyA indicates that the browser recognized the physical A position and produced the letter a under the current layout. If the code still identifies the expected position but the character is different, investigate your Android keyboard layout, language setting, or remapping before assuming the hardware switch is broken. A fuller reference explains how to test keyboard input and find dead keys online.

Match Symptoms to Likely Causes

Use the visible behavior and the last-key information together. The table below separates common symptoms without declaring every unlit key defective.

Observed result Likely interpretation Next check
A pressed key lights up and stays marked. The browser received and reported that key event. Continue testing the remaining keys.
A key stays highlighted after you release it. A sticky or chattering-key symptom may be present. Reset, release the key again, and check whether the highlight remains.
One tap fires the key repeatedly. The switch may be chattering or the key may be mechanically stuck. Clean or inspect the affected key and arrange repair if the behavior continues.
The character is wrong, but the physical code looks correct. The layout, language, or software remapping may be responsible. Check Android’s language and keyboard configuration.
A key never lights up. Focus loss, operating-system interception, or a physical fault are possible. Refocus the tester and compare the key with a plain text field.
A key vanishes during a multi-key combination. The combination may be affected by rollover or ghosting. Repeat the combination and note which individual presses register.

For suspected dead keys, use Reset and complete a fresh pass after checking focus. A key that consistently remains dark after those precautions is a likely dead, dirty, disconnected, or failing key. For suspected ghosting, hold several keys simultaneously and watch which on-screen buttons remain lit; the test reveals the dropped input rather than assigning a hardware rating.

Recognize Browser and Android Limits

Some keys are handled by the operating system or hardware before the browser can report them. Examples include some Fn combinations, media keys, and lock keys. Their failure to appear in the tester does not automatically mean the physical keyboard is broken. A browser-level result therefore cannot diagnose every key that Android reserves for system control.

Android’s current focus also matters. If the on-screen keyboard loses focus, physical presses may stop updating the display. Click the tester’s keyboard area again, or tap elsewhere to leave it if you need to navigate the page. On devices with an Escape key, Escape can also be used to leave the focused capture area.

All detection runs locally in the browser. The page does not record, store, log, or upload what you type, so closing or refreshing it removes the session data. This local workflow also does not measure polling rate, complete hardware rollover capacity, or the Android touch keyboard’s performance. It answers one practical question: which physical key events does the active browser page receive?