Keyboard Layout Translator
Fix keyboard-layout mismatches between local keyboards and remote consoles. Convert AZERTY, QWERTZ, and QWERTY text instantly in your browser.
I'm Typing mode: You are physically typing on your local keyboard layout, but the remote console expects a different layout. This shows what the remote side will actually receive.
Quick presets
How this works
- Your local keyboard layout and the remote console layout do not match.
- This tool translates based on physical key positions, not language meaning.
- This is most common in VM consoles, VNC/noVNC, KVM, installers, and password prompts.
- Ordinary SSH sessions usually send characters rather than raw key positions, so layout mismatches are less common there.
- Shift-modified symbols (like @, #, !, and /) are handled based on the actual key position and modifier state.
This tool runs entirely in your browser. All keyboard layout translation happens client-side using a local key-position model. Nothing you type is stored or sent to any server.
Overview
Remote consoles, VM terminals, VNC/noVNC sessions, and KVM-over-IP devices often interpret keyboard input based on a default layout that does not match the physical keyboard in front of you. When your local keyboard is set to French AZERTY but the remote machine expects US QWERTY, pressing the A key sends an Q to the remote side. Symbols are even worse: @, #, /, and ! land on completely different physical keys across AZERTY, QWERTZ, and QWERTY variants.
This is different from a normal typing mistake. The keystrokes are correct for your local layout, but the remote system interprets the raw key positions using a different mapping. The result is predictable garbled text, not random errors. That predictability is what makes translation possible: given two layouts, you can deterministically map what one keyboard sends to what the other layout interprets.
The pain is sharpest with passwords, shell commands, and installer prompts. Passwords are not echoed, so you cannot see the mismatch happening. Shell commands with symbols (pipes, paths, redirects, options) break in confusing ways. And installer screens often lock you into a console with no easy way to change the keymap before entering critical configuration.
What this tool helps with
Good fit for
- Rescuing garbled commands from remote console mismatchespaste the garbled output and recover the likely original text so you can re-enter it correctly.
- Predicting what a remote VM console will receivetype the command locally and see exactly what the remote side will interpret before you enter it blindly.
- Recovering mistyped passwords in non-echoing contextsif a password was entered under the wrong layout, translate it to understand what was actually sent.
- Translating between common European keyboard layoutsconvert between French AZERTY, German QWERTZ, UK QWERTY, and US QWERTY with full symbol support.
- Debugging VNC/noVNC and KVM-over-IP keyboard problemsunderstand why specific symbols are wrong and which keys to press to get the intended character.
- Checking what a remote machine actually receivedverify the exact characters that were sent before blaming authentication, shell, or application bugs.
Not the right tool for
- Treating this as a universal SSH fixordinary SSH sessions usually send characters, not raw key positions. Layout mismatches are more common in VM consoles, VNC, and KVM sessions than in standard SSH shells.
- Confusing keyboard layout with character encodingif you see mojibake (garbled Unicode), the problem is encoding (UTF-8, Latin-1, etc.), not keyboard layout. This tool fixes layout mismatches, not encoding issues.
- Assuming all QWERTY layouts are the sameUS and UK QWERTY differ in symbol positions. @ is on Digit2 in US but on Quote in UK. # and ~ are on different keys. This tool treats them as separate layouts.
- Fixing the browser-side symptom instead of the serverif you can change the keyboard layout on the remote machine, that is the better long-term fix. This tool is for when you cannot or need an immediate rescue.
How to use it
- 1
Choose your mode
Select 'I'm Typing' to predict what a remote console will receive, or 'Rescue' to recover garbled text from a mismatch that already happened.
- 2
Select your physical keyboard layout
Choose the layout your local keyboard uses. If you are in France, this is likely French AZERTY. If in Germany, German QWERTZ.
- 3
Select the remote/target layout
Choose the layout the remote system expects. VM consoles and installers often default to US QWERTY.
- 4
Type or paste the text
Enter the command, password, or text. The translation updates instantly as you type. No submit button needed.
- 5
Copy the translated result
Use the copy button to grab the corrected output and paste it into the remote console, terminal, or application.
- 6
Optionally fix the root cause on the remote machine
On Linux consoles, use loadkeys us (or your layout) for immediate effect. For persistent changes on Debian/Ubuntu, use dpkg-reconfigure keyboard-configuration.
Common issues and fixes
Assuming the problem is SSH
Standard SSH sessions transmit characters, not raw keycodes. Layout mismatch pain is strongest in VNC/noVNC, VM consoles (Proxmox, VMware, Hyper-V), KVM-over-IP, Linux TTY consoles, and installer screens. If you are in a normal SSH shell and characters are wrong, check your local terminal emulator's keyboard settings first.
Confusing layout with encoding
If you see garbled Unicode (e.g. é, ä, or replacement characters), the problem is character encoding, not keyboard layout. Check locale settings (locale, LANG, LC_ALL) and terminal encoding (UTF-8 vs Latin-1) instead.
Using the wrong QWERTY variant
US and UK QWERTY are not the same layout. Key differences: @ is Shift+2 in US but Shift+Quote in UK. # is Shift+3 in US but on the Backslash key in UK. " is Shift+Quote in US but Shift+2 in UK. Always select the correct variant.
Forgetting Shift-sensitive symbol changes
Letters may look close between layouts, but symbols break badly. On French AZERTY, numbers require Shift. On German QWERTZ, / is Shift+7. The tool handles modifier-aware conversion, but you need to select the correct source and target layouts.
Dead keys causing unexpected behavior
French AZERTY and German QWERTZ use dead keys for accents (^, `, ¨). A dead key press followed by a letter produces an accented character. This tool maps the dead key character itself but cannot fully simulate dead-key composition. If accented characters are garbled, the dead key interaction is likely the cause.
Trying to fix the browser when the fix belongs on the server
If you have persistent access, change the keyboard layout on the remote machine instead of translating forever. On Linux: loadkeys for console, setxkbmap for X, or dpkg-reconfigure keyboard-configuration for permanent Debian/Ubuntu changes.
Frequently asked questions
Related
Why does my remote terminal or console type different characters than my keyboard?
When you connect to a remote machine through a VM console, VNC/noVNC session, KVM-over-IP device, or Linux TTY, the remote system interprets your keystrokes using its own keyboard layout setting. If your local keyboard is set to French AZERTY but the remote console expects US QWERTY, the same physical key press produces a different character on the remote side. You press A and the remote gets Q. You press ; and the remote gets M.
This happens because the remote system receives raw key position data (scancodes) from these console types, not pre-translated characters. It then applies its own layout interpretation to those positions. If that interpretation does not match your physical keyboard, every keystroke gets remapped.
Is this an SSH problem or a remote console problem?
This distinction matters. Standard SSH connections transmit characters that your local terminal emulator has already processed using your local keyboard layout. By the time the remote shell receives the input, it is already the correct character. This means layout mismatches in ordinary SSH are rare.
The problem is much more common in:
- VM consoles — Proxmox, VMware vSphere, Hyper-V, cloud provider web consoles
- VNC / noVNC — graphical remote desktop sessions that transmit key events
- KVM-over-IP — hardware console access that sends raw keyboard scancodes
- Linux TTY consoles — direct terminal login where loadkeys determines the keymap
- Installer screens — OS installers that default to US QWERTY before configuration
- Password prompts — non-echoing prompts where you cannot see the mismatch happening
If you are in a normal SSH shell and characters are wrong, the issue is more likely your terminal emulator's input settings, locale, or character encoding rather than a keyboard layout problem.
AZERTY vs QWERTY vs QWERTZ
These three layout families are named after the first six letter keys on the top row. Each is the default in different regions, and each places letters and symbols on different physical key positions.
| Layout | Common regions | Key differences from US |
|---|---|---|
| US QWERTY | United States, many defaults | Baseline layout for most remote consoles and VMs. |
| UK QWERTY | United Kingdom, Ireland | @ on Shift+Quote (not Shift+2). # on Backslash key. " on Shift+2. Extra IntlBackslash key. |
| French AZERTY | France | A/Q and Z/W swapped. Numbers require Shift. M on Semicolon key. Punctuation heavily rearranged. |
| Belgian AZERTY | Belgium | Similar to French but different symbol positions. ! on Digit8 (not Shift+1). |
| German QWERTZ | Germany, Austria | Y/Z swapped. Numbers same but Shift-symbols differ (/ on Shift+7). ß, ü, ö, ä on dedicated keys. |
| Swiss German | Switzerland | QWERTZ variant. Different symbol positions from German DE. ' on Minus key. |
The A/Q and Z/W swaps between AZERTY and QWERTY are the most visible letter-level change. The Y/Z swap in QWERTZ is the most visible between German and US layouts. But symbols often break even when letters seem mostly readable, because symbol keys are rearranged far more aggressively than letter keys across layout families.
Common layout mismatch cheat sheet
When a user on one layout types into a remote console expecting another, these are common character transformations. This is not exhaustive but covers the most frequent surprises.
French AZERTY local → US QWERTY remote
| You press | Remote receives | Why |
|---|---|---|
| a | q | A and Q are swapped between AZERTY and QWERTY |
| z | w | Z and W are swapped |
| m | ; | M is on the Semicolon key position in AZERTY |
| , | m | Comma is on the M key position |
| ! | / | ! (Slash key in AZERTY) maps to / in US |
German QWERTZ local → US QWERTY remote
| You press | Remote receives | Why |
|---|---|---|
| z | y | Y and Z are swapped between QWERTZ and QWERTY |
| y | z | Same swap, opposite direction |
| ö | ; | ö occupies the Semicolon key position |
| ä | ' | ä occupies the Quote key position |
| Shift+7 (/) | & | / is Shift+7 in QWERTZ but & is Shift+7 in US |
UK QWERTY local → US QWERTY remote
| You press | Remote receives | Why |
|---|---|---|
| Shift+' (@) | " | @ is Shift+Quote in UK but Shift+Quote is " in US |
| Shift+2 (") | @ | " is Shift+2 in UK but @ is Shift+2 in US |
| # (Backslash) | \ | # is on the Backslash key in UK layout |
| ~ (Shift+Backslash) | | | ~ is Shift+Backslash in UK, which is | in US |
How to fix the layout on Linux instead of translating forever
If you have persistent access to the remote machine, changing the keyboard layout on the server side is the proper long-term fix. The method depends on the environment.
Linux console / TTY
loadkeys us
Changes the console keymap immediately for the current session. Replace 'us' with your layout code (fr, de, uk, etc.). Available keymaps are usually in /usr/share/keymaps/ or /lib/kbd/keymaps/.
Debian / Ubuntu persistent
sudo dpkg-reconfigure keyboard-configuration
Interactive reconfiguration that persists across reboots. Sets both console and X keyboard model, layout, variant, and options. Requires root access.
systemd-based systems
sudo localectl set-keymap us
Sets both the console keymap and X11 layout on systemd-managed distributions. Use localectl list-keymaps to see available options.
X / GUI sessions
setxkbmap us
Changes the X11 keyboard layout for the current user session. Does not affect Linux console TTYs. For persistent X changes, edit /etc/X11/xorg.conf.d/ or use desktop environment settings.
VM hypervisor settings
Some hypervisors (Proxmox, VMware, Hyper-V) allow you to configure the keyboard language for the console session. Check the hypervisor documentation for console keyboard settings.
Note that GUI/X settings and console/TTY settings are independent on Linux. Changing one does not automatically change the other. Remote console sessions through VNC or KVM may have their own keyboard configuration layer that overrides both.