Remove Accents from Text
Strip accents and diacritics: á→a, ñ→n, ü→u.
Works on any language — your text never leaves this tabRemove accents and diacritics from text
About this accent remover
Removing accents means stripping the diacritical marks from letters — turning café into cafe, señor into senor, über into uber — while keeping the base letters and everything else intact. You want it for filenames, URL slugs, database keys, ASCII-only form fields, or matching text where records differ only by the accent. Paste any text below and get it back cleaned; the conversion runs in your browser via Unicode normalization, not a hand-written table, so Spanish, Portuguese, French, German, Czech, Polish and Vietnamese are all handled correctly.
Paste text and get it back without diacritical marks: café becomes cafe, señor becomes senor, über becomes uber. Handy for filenames, usernames, database keys, ASCII-only fields, and matching text where the accents vary between records. A toggle keeps the ñ intact for Spanish, where dropping it changes the word.
The conversion uses Unicode normalization rather than a hand-written lookup table, which is why it handles Spanish, Portuguese, French, German, Czech, Polish and Vietnamese without knowing anything about those languages. Everything runs in your browser: paste a customer list or an export from a production database and none of it leaves the page.
Here is the mechanism, because it explains both the strengths and the limits. Unicode can write é two ways: as the single precomposed code point U+00E9, or as the letter e followed by U+0301, the combining acute accent. The normalization forms defined in Unicode Annex #15 convert between them — NFC composes into single code points, NFD decomposes into base letter plus marks. This tool applies NFD and then deletes every character in the Combining Diacritical Marks block, U+0300 to U+036F. No table of letters is involved, which is also why stacked marks work: Vietnamese ế is e + circumflex + acute, three code points after NFD, and both marks fall inside the block, so a clean e comes out.
The honest caveat is the letters that are not a base plus a mark. ø, ł, đ, ß, æ, œ, þ, ð and Turkish dotless ı have no canonical decomposition in Unicode — they are distinct letters, not decorated ones — so NFD leaves them alone and this tool passes them through unchanged. Turning ß into ss or ø into o is transliteration, a per-language mapping, not accent stripping, and the right answer depends on context: German ö is o in one convention and oe in another. If you need those, map them yourself before or after running the text through here. One more subtlety: mixed-script input comes back in NFD form. Korean 한글 and Japanese が look identical afterwards but are now stored as decomposed sequences, so the text grows in code points even though nothing visibly changed.
And the case for not using this at all. If the goal is accent-insensitive searching or matching, do not destroy the data — compare it correctly instead. MySQL’s utf8mb4_0900_ai_ci collation is accent-insensitive and case-insensitive by design, PostgreSQL ships the unaccent extension, and in JavaScript Intl.Collator with sensitivity: “base” treats a and á as equal without touching either string. Strip accents when the destination genuinely cannot hold them: ASCII-only form fields, legacy fixed-width imports, URL slugs, and filenames that have to survive a trip between Windows, Linux and macOS — Apple’s HFS Plus stored filenames in a variant of decomposed Unicode while other volume formats use the precomposed form, which is exactly the mismatch that makes “the same” filename fail to match.
Which diacritics get stripped, and which letters don’t
Anything Unicode models as a base letter plus a combining mark in the U+0300–U+036F range is stripped, whatever language it came from. These are the marks people actually paste in:
| Letters | Result | Mark and language |
|---|---|---|
| á é í ó ú / Á É Í Ó Ú | a e i o u / A E I O U | Acute — Spanish, Portuguese, Czech |
| ñ ã õ | n a o | Tilde — Spanish, Portuguese |
| ä ö ü | a o u | Umlaut / diaeresis — German, Spanish ü |
| à è â ê î ô û | a e a e i o u | Grave and circumflex — French |
| ç | c | Cedilla — French, Portuguese, Turkish |
| ř š č ž ď | r s c z d | Caron — Czech, Slovak, Croatian |
| ą ę ż ś ć | a e z s c | Ogonek, dot, acute — Polish |
| ế ệ ừ ữ | e e u u | Stacked marks — Vietnamese |
The letters below are not accented letters at all. They are letters in their own right with no canonical decomposition, so normalization leaves them untouched and so does this tool. The third column is the conventional transliteration you would have to apply yourself — and it is a convention, not a rule.
| Letter | This tool returns | Usual transliteration |
|---|---|---|
| ß (German) | ß | ss |
| ø Ø (Danish, Norwegian) | ø Ø | o or oe |
| ł Ł (Polish) | ł Ł | l |
| đ Đ (Croatian, Vietnamese) | đ Đ | d or dj |
| æ Æ (Danish, Norwegian) | æ Æ | ae |
| œ Œ (French) | œ Œ | oe |
| þ ð (Icelandic) | þ ð | th and d |
| ı (Turkish dotless i) | ı | i |
Two rows deserve a second look. Danish and Norwegian å does get stripped to a, because it genuinely is a plus a combining ring above, while its neighbour ø does not — so a single word can come out half-converted. And Turkish İ (capital I with dot) strips to I while lowercase ı (dotless i) is left alone, which breaks the case pairing that Turkish depends on.
If you are debugging a mismatch rather than cleaning text, the useful question is usually normalization, not accents. Two strings that look identical on screen can differ in bytes because one is NFC (é as a single code point) and the other NFD (e plus a combining mark). Equality checks, sorting, regular expressions and string length all break on that, and nothing in the rendered text reveals it. In JavaScript, calling s.normalize(“NFC”) on both sides fixes the comparison without deleting anything, and the W3C recommends NFC for content on the Web. Strip accents only when the destination truly cannot store them.
How to remove accents in Excel, Google Sheets and Python
Excel has no accent-stripping function — nothing in Microsoft’s text function reference does it. The route that works in any version is nesting SUBSTITUTE, one level per letter.
=SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(A1,"á","a"),"é","e"),"í","i"),"ó","o"),"ú","u")Microsoft 365 shortens it with REGEXREPLACE, which takes a PCRE2 pattern, but its case_sensitivity argument defaults to case sensitive — capitals still need a second pass.
Google Sheets is a different answer. It has REGEXREPLACE too, but Google documents Sheets as supporting RE2 "except Unicode character class matching" — so the combining-mark class, the one pattern that would catch every accent at once, is missing there.
Python is the only one of the three that does it properly: normalize to NFD, the canonical decomposition that turns é into e plus a combining acute, then drop every combining mark.
import unicodedata
def strip_accents(s):
d = unicodedata.normalize('NFD', s)
return ''.join(c for c in d if unicodedata.combining(c) == 0)The field above runs that same NFD pass over the whole text at once — capitals, ñ and ü included — with a toggle to keep the ñ.
Common mistakes when removing accents
The tool does not stop you from making these — they are decisions you have to make about your text before you strip anything.
| The mistake | What breaks | The fix |
|---|---|---|
| Stripping ñ in Spanish text | año → ano changes meaning; señor → senor loses correctness | Use the "keep ñ" toggle; only strip ñ when the destination truly cannot store it (ASCII form field, legacy import) |
| Destroying accented data instead of comparing | Losing accents in your database means you can never restore them | Use accent-insensitive collation (MySQL utf8mb4_0900_ai_ci) or an extension (Postgres unaccent) for search; keep the accents in storage |
| Assuming ß becomes ss automatically | German ß, Danish ø, Polish ł pass through unchanged — they are letters, not accented letters | These need per-language transliteration (a table you write yourself), which is different from accent stripping |
| Forgetting the capital forms | Á, É, Ñ, Ü in headlines and IDs sometimes survive because a manual replacement forgets them | This tool handles both cases (á and Á, ñ and Ñ) at once because Unicode normalization does |
| Applying the output to published text | Spanish, Portuguese and French readers see wrong meaning (papá vs papa) or wrong pronunciation | Use accent-stripped text only as a technical key — filenames, URL slugs, database IDs — never as body copy |
| Not normalizing to NFC after | The output may be in decomposed form (NFD); some systems accept only precomposed (NFC), notably older Windows APIs | If you save the result to a filesystem or a strict database, call .normalize("NFC") on the JS side or the equivalent in your language |
Reference tables
FAQ
Does it change the ñ?
By default ñ becomes n, but there’s a toggle to preserve it — useful when "año" and "ano" must stay distinguishable.
Which languages does it support?
Any language written in Latin script with diacritics: Spanish, Portuguese, French, German, Czech, Vietnamese, and more.
Does it affect uppercase letters?
Yes, equally: Á→A, Ñ→N, Ü→U. Casing is otherwise preserved exactly.
How do I remove accents from filenames?
Paste the list of filenames in the field above (one per line), strip the accents, and copy the output. For a bulk rename of files on disk, PowerShell on Windows can iterate with Get-ChildItem and pass each name through .Normalize([Text.NormalizationForm]::FormD); Linux and macOS ship convmv (convmv --notest -f utf8 -t ascii --replace) or you can pipe through iconv with //TRANSLIT. Rename atomically, keep a backup, and be aware that Apple’s HFS+ historically stored filenames in decomposed form while APFS uses precomposed — that mismatch alone causes "file not found" errors.
Can I remove accents in SQL or a database?
Yes, and in most cases you should not — you should compare accent-insensitively instead. MySQL’s utf8mb4_0900_ai_ci collation and MariaDB’s utf8mb4_uca1400_ai_ci are accent-insensitive by design; PostgreSQL ships the unaccent extension you can call like SELECT unaccent('café'); SQL Server has accent-insensitive collations (Latin1_General_CI_AI). When you must physically strip accents — for a search index or exported ASCII text — TRANSLATE with source and target character sets, or the unaccent() function in Postgres, are the cleanest options. Only destroy the data on the way out to a system that cannot store it.
Will removing accents break Spanish words?
Sometimes — that is the entire reason the ñ toggle exists. In Spanish, the tilde carries meaning: año (year) becomes ano (anus) without it, sí (yes) becomes si (if), papá (dad) becomes papa (potato). Stripping accents is safe for a technical key (filename, slug, database ID) but not for published text. And ñ is not an accented n: the RAE (Real Academia Española) treats it as its own letter, which is why the toggle to preserve it is on by default in Spanish.
Does the tool handle emoji, Chinese, or Arabic text?
It leaves them alone. Accent removal only touches characters that Unicode models as a base letter plus a combining diacritical mark in the U+0300–U+036F range. Emoji (🎉), CJK ideographs (漢字), Arabic (العربية), and Cyrillic (Русский) all pass through unchanged because none have canonical decompositions in that range. Mixed text — an English caption with some Chinese and some accented Spanish — is safe: only the accented Latin characters get touched.