Accent folding normalises text so that searches match regardless of accents and special letters. It is the standard preprocessing step behind diacritic-insensitive search, where café and cafe are treated as identical.
How it works
Two stages produce a clean ASCII key:
1. Expand special letters and ligatures that have no combining mark:
ß → ss æ → ae œ → oe ø → o ð → d þ → th ł → l
2. Normalise to NFD and delete combining marks (U+0300–U+036F):
é → e ñ → n ü → u
(optionally) lowercase the whole stringDoing the ligature expansion before the NFD strip ensures characters that NFD cannot decompose still become plain ASCII. Apply the same pipeline to both your search index and the incoming query.
Worked examples
| Input | Folded output |
|---|---|
| Mötley Crüe — Straße | motley crue strasse |
| café au lait | cafe au lait |
| Zoë & Chloé | zoe & chloe |
| Łódź, Polska | lodz, polska |
| Þór Björnsson | thor bjornsson |
| São Paulo | sao paulo |
Where this matters in real projects
Name search. A user database containing “Ångström” will not match a search for “Angstrom” without folding. Apply the same normaliser at indexing time and at query time so both sides of the comparison are in the same form.
Address matching. Addresses imported from international sources often contain diacritics (Köln, Málaga, Łódź). Fuzzy address matching and deduplication pipelines routinely fold before comparing.
URL slugs. Before slugifying a title like “Über-cool résumé tips,” fold the accents first to get “uber-cool resume-tips” — clean, ASCII-safe URL path segments.
Database LIKE queries. Postgres and MySQL can be configured for case-insensitive collations, but accent-insensitive collations are less universal. Storing a pre-folded search column alongside the display column is a portable, engine-agnostic approach.
Log and metric aggregation. Event names, product names, or city names scraped from multiple sources arrive in inconsistent casing and accent forms. Folding before grouping collapses duplicates that would otherwise inflate your metric counts.
Common mistakes
- Folding only the stored value, not the query — if a user types “café” and you search a folded index of “cafe,” the comparison still fails. Always fold both sides.
- Using NFD strip alone without ligature expansion — pure NFD normalisation leaves ß as ß (it is not decomposable). The ligature expansion step must come first.
- Over-folding for display — fold only for search keys and comparison, never for the displayed result. Users expect to see “Müller” in results, not “muller.”