Remove accents and diacritics from text - including Polish letters

Polish uses nine letters with diacritics. Their standard ASCII replacements are the ones Polish banks, email providers and government systems use:

So “Łódź” becomes “Lodz”, “Wałęsa” becomes “Walesa” and “Kraków” becomes “Krakow”. The letter ł is the classic trap: it is not an “l” with an accent mark in Unicode but a separate letter, so the usual programming trick of Unicode normalisation leaves it untouched and “Łódź” comes out as “Łodz”. This tool maps it explicitly.

With “Remove all accents” on, letters are decomposed into a base letter plus combining marks (Unicode NFD normalisation) and the marks are dropped: é → e, ñ → n, ü → u, č → c, å → a. Letters that have no decomposition are replaced from a table: ß → ss, æ → ae, œ → oe, ø → o, đ → d, ð → d, þ → th, ı → i.

Example: “Müller, Straße, Øresund, Čapek, Crème brûlée” → “Muller, Strasse, Oresund, Capek, Creme brulee”. Upper and lower case are preserved, and digits, spaces, punctuation and line breaks are left exactly as they were. Non-Latin scripts such as Greek, Cyrillic or Chinese are not transliterated - only Latin letters with diacritics are simplified.

Note that this is a technical simplification, not a spelling convention. German readers often prefer “ü” written as “ue” (Müller → Mueller) in names, and some passports follow ICAO rules that differ from simple accent stripping.

• File and folder names - avoid garbled names after uploading to a server, sending through old email clients or unpacking a ZIP on another system.
• Usernames, logins and email addresses - many systems accept only ASCII. For page addresses use the slug generator, which also handles spaces and punctuation.
• SMS messages - a single accented letter outside the GSM-7 alphabet (such as ł, ś or č) switches the message to UCS-2 and cuts the limit from 160 to 70 characters, so a 120-character text costs two messages instead of one.
• Data imports and matching - removing accents before comparing names helps find duplicates such as “Jose” and “José” in a CRM or spreadsheet.
• Legacy systems and payment titles - older banking and accounting software may reject or mangle non-ASCII characters in transfer descriptions.