Inspiration
A keyboard check is easier to interpret when it separates three questions: did a press reach the browser, is the key still held, and has that key already been tested? KeyboardTester.click provides a visual starting point for those checks. I maintain the project; this portfolio entry focuses on the homepage's desktop keyboard tester.
What it does
The free keyboard tester displays mapped keys, press counters and key history. Layout, keyboard-size and OS-label controls help match the display to the keyboard being checked. Advanced options include session statistics, a heatmap and a text export. No KBT account or software installation is required for this check.
A useful first run is deliberately simple:
- Keep the page focused, choose the closest layout and size, then press Reset.
- Press and fully release a letter key three times slowly. Compare its counter and history entries with those three separate actions.
- Hold it once, then release. The live held state should end on release; the accumulated tested color and counter remain until reset. Remaining tested color alone is not evidence of a stuck key.
- Repeat with other keys, recording any repeatable difference before changing the connection or browser.
The core counter filters held-key auto-repeat. It is intended to count separate presses received by the page, not every repeated character produced by the operating system.
How it is built
The site uses PHP-rendered HTML, CSS and vanilla JavaScript. In the current keyboard script, KeyboardEvent.code selects a key in the visual layout. For ordinary one-character English input, history uses event.key; Space and non-character keys have explicit labels. A physical-position code and the character produced by the active OS layout are different concepts.
On keydown, the script tracks held keys and ignores another count when event.repeat is true or that code is already held. keyup clears the held state. When the window loses focus or the document becomes hidden, the script clears live held states without erasing the session history. Reset clears both.
The public repository is available for reference, but its snapshot can differ from the deployed site. The behavior described here was checked against the current live keyboard script on September 23, 2026.
Challenges
Browser input is only one view of a keyboard. OS or browser shortcuts can intercept keys, focus changes can interrupt event delivery, and alternate layouts can produce different characters. A missing response needs a controlled recheck; it does not identify a faulty switch by itself. On-screen pointer clicks exercise the interface and are not evidence that a physical key works.
This project description makes no claim to measure electrical switch behavior, switch travel, true USB polling rate or calibrated end-to-end latency.
Accomplishments
The current implementation keeps live held state separate from accumulated test history and gives users a repeatable press-and-release check. Session statistics and export provide a record to compare alongside browser, OS and connection notes.
What this demonstrates
Input visualizations need explicit state definitions. A tested key is not necessarily a held key, a repeated keydown is not necessarily another physical press, and code is not the same as a character. Those distinctions are more useful than treating every browser event as a hardware diagnosis.
What's next
Feedback is welcome on reproducible key-mapping or accessibility problems. Include the browser, OS, selected layout, expected behavior and observed behavior. This entry describes the existing tool; it does not promise a release date or unimplemented features.
Disclosure
Project description prepared with AI assistance and checked against the current implementation. It describes an observation procedure, not results measured from a particular physical keyboard. The source license distinguishes code from branding, stock media and third-party components.
Log in or sign up for Devpost to join the conversation.