DEV Community: Chandra Sekhar Dey

Building a Function Key (F1–F12) Tester: Handling the Fn-Row Mess Across OSes

Chandra Sekhar Dey — Wed, 30 Sep 2026 21:24:57 +0000

Function keys seem like the simplest possible thing to test — 12 keys, press them, see if they register. Building the Function Key Test for KeyboardTest.tech turned out to have more edge cases than expected, mostly because F-keys don't behave consistently across operating systems, browsers, or laptop firmware.

The base implementation is simple enough
javascript
const fKeys = ['F1','F2','F3','F4','F5','F6','F7','F8','F9','F10','F11','F12'];
const registered = new Set();

document.addEventListener('keydown', (e) => {
if (fKeys.includes(e.key)) {
registered.add(e.key);
updateKeyUI(e.key, true);
}
});

document.addEventListener('keyup', (e) => {
if (fKeys.includes(e.key)) {
updateKeyUI(e.key, false);
}
});

That covers the happy path. Here's where it got complicated.

Problem 1: laptops remap the entire row by default

On most laptops, F1–F12 aren't F-keys out of the box — they're brightness, volume, media playback, etc., with true function-key behavior gated behind an Fn modifier (or the reverse, depending on a BIOS/firmware toggle). A user can press what they believe is "F5" and actually send a browser refresh shortcut instead of a pure F5 keypress, or vice versa, depending on their Fn-lock state — and there's no reliable way to query that state from JavaScript. The most honest fix wasn't a code fix at all — it was adding a visible note in the UI: "If F-keys aren't registering, try holding Fn while pressing them (or check your Fn-lock setting)." Sometimes the right engineering answer is admitting what you can't detect and guiding the user instead.

Problem 2: browsers intercept some F-keys before your JS ever sees them

F1 (Help), F6 (address bar focus in some browsers), F11 (fullscreen), and F12 (DevTools) are commonly intercepted at the browser level for their own default behavior. Depending on the browser, your keydown listener may fire and the default action happens, or the default action wins and your listener never fires at all. This is inconsistent enough across Chrome/Firefox/Safari that I ended up documenting per-browser caveats directly in the tool's FAQ rather than pretending it's uniformly solvable — a decision that felt uncomfortable at first (admitting a limitation) but is more honest than silently failing.

Problem 3: e.key vs e.code actually matters here

Using e.key seemed natural since it directly gives you "F7" as a string. But e.key reflects the interpreted result, which can be affected by OS-level remapping. e.code ("F7" as a physical key code) is more reliable for "did this physical key get pressed" — which is the actual question a hardware tester needs answered, not "what action resulted from this press."

Problem 4: visually distinguishing "not tested yet" from "failed"

A key that simply hasn't been pressed yet looks identical to a key that was pressed but didn't register — from the UI's perspective, both are just "never got a keydown event." I ended up adding an explicit "press every key to complete the test" prompt and a completion indicator, so a user isn't left wondering whether an untested key silently failed.

Takeaway

The hardest part of this feature wasn't the JavaScript — it was accepting that a browser-based tester has a real ceiling on what it can verify when firmware/OS layers get involved, and building the UI to be honest about that ceiling instead of overclaiming certainty.

If you've built anything that tests hardware behavior through a browser sandbox, curious where you've hit similar detection ceilings — would like to compare notes.

Optimizing a Client-Heavy Next.js Tool for Instant Load — What Actually Moved the Needle

Chandra Sekhar Dey — Wed, 16 Sep 2026 18:12:39 +0000

KeyboardTest.tech is almost entirely client-side JavaScript — the whole point is real-time keyboard event handling in the browser. That's exactly the kind of app that can quietly balloon in bundle size and feel sluggish on load if you're not paying attention. Here's what I actually did to keep it fast, and a couple of things I tried that didn't help as much as expected.

Static generation for everything that doesn't need to be dynamic

Since the actual testing logic runs entirely client-side, there's no reason for the tool pages themselves to hit a server on every request. Static generation via Next.js App Router means the HTML shell ships instantly, and the interactive bits hydrate in after — the user sees the page immediately instead of waiting on a render round-trip.

Splitting client components aggressively

Not every part of a tool page needs to be a client component. The static content — headings, FAQ text, the "how to use this" copy — stays as server-rendered content, while only the actual interactive keyboard UI is marked "use client". This keeps the client-side JS bundle scoped to what genuinely needs interactivity instead of hydrating the entire page.

The thing that surprised me: font loading mattered more than I expected

Early versions had a visible layout shift from web font loading. Switching to font-display: swap and self-hosting the fonts (rather than a third-party font CDN round-trip) fixed most of the perceived jank — this had a bigger visible impact on "does this feel fast" than several JS optimizations combined.

What didn't help as much as I hoped: code-splitting the event-handling logic

I expected lazy-loading the keyboard event detection logic (ghosting/chatter/rollover) to meaningfully cut initial bundle size. In practice, it's small enough that the added complexity of a dynamic import wasn't worth the marginal savings — sometimes the "obviously correct" optimization isn't worth the engineering overhead for the actual bytes saved. Worth measuring before assuming.

Debounced rendering for the visual key-state UI

Every keydown/keyup was originally triggering a full re-render of the on-screen keyboard. Batching state updates and only re-rendering the specific key components that changed (rather than the whole keyboard grid) made multi-key stress-testing noticeably smoother, especially on lower-end devices.

I Built a Browser-Based Keyboard Tester: What I Learned About Keyboard Events

Chandra Sekhar Dey — Thu, 20 Aug 2026 03:56:10 +0000

I Built a Browser-Based Keyboard Tester: What I Learned About Keyboard Events

A keyboard seems simple until you try to build something that needs to detect every key a user presses.

I recently built keyboardtest, a browser-based keyboard testing tool. The idea is simple: press a key, and immediately see whether the browser receives the keyboard event.

But building something this simple taught me a few interesting things about browser keyboard input.

The basic idea

Browsers provide keyboard events that allow JavaScript applications to react when users press and release keys.

For a simple keyboard tester, the basic flow is:

Listen for a keyboard event.
Identify the key that was pressed.
Update the corresponding key on the virtual keyboard.
Keep track of keys that are currently pressed.
Reset the visual state when the key is released.

The result is a virtual keyboard that reacts in real time.

Why testing every key is useful

A keyboard tester can be useful when:

A key appears to be broken
You're checking a new keyboard
You're buying a used laptop
You're troubleshooting a mechanical keyboard
You want to check a gaming keyboard
Several keys behave unexpectedly

Instead of guessing whether a keyboard is working, you can visually check which keys are being registered.

Some interesting edge cases

Keyboard input isn't always as straightforward as it looks.

Modifier keys such as Shift, Ctrl, Alt, and Meta need special handling because they can be held while other keys are pressed.

There are also differences between physical keyboard layouts and the values reported by the browser. A useful keyboard tester therefore needs to think carefully about how it represents keys rather than assuming every keyboard has exactly the same layout.

Another interesting area is simultaneous key presses. This is particularly important for gaming keyboards, where users may press several keys at once.

Building the project

The main goal of keyboardtest was to keep the experience simple:

Open the website
Start pressing keys
See the result immediately

There is no desktop application to install and no complicated configuration.

You can try it here:

https://keyboardtest.tech

I'm continuing to improve the project and I'm particularly interested in browser compatibility, keyboard layouts, accessibility, and better ways to diagnose keyboard problems.

What I learned

The biggest lesson was that even a small browser utility can have surprisingly interesting technical details behind it.

Keyboard events are easy to demonstrate, but building a useful tool around them means thinking about different operating systems, layouts, modifier keys, simultaneous input, and user experience.

If you've built anything involving browser keyboard events, I'd be interested to hear about the edge cases you've encountered.

What keyboard-related browser feature would you add to a testing tool?

Building a Browser-Based Keyboard Tester: Ghosting, NKRO, and the Quirks of the KeyboardEvent API

Chandra Sekhar Dey — Mon, 03 Aug 2026 17:47:02 +0000

I built KeyboardTest.tech — a free, no-install keyboard diagnostic tool that runs entirely in the browser. Here's what I learned wrestling with the KeyboardEvent API to detect stuck keys, ghosting, and rollover limits client-side, with zero server logging.
The core problem: the browser doesn't tell you what you think it does

keydown and keyup seem simple until you try to build something like an NKRO (N-Key Rollover) checker. A few gotchas that cost me real debugging time:

event.code vs event.key — key gives you the character produced (locale + modifier-dependent), code gives you the physical key position (layout-independent). For a hardware tester, you almost always want code. Using key will silently break for non-QWERTY layouts.
The OS eats some combos before JS ever sees them. Certain OS-level shortcuts (screenshot combos, some Meta/Cmd chords) never reach the page. You can't "test" what the browser never receives — worth being upfront about this as a limitation rather than pretending full hardware-level access.
Ghosting isn't a JS bug, it's a hardware/matrix limitation. Cheap keyboards use a key matrix that can only resolve certain simultaneous key combinations. When you hold enough keys at once, the matrix can't disambiguate and either drops a keypress or reports a "phantom" one. From the browser, this shows up as a keydown that never fires (not a keyup that fires incorrectly) — which means your ghosting detector is really just: track expected keys pressed vs. actual keydown events received, then diff.
Detecting rollover without native access

There's no navigator.keyboard.getRollover() — so an NKRO tester really just:

Listens for every keydown and adds event.code to a Set.
Listens for keyup and removes it.
Tracks the maximum size the Set ever reached during a session.

That max size is your empirical rollover ceiling. It's not perfect (you're bounded by however many keys the user's fingers can physically hold down during testing), but for practical "is this a 6KRO or NKRO keyboard" purposes, it works well — most users can get 8-10+ keys down at once if they try.

Chatter/double-typing detection

Switch chatter (one physical press registering as two) shows up as two keydown events for the same code within an implausibly short window with no keyup in between. A naive Date.now() timestamp diff on consecutive keydowns for the same code, with a threshold tuned against real bouncy-switch recordings, catches the overwhelming majority of cases without false-positiving on fast intentional double-taps (those have a keyup between them).

Zero-logging by design

Everything above runs entirely client-side — no keystroke data is ever sent to a server. For a tool whose entire premise is "let me mash random keys to test my hardware," that's a privacy requirement, not just a nice-to-have. If you're building anything similar, it's worth architecting for this from the start rather than bolting on privacy later — it also simplifies GDPR/CCPA compliance considerably since there's no keystroke data to protect in the first place.

Stack notes

Built with Next.js (App Router) + TypeScript + Tailwind. Static generation for the tool pages themselves (no server round-trip needed since all the diagnostic logic is client-side JS), with MDX for the blog/guide content.

I Built a Free Browser-Based Keyboard Testing Tool with Next.js

Chandra Sekhar Dey — Thu, 23 Jul 2026 15:54:55 +0000

As developers, we often need to verify whether a keyboard is working correctly. Maybe a key has stopped responding, a mechanical switch is chattering, or you're trying to test anti-ghosting before gaming.

Most existing tools either require downloading software, contain intrusive ads, or don't provide enough information for debugging.

So I decided to build KeyboardTester.

👉 https://keyboardtest.tech

Why I Built It

The goal was simple:

No installation
No account required
Works instantly in any modern browser
Privacy-friendly (everything happens in the browser)

Whether you're a developer, gamer, IT technician, or just troubleshooting a laptop keyboard, you should be able to test every key within seconds.

Tech Stack

The project is built using:

Next.js 16 (App Router)
React 19
TypeScript
Tailwind CSS
Shadcn UI / Radix UI
Static deployment through Cloudflare CDN

The application is designed to be lightweight, responsive, and accessible.

Features

Current features include:

🎹 Interactive keyboard tester
⌨️ Real-time key highlighting
👻 Ghosting and N-Key Rollover (NKRO) testing
⚡ Multiple simultaneous key detection
📊 Key event inspector (key, code, keyCode)
⏱️ Typing speed (WPM) test
🖱️ CPS (Clicks Per Second) tester
🍎 macOS keyboard layout support
🪟 Windows and laptop keyboard layouts
Challenges

One interesting challenge was handling browser keyboard events consistently.

Different operating systems and browsers can report keys differently, especially modifier keys like:

Command (⌘)
Option (⌥)
Alt
Fn
Windows key

Making the tester behave consistently required careful handling of keyboard events across platforms.

Performance

One thing I wanted to prioritize was speed.

The site loads quickly because it's statically generated and served through a global CDN. Since processing happens locally in the browser, there are no server round trips while testing your keyboard.

What's Next?

I'm planning to add:

More international keyboard layouts
Better accessibility improvements
Additional hardware diagnostics
More typing analytics
New testing utilities
I'd Love Your Feedback

If you enjoy building developer tools or have ideas for keyboard diagnostics, I'd appreciate your feedback.

You can try it here:

https://keyboardtest.tech