Keyboard Layout Test Guide

A reference for the DeskTest.net Keyboard Layout Test. It covers how the tool reads the active layout, how to read the verdict, and how to fix the US/UK/AZERTY/QWERTZ mismatch that makes a PC type the wrong character when the hardware and the OS input language disagree.

Open the Keyboard Layout Test →

What does the Keyboard Layout Test check?

It answers one question: which character does each physical key actually type? That is decided by the keyboard layout the operating system has selected, not by the hardware. A US ANSI keyboard whose Windows input language was set to UK will type a double-quote when you press the @ key. A German QWERTZ image running on US hardware swaps Y and Z. The keys are in the same place; the OS just assigns different characters to them.

The tool runs three steps in order:

1. Detection method available. It checks for navigator.keyboard.getLayoutMap(), a Chromium/Edge API that returns the character each physical key currently produces. If the browser has it (best on managed Windows), the layout is read directly with no typing. If not (Firefox and Safari do not implement it), the tool falls back to an interactive capture and this step still passes.
2. Active layout detected. It reads a set of signature keys - the ones whose character differs between layouts - and scores them against reference maps for US, UK, AZERTY, QWERTZ, and Dvorak to name the active layout. A table shows the code of each physical key (KeyQ, Digit2, Semicolon...) and the character it produces.
3. Matches the expected layout. It compares the produced characters against the layout you selected in the Expected layout dropdown (the layout printed on your hardware). If every signature key matches, it passes. If any differ, it fails and lists exactly which keys type the wrong character.

How this differs from the Keyboard Test

The two tools look similar but answer opposite questions, and you often want both.

If a user reports "my at-sign types a quote", that is a layout problem, not a hardware fault, and no amount of key-registration testing will find it. Conversely, if a key produces nothing at all, that is a hardware or driver problem for the Keyboard Test, not a layout one.

When should I run this?

• "My password stopped working" on an imaged fleet. The single most common cause on identically-imaged machines: one PC's input language drifted to a different layout, so every symbol in the password (@, #, /, \, ", the swapped Y/Z) is now different from what the user types elsewhere.
• Email addresses failing to send. The @ that types as " on a US-hardware/UK-software mismatch silently breaks every address the user enters.
• A new starter's laptop "types funny". A machine imaged from a regional gold image (French AZERTY, German QWERTZ) handed to someone with US hardware, or vice versa.
• Remote-desktop and VDI sessions. The layout can differ between the local client and the remote session; run this inside the session to see what the remote host thinks the layout is.
• Before rolling out a keyboard-driven line-of-business app. Confirm every workstation in a branch produces the same characters for the same keys.

Reading the results

Set Expected layout to the layout printed on the physical keyboard (US for most North American fleets), then Run. Each step shows a status badge: Pending (gray), Running (yellow), Pass (green), Partial (yellow), or Fail (red). The verdict panel at the top names the outcome and, on a mismatch, the likely cause and the recommended next step.

The layout table lists each signature key by its physical KeyboardEvent.code, the character it produces now, and the character your expected layout should produce. Rows where those differ are highlighted red. That is the concrete evidence: "the physical @ key (Digit2) produces a quote, but a US keyboard produces @".

Copy Diagnostic Report produces a plain-text report: the detection method, the detected layout, every produced character by key code, the mismatched keys, and the overall verdict. Paste it into a ticket, or use Send to your IT to open it in an email.

The signature keys, layout by layout

The tool does not need every key - just the ones that move between layouts. These are the tells it scores:

US and UK are the closest pair: their letters are identical, and the base layer differs only on the key above Enter (Backslash = \ on US, # on UK), plus the shifted @-vs-quote swap. That is why the tool reads the backslash key and, in interactive mode, Shift+2 - they are what separate a US image from a UK one. AZERTY and QWERTZ are unmistakable from the letter positions alone.

Fixing a layout mismatch

A mismatch is a software setting, not a broken keyboard. The fix is to make the OS input language match the hardware.

Windows

1. Open Settings, Time & language, Language & region.
2. Under the installed language, open the three-dot menu, then Language options. Under Keyboards, remove any layout that does not match the hardware, leaving only the correct one (for US hardware, US / United States-QWERTY).
3. If you cannot remove the extra one, at least make the correct layout the default. The taskbar language switcher (or Win+Space) cycles installed layouts; an accidental switch is a frequent cause. Sticky switching per app: Windows can remember a different layout per window.
4. For fleets, set the system-wide default under Administrative language settings, Copy settings, and apply to the welcome screen and new user accounts so freshly imaged or newly logged-in machines inherit the right layout.
5. Re-run this test to confirm every key now produces the expected character.

macOS

1. Open System Settings, Keyboard, then under Text Input click Edit next to Input Sources.
2. Add the input source that matches the physical keyboard (for US hardware, U.S. or ABC), and remove the mismatched one.
3. Untick Show Input menu in menu bar if accidental switching is the problem, or use it to confirm which source is active.
4. Re-run this test.

For IT admins

Where the layout comes from. On Windows the per-user input list lives under HKCU\Keyboard Layout\Preload and Substitutes; the default system layout is set at image time and in the language pack. A gold image built in one region and deployed in another is the classic source of a fleet-wide mismatch. Bake the correct default into the reference image and validate it post-deployment rather than trusting the installer default.

Provisioning and MDM. Intune and other MDM tools can push the input language and default keyboard layout; a policy that lists multiple layouts lets users drift. Pin a single layout for kiosk and shared-workstation profiles. For multi-region orgs, template the layout per site rather than shipping one global image.

Remote sessions. RDP and Citrix can either inherit the client layout or force the server's; a mismatch between the two produces a session that types differently from the local desktop. Run this test inside the session to see the effective layout there, and set the session policy explicitly instead of relying on inheritance.

Barcode and payment hardware. USB scanners and PIN pads that present as HID keyboards emit scancodes that the OS layout then maps to characters. A scanner tuned for a US host on a UK-layout PC will corrupt any SKU containing a remapped symbol. Keep the workstation layout and the scanner's keyboard-wedge profile on the same country.

Behind the scenes

The tool keys everything off KeyboardEvent.code, the physical key position, which never changes with layout: KeyQ is always the top-left letter key whether it prints Q, A, or an apostrophe. The character it produces is what layout decides, and that is exactly what we measure.

Automatic mode calls navigator.keyboard.getLayoutMap(), which resolves to a map from code to the base-layer character. We read the signature codes from it and score them against each reference layout, picking the closest match. Because the map is the unshifted layer, it reliably catches letter and symbol remaps but not shifted-only differences; the @-vs-quote consequence is derived from the named layout in this mode.

Interactive mode (Firefox, Safari, or when the map returns empty) attaches a capture-phase keydown listener and prompts you to press a short, fixed list of physical keys, described by their US position. For each, it reads event.code (to confirm you pressed the right physical key) and event.key (the produced character). One prompt is Shift+2, which measures the @-vs-quote result directly. Standalone modifier presses are ignored, and every captured key calls preventDefault() so nothing you press navigates or types into the page. The listener is removed when the step ends or on Reset, and nothing is retained after you leave.

Limits. This tool does not test key registration (use the Keyboard Test), does not resolve dead-key or compose sequences, and does not see AltGr third-level characters or per-application remappers that intercept keys after the browser. It recognizes US, UK, AZERTY, QWERTZ, and Dvorak; a regional variant or custom firmware map may read as "unrecognized", in which case the produced-character table is still accurate even though the tool cannot put a name to it.

Privacy. Everything runs in this browser tab. No keystroke is logged to a server, no telemetry is fired, and the report is assembled from in-memory state only when you click Copy or Send. Open DevTools, Network tab, and confirm: no outbound requests while the test runs.

Related

• Keyboard Layout Test - the diagnostic itself
• Keyboard Test - checks whether each physical key registers, finds stuck keys
• Keyboard Test Guide - the companion guide for physical-key faults
• DeskTest.net home
• About DeskTest.net