Keyboard Test

Introduction

The DeviceHub Keyboard Test is a free online keyboard check that visualizes every key press inside your browser without downloads, drivers, or accounts. Open the page, click into the interactive area, and press keys while an on-screen US QWERTY reference lights matching switches, including function keys, modifiers, the navigation cluster, arrow keys, and the space bar. The tool listens for standard KeyboardEvent keydown and keyup traffic, the same events web apps and games receive, so a working highlight here is a strong baseline before you blame a single application. Mechanical enthusiasts chasing stuck switches, laptop owners after spills, help-desk technicians, competitive gamers verifying basics before a tournament, students on locked-down school machines, and anyone returning a defective board use it as a neutral first step. Because it runs entirely in the tab, you can test keyboards on Windows, macOS, Linux, or ChromeOS without administrator rights or vendor utilities. Schools and libraries appreciate that nothing needs installing on managed desktops. If you cleaned a board, swapped a wireless dongle, updated the OS, or suddenly lost a cluster of keys in every app, this visual map answers the fundamental question, does the browser see this physical key, in seconds rather than minutes of driver reinstalls. Retail floor staff demoing pre-built PCs also prefer a bookmarkable page over hunting for manufacturer control panels that differ on every SKU.

What this tool does

This tool attaches keyboard listeners to a focused test surface, maps each event’s physical code onto a virtual layout, and highlights keys while they remain down. A live log shows the code string, the character when applicable, and modifier state so you can separate physical position from printed legend, critical when diagnosing layout or language mismatches. Reset clears the board and history so you can start a fresh pass after cleaning or reseating a cable. Status messaging reminds you when focus leaves the page, because keystrokes then go elsewhere and the board appears “dead.” The intent is a complete keyboard smoke test: focus, press, confirm highlight and release, exercise modifiers, then reset. It does not claim to measure debounce firmware, scan-matrix electrical limits, or USB HID report rates; for simultaneous-key behavior use Keyboard Ghosting Test and Keyboard Ghosting Test, and for speed-and-accuracy practice use Typing Test. Side buttons on some gaming boards that emit macros may appear as unexpected codes or nothing at all, that is useful diagnostic information about how the OS remaps them before Chrome or Firefox ever sees them. The virtual board is a reference overlay, not a claim that your hardware is a full-size ANSI board; compact sixty-percent and seventy-five-percent layouts still produce codes for the keys they physically have.

When to use it

Use the Keyboard Test before gaming sessions, coding marathons, remote desktop work, exam platforms, and RMA returns when you need confidence every switch registers outside a single vendor app. Run it after spills or deep cleans, after installing OS updates that change input method editors, after docking a laptop with an external board, and whenever a meeting or IDE shortcut “does nothing” while other keys feel fine. IT teams can ask users to open this page so both sides share a common baseline outside proprietary keyboard software. Retail staff demoing floor models can show dead keys without loading manufacturer utilities. Parents helping kids with school Chromebooks use it to confirm the built-in board before an exam locks input. If you only need multi-key ghosting, simultaneous-key counts, or WPM accuracy, jump to those specialized input tools; start here when you need human-readable proof that individual presses light the matching key. Call-center supervisors also bookmark this page as a shared triage link when agents report intermittent keys across softphones and browsers. Freelance writers validating a travel keyboard before a deadline week should run a full alphabet and modifier pass once after unpacking from luggage.

How it works

On focus, the page listens for keydown and keyup (and related keyboard events where helpful) and reads KeyboardEvent.code for physical position plus KeyboardEvent.key for the character the current layout produces. The on-screen board is a US QWERTY reference; codes still arrive from AZERTY, QWERTZ, or Dvorak hardware, which is how layout confusion becomes visible. Highlight state tracks pressed keys until keyup or a reset. Some browser and OS shortcuts, F5 refresh, Ctrl+W close tab, Alt+Tab, never fully reach the page or navigate away; that is expected platform behavior, not a DeviceHub bug. Remote desktop and virtualization layers can swallow combinations before the guest browser sees them. No Permissions API prompt is required: keyboard events are available to focused documents without microphone or camera grants. Secure HTTPS hosting keeps the rest of DeviceHub consistent, but key listening itself does not need getUserMedia. DeviceHub does not upload keystroke streams; handling stays in tab memory for visualization during the session. Extensions that redefine shortcuts can intercept events before your listeners run, private windows help isolate that class of false negatives. Laptop Fn layers may emit media keys or nothing depending on firmware mode; comparing an external USB board separates chassis firmware from browser quirks. Autorepeat from the OS may fire repeated keydowns for a held key; the highlight still represents a single physical switch until keyup, which keeps the smoke-test mental model simple.

Step-by-step instructions

1. Open this DeviceHub page over HTTPS in Chrome, Firefox, Edge, or Safari and click the interactive Keyboard Test panel or Start focus control so key events route into the tool rather than the address bar or a neighboring form field.
2. Press letter, number, and punctuation keys one at a time, confirming each matching key on the virtual board lights on press and clears on release, then glance at the event log for code and character values that match your expectation.
3. Exercise modifiers, Shift, Ctrl or Control, Alt or Option, and Meta or Command, alone and with a letter, noting any OS-reserved chords that never appear because the system consumed them before the page could listen.
4. Walk the function row, arrows, navigation cluster, and space bar, watching for dead zones that suggest membrane damage, liquid residue, or a failing wireless link rather than a single-app binding issue in one game or IDE.
5. Optionally tap a suspect key rapidly to expose intermittent contacts that casual typing might miss, then use Reset to clear highlights and the log before a second clean pass after you reseat the cable or swap batteries.
6. When finished, click away or close the tab; no permission revoke is required because the tool never requested privileged device access, just avoid typing passwords into the log on shared screens or screen shares.

Common problems

Keys that never light usually mean focus left the tester, a browser or OS shortcut ate the event, a remote desktop session filtered the combination, or the switch itself is dead. Stuck highlights can indicate a physically held key, sticky debris, or a missed keyup after focus changes. Wireless boards with low batteries drop intermittent events that look like random dead keys. Compact laptop layouts hide secondary functions behind Fn, so the printed legend may not match the code the browser reports. IME composition for non-Latin input can alter key sequences mid-test, finish or cancel composition before diagnosing. If everything works here but fails in one game, investigate that game’s exclusive raw-input path or overlay next. Extension shortcut managers are a frequent false alarm; disable them temporarily. KVM switches occasionally drop certain modifiers until you toggle the hotkey that releases keyboard control back to the PC. Virtual machines with USB passthrough may remap media keys differently than the host OS, so compare host versus guest before concluding the hardware failed.

Privacy explanation

Keyboard events stay entirely on your device during this test. DeviceHub does not upload keystrokes, build typing profiles, or store your log on a server. The on-page log exists only for the current session and clears when you reset or leave. No microphone, camera, or HID device permission is requested. Avoid entering passwords, recovery codes, or personal messages while the log is visible on a shared display. Closing the tab ends listeners for that page; nothing continues in the background. Clearing cookies does not affect key testing because no privileged grant was stored. Prefer a private window if you are diagnosing extension conflicts without changing your everyday profile. Screen recordings shared with support should crop or blur any accidental desktop content outside the tester.