AZERTY ↔ QWERTY converter
Fix text typed on the wrong keyboard layout by remapping each key between French AZERTY and US QWERTY: the six keys that read azerty on a French keyboard give qwerty on a US one. It works both ways, without retyping. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- azerty
- Direction
- Azerty to qwerty
- Result
- qwerty
- Layout from
- azerty
- Layout to
- qwerty
- Length
- 6
When you type with the wrong keyboard layout selected, every keystroke lands on a different character than the one you meant. A password typed on French AZERTY while the system expects US QWERTY becomes gibberish; a chat message drafted on a borrowed laptop can look like a cipher. This AZERTY QWERTY converter remaps each character by physical key position between the French AZERTY layout and the US QWERTY layout, in either direction, so you can recover the intended text without retyping.
How AZERTY and QWERTY differ by key position
French AZERTY and US QWERTY place different glyphs on many of the same physical keys. On AZERTY the top letter row begins with A Z E R T Y, while on QWERTY those same columns begin with Q W E R T Y. The home row swaps Q and A, puts M where the semicolon sits on QWERTY, and uses ù and other French symbols where English keyboards put apostrophe and related punctuation.
Digits on a classic French AZERTY layout often require the Shift key and live on the same physical keys that produce ampersand, e-acute, quotes, and other symbols when unshifted. This converter does not rotate the alphabet like a Caesar cipher and does not implement a keyboard-shift puzzle; it builds a fixed bidirectional table of physical key pairs and substitutes each input character with the glyph that shares that key on the target layout.
Letters that occupy the same column on both layouts, such as E R T Y U I O P and many home-row letters, stay the same.
Where layout remapping shows up in real work
Travelers and bilingual offices constantly switch between French AZERTY machines and US or UK QWERTY laptops; a single trusted remap oracle fixes the classic “I typed my passphrase on the wrong layout” ticket without forcing a reset. Customer support teams paste garbled login attempts into a browser tool and recover the intended password characters when the only mistake was layout, not the secret itself. Localization QA and keyboard-layout documentation authors generate examples that show how the same finger positions produce different strings on AZERTY versus QWERTY.
Classroom demos of input methods can contrast this physical-key remap with alphabet ciphers and with adjacent-key keyboard-shift puzzles so students see three different ideas clearly. If you need a QWERTY adjacent-key cipher, classical Caesar rotation, Base64, or full Unicode transliteration, treat those as separate search intents and landings rather than overloading this AZERTY QWERTY converter page.
What you can do with it
Recover mistyped passwords
Remap a passphrase typed on AZERTY while the account expected QWERTY (or the reverse) without forcing a full password reset.
Support and bilingual desks
Paste garbled chat or form input from a wrong OS keyboard layout and restore readable French or English text by key position.
Layout QA and teaching demos
Generate stable AZERTY versus QWERTY examples for docs, localization tests, and classroom comparisons with other ciphers.
FAQ
What does this AZERTY QWERTY converter do?
It remaps each character by physical key position between French AZERTY and US QWERTY, in either direction, and reports glyphs that have no layout pair.
What happens to unmapped characters?
Whitespace is preserved and never counted as unmapped.
Is this the same as a keyboard-shift cipher?
No. A keyboard-shift cipher slides letters to neighboring QWERTY keys for puzzles. This tool remaps whole layouts AZERTY ↔ QWERTY by the same physical key.
What does it cost?
The browser tool is free and runs locally.
Which direction should I choose?
Pick AZERTY to QWERTY when the garbled text came from fingers or a machine set to French AZERTY; it rewrites each character as the US glyph on the same key. Choose the reverse when the text was typed on QWERTY but meant for AZERTY.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/enc/azerty-qwerty \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"azerty"}'const res = await fetch("https://api.kit.forhosting.com/enc/azerty-qwerty", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "azerty"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/azerty-qwerty",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "azerty"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/azerty-qwerty", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"azerty"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"azerty"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/azerty-qwerty", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "azerty"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.azerty_qwerty",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Whitespace is preserved, case-aware letter pairs stay consistent with the layout tables, and any glyph that has no counterpart on the other layout is left unchanged and listed in the unmapped_keys field.
How AZERTY and QWERTY differ by key position
Direction azerty_to_qwerty assumes the text you see was produced under AZERTY (or under muscle memory for AZERTY) and rewrites it as the QWERTY glyphs for those same keys. Direction qwerty_to_azerty does the reverse. Because the map is pure table lookup with no network and no randomness, identical text and direction always yield identical JSON. Characters outside the tables—emoji, CJK ideographs, rare symbols—pass through unchanged and appear once each in unmapped_keys so you can see what the engine could not remap.
Input contract, response fields, and validation
Spaces, tabs, and newlines are always preserved and never counted as unmapped. Send a required string field named text and an optional direction field whose enum is azerty_to_qwerty or qwerty_to_azerty. When direction is omitted, azerty_to_qwerty is the default so a minimal payload still performs the most common recovery path for French-layout mistypes. On success the response echoes direction, layout_from, layout_to, and the original text; it returns result as the remapped string, length of that result, mapped_count as how many characters were substituted from the table, unmapped_count as how many non-whitespace characters had no pair, and unmapped_keys as a unique list of those glyphs in first-seen order. Missing text, non-string objects for text, unsupported direction values, and strings longer than the documented maximum fail with invalid_input and a clear English message; those validation failures do not consume prepaid balance. Classic checks include converting the AZERTY word azerty to qwerty, converting qwerty back to azerty in the opposite direction, and confirming that a string with CJK characters still returns success while listing those characters under unmapped_keys. Pricing for successful API calls is the published base of $0.002 per item.
Where layout remapping shows up in real work
Because this capability is a pure parse engine, API pricing is the published base of $0.002 per successful item and failed validation does not consume balance.
Technical questions
Which direction should I choose?
Use azerty_to_qwerty when the visible text was produced under AZERTY and you want QWERTY glyphs; use qwerty_to_azerty for the reverse. Default is azerty_to_qwerty.