Wrong characters in a remote session: keyboard layouts explained

You press a key and a different character appears. Nothing is broken — two machines are disagreeing about what your keyboard is, and there are only three ways that disagreement can happen.

The disagreement

A keyboard does not send letters. It sends scancodes — a number identifying a physical key position. The operating system then applies a layout to decide that position number 44 means z on a US layout, y on a German one, and z again on Turkish Q.

In a remote session there are two operating systems and therefore potentially two layouts. If the tool forwards scancodes, the host layout decides the character. If it forwards characters, your local layout decides. Neither approach is wrong, but they fail in opposite ways, and knowing which one your tool uses tells you immediately what to fix.

Turkish keyboards, specifically

Turkish is where this shows up most, for three reasons that compound.

• Two national layouts. Turkish Q and Turkish F place letters completely differently, and F is not a variant of Q — it is a different design. A host set to Q with an F keyboard in front of you is unusable, and vice versa.
• Letters that do not exist in ASCII. ç ğ ı İ ö ş ü live in different places on each layout, and a US-configured host has no key positions for them at all. On a US host the letters simply cannot be produced by any key you press.
• The dotted and dotless i. Turkish distinguishes i/İ from ı/I, and case conversion follows different rules. Software that assumes English casing can turn one into the other, which is bewildering when it happens inside a remote session where you are already suspecting the keyboard.

AltGr and dead keys

AltGr is not a modifier of its own on Windows — it is reported as Ctrl and Alt pressed together. Remote tools that forward modifiers naively can turn an AltGr combination into a Ctrl+Alt shortcut on the host, so instead of typing @ or { you trigger something. If a symbol on the third level of your keyboard does nothing or does something alarming, this is why.

Dead keys — the ones that produce an accent only when combined with the next keystroke — need the two presses to arrive in order and be interpreted by the same layout engine. If the two halves are handled by different sides of the connection, you get the accent character on its own, or nothing, or both letters unaccented.

Fixing it

1. Set the host's layout to match your physical keyboard. The most reliable fix by a distance, and it is a one-time change. On Windows: Settings → Time & language → Language & region, add the layout, and make it the default so it survives a restart and applies at the login screen too.
2. Check the language indicator on the host, not on your machine. Windows switches layout per application and remembers it, so one window can be on a different layout from the rest and it will look like the connection is at fault.
3. Use the tool's text-input path for anything long. Some remote tools can send text as characters rather than key positions, which sidesteps layout entirely for typing. It is the right tool for a password or a paragraph and the wrong one for shortcuts.
4. Use the on-screen keyboard for one awkward character. Clumsy, but it is generated on the host with the host's layout and it always produces what it shows.
5. Check Caps Lock on both ends. Sounds trivial, and state can genuinely diverge between the two machines when a session drops mid-keypress.

The one that is not a layout problem

If every key is delayed rather than wrong, that is latency, not layout — the characters are correct but arrive late enough that you type ahead of the display. Different problem, different guide: why the remote cursor lags.

More guides