German text breaks software in predictable ways. A user named "Müller" becomes "Müller" in your database, your slug generator turns "Größe" into "gr-e", and string comparison says "ä" and "a" are different characters (they are) while your German users insist "ß" and "ss" should sometimes match (they should). This is the practical reference for the seven German special characters: ä ö ü Ä Ö Ü ß.

The characters and their code points

There are exactly seven: three lowercase umlauts, three uppercase umlauts, and the Eszett (ß, "scharfes S"). Every one of them lives in the Latin-1 Supplement block, which is why they survived the ASCII era better than most accented characters:

Numeric character references work too: ä for ä, ß for ß. In modern UTF-8 HTML you can usually type the characters directly, but entities are still the safe choice inside attributes, email templates, and anywhere an encoding might get mangled in transit.

Typing them while you code

You will need these constantly in string literals and test data. The fastest methods per OS:

• Mac: Option + U, release, then the vowel (ä ö ü; add Shift for Ä Ö Ü). Option + S for ß.
• Windows: Alt codes on the numpad — Alt+0228 (ä), Alt+0246 (ö), Alt+0252 (ü), Alt+0223 (ß). Or add the US-International layout.
• Linux: Compose key, then " + vowel; Compose + s + s for ß.

Normalization: the bug you will definitely hit

Unicode lets you represent ä two ways: the precomposed character U+00E4, or the letter "a" followed by a combining diaeresis (U+0061 U+0308). They render identically but === says they are different. If your app compares, deduplicates, or hashes German strings, normalize first:

import unicodedata
unicodedata.normalize("NFC", user_input)  # compose to canonical form

str.normalize("NFC")

NFC (Canonical Composition) is the right default for storage and comparison. NFD (decomposed) is useful when you need to strip diacritics: decompose, then drop the combining marks.

Case folding and the ß problem

German's Eszett has no uppercase form in traditional orthography (the capital ẞ, U+1E9E, was only officially added in 2017 and is still rare). "ß".toUpperCase() in JavaScript gives "SS", which is linguistically correct — but it means uppercasing is not reversible, and naive case-insensitive comparison breaks:

// Wrong: "straße" vs "STRASSE" won't match with toLowerCase alone
"straße".toLowerCase() === "strasse".toLowerCase()  // false

// Right: case folding handles ß -> ss
"straße".toUpperCase() === "STRASSE"  // true

For search and deduplication, fold to a canonical case with toUpperCase() (or Python's casefold(), which is designed exactly for this) before comparing.

Sorting German strings

Default code-point sorting puts ä after z, which looks wrong to German users. In German phonebook collation, ä sorts with a, ö with o, ü with u, and ß with ss. Use locale-aware comparison:

["Öl", "Apfel", "Äpfel"].sort((a, b) => a.localeCompare(b, "de"))
// Apfel, Äpfel, Öl

Python's locale.strxfrm with a German locale does the same. If you are on a database, set the column collation to a German locale (de-DE-x-icu in Postgres) rather than sorting in application code.

Slugs and URLs

German convention transliterates for ASCII-only contexts: ä→ae, ö→oe, ü→ue, ß→ss. "Müller" becomes "mueller", "Straße" becomes "strasse". This is not just tradition — it is what German users expect to type:

const slug = name
  .toLowerCase()
  .replace(/ä/g, "ae").replace(/ö/g, "oe")
  .replace(/ü/g, "ue").replace(/ß/g, "ss")
  .replace(/[^a-z0-9]+/g, "-");

Do the transliteration before stripping non-ASCII characters, or the umlauts vanish entirely.

LaTeX

In LaTeX documents, \"a, \"o, \"u produce ä, ö, ü, and \ss{} gives ß. With modern engines (XeLaTeX, LuaLaTeX) and UTF-8 source files, you can type the characters directly.

Troubleshooting: mojibake

"Müller" shows as "Müller". Classic UTF-8 bytes read as Latin-1. ü is C3 BC in UTF-8; read those two bytes as Latin-1 and you get à (C3) + ¼ (BC). Fix the decoding, not the data — the bytes are almost always correct.

"Größe" or question marks. Same family of bug: a Latin-1/Windows-1252 layer somewhere in the pipeline. Check, in order: the HTML <meta charset>, the HTTP Content-Type header, the database connection charset, and the file encoding your editor saved with.

Length and slicing surprises. In UTF-8, each umlaut is 2 bytes but 1 character. Byte-slicing a string can split a character mid-sequence. Slice by characters (Python 3 strings, JS spread [...str]), never by raw bytes, and be careful with substr on emoji-adjacent content.

Regex character classes. [a-z] does not match ä. Use Unicode property escapes: /\p{L}/u matches any letter including umlauts.

The lazy option

When you just need the character itself — for a test fixture, a string literal, a commit message — a click-to-copy page is faster than any shortcut. I keep Umlaut Letters bookmarked: all seven characters on one page, click to copy, with the code points and entities listed beside them.

Handle encoding at the boundary (normalize on input, UTF-8 everywhere, locale-aware collation) and German text stops being a bug factory.