German uses three umlauted vowels — ä, ö, ü — and the sharp-s ß, none of which exist in plain ASCII. When text must pass through a system that only understands the basic Latin alphabet, these characters are replaced by digraphs: ae, oe, ue and ss. This tool converts in both directions, with case-aware handling for the capital forms.
The substitution rules
| German character | ASCII digraph | Upper (title case) | Upper (all-caps) |
|---|---|---|---|
| ä | ae | — | — |
| Ä | Ae | Ae | AE |
| ö | oe | — | — |
| Ö | Oe | Oe | OE |
| ü | ue | — | — |
| Ü | Ue | Ue | UE |
| ß | ss | — | — |
| ẞ | SS | SS | SS |
How it works
Converting umlaut to ASCII is a straightforward one-to-one substitution: ä → ae, ö → oe, ü → ue, ß → ss. The only subtlety is case. A capital umlaut becomes title case when followed by a lowercase letter (Ä → Ae) but an uppercase pair when it sits in an all-caps run (Ä → AE), so Übung becomes Uebung and ÜBUNG becomes UEBUNG.
Converting ASCII back to umlauts reverses the mapping, but it is fundamentally ambiguous. The sequences ae, oe, ue and ss occur in plenty of words that have no umlaut at all — think Aerosol, Koexistenz, Etui or Wasser. The tool replaces every match, so you should always proofread the output and undo any incorrect substitutions.
Where this transliteration is used in practice
Passports and identity documents: The machine-readable zone (MRZ) at the bottom of a passport uses the ICAO standard, which requires plain Latin characters. German umlauts in names are converted using this exact ae/oe/ue/ss substitution. This is why a passport holder named “Müller” appears as “MUELLER” in the MRZ.
Legacy systems and databases: Many older enterprise systems, mainframes, and data pipelines were designed for ASCII or ISO 8859-1 in limited configurations. Even today, some ERP, payroll, and HR systems store German names in the transliterated form.
Email addresses: RFC 5321 technically allows international characters in email addresses (SMTPUTF8), but many servers and clients only reliably handle ASCII local-parts. A user named mü[email protected] may be stored or delivered as [email protected] in systems that do not support SMTPUTF8.
DIN 5007-2 (phone-book sorting): The German standard for alphabetical sorting has two variants. DIN 5007-1 treats umlauts as separate letters placed after the base letter (so ä sorts near a). DIN 5007-2 — used in phone books and directories — treats each umlaut as its two-letter equivalent for sorting (ä sorts as ae), which means “Müller” is listed between “Muehler” and “Muenster”. This tool’s output is suitable for producing sort keys under DIN 5007-2.
Internationalised domain names (IDN): German domain names like münchen.de use Punycode (xn--mnchen-3ya.de) at the DNS level, but the display form with umlauts is the user-facing representation. For older systems that cannot handle Punycode, the ae/oe/ue substitution is sometimes used informally, though this creates a different domain name entirely.
When to use umlaut→ASCII vs. ASCII→umlaut
Umlaut to ASCII is lossless and deterministic — every German text has exactly one correct transliterated form. Use this direction when:
- Preparing text for a system that only accepts ASCII.
- Generating sort keys for DIN 5007-2 ordering.
- Creating email local-parts for legacy servers.
- Exporting to formats that cannot carry UTF-8 safely.
ASCII to umlaut is a best-effort reversal that requires human review. Use it when:
- You received text that was transliterated and want to restore the original German.
- You are cleaning up imported data where umlauts were stripped.
Always proofread ASCII-to-umlaut output: “aerosol” should not become “ärosol”, and “Wasser” should not become “Waßer”.