Remove Accents

Strip diacritics from text — turn café into cafe.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Unaccents text, rewriting it as its plain-Latin equivalent — é to e, ñ to n, ß to ss — for the systems that still refuse anything outside the ASCII letters: legacy database columns, filenames, email local parts, sort keys and import files.

How to use it

1Paste the accented text into the top box — the flattened version appears underneath as you type, with no button to press.
2Check the counter beside the Copy button: it reports how many characters were actually altered, which is the quick way to tell whether a file really had a diacritic problem or you were chasing something else.
3Copy the plain text out.

Example

Input: Straße Zürich — Kraków, Đà Nẵng, Ελλάδα, 日本
Output: Strasse Zurich — Krakow, Da Nang, Ελλαδα, 日本, with '7 characters normalized' shown beneath

Most of the work is generic: text is put into NFD, which splits a letter away from its accent mark, and the marks are then deleted — so it copes with letters no hand-written lookup table would have anticipated. A handful of characters carry no separate mark and are handled by explicit rules instead: ß, ø, æ, đ and ł, where the stroke or the ligature is part of the letter itself. What it will not do is transliterate. Ελλάδα loses its accent but stays in Greek, and 日本 comes back untouched — if you need a non-Latin script turned into Latin, this is the wrong tool. Punctuation and spacing are also left exactly as they were, em dashes and curly quotes included, so this on its own does not make a string ASCII-safe. For a URL, run the result through the Slug Generator afterwards.

What happens to your data

Normalisation is String.prototype.normalize followed by a short chain of regular expressions, all running in this tab; there is no dictionary to fetch and no request is made at any point. Names are the usual input here — a customer export, a member list, a column of addresses — and none of it is uploaded, stored or logged. The text lives in a single component state variable, so reloading the page is enough to clear it.

Last updated August 2026

A spreadsheet of member names goes into an old booking system and comes back as Jos? Garc?a. A deploy script falls over on a file called résumé-final.pdf. Someone searches the customer list for Muller, finds nothing, and Müller is sitting there in row 40. All three are one problem in different clothes: a letter carrying a mark, meeting something that understands only the twenty-six unmarked ones.

Before you flatten anything, decide which of two jobs you are doing. One is stripping the mark and keeping the letter — é to e, ñ to n. That is what you want for a search key, a sort key, a filename, or an import that refuses anything else. The other is transliterating by national convention, where ü becomes ue and ø becomes oe — how those languages spell the letter when the mark is unavailable. The two give different answers for the same input, and Muller and Mueller are not the same surname.

Removing accents also does not make text ASCII. Marks live on letters, so spaces, em dashes, curly quotes and ampersands come through untouched, and so does any letter with no separable mark — þ, ð and ı survive a pass like this unchanged.

The mistake that costs most is overwriting the original. Flattened text is a key, not a name — keep the accented spelling for display and store the plain one beside it.

How it works

Toolvore puts your text through Unicode NFD normalisation, which splits a letter such as é into a plain e and a separate combining acute, then deletes every mark in the U+0300 to U+036F range with one regular expression. That is why it copes with letters nobody thought to list: the rule targets the mark, not the letter. Five cases carry no separable mark, since the stroke or ligature is part of the letterform, and are named individually — ß to ss, Æ and æ to AE and ae, Ø to O rather than the OE Danish would write, Đ to D, Ł to L. Nothing else is listed, so þ, ð, ı and ŋ arrive exactly as they left. The weak point is that the text is never recomposed into NFC afterwards: a mark outside that one range survives the deletion and stays detached from its letter, so a voiced Japanese kana or a Korean syllable comes back looking identical while carrying more code points than before.

Common use cases

Flattening a customer export before it enters a system that only accepts unaccented letters
Turning a name with diacritics into a filename a build script will not choke on
Building a search key so that Muller and Müller match each other
Cleaning a column of European city names ahead of a bulk import
Producing a sort key for a list that mixes accented and unaccented spellings

Frequently asked questions

Why do two names that look identical fail to match in my database?＋

Two identical-looking names can be two different strings. é exists twice in Unicode: as the single character U+00E9, and as a plain e plus the combining acute U+0301. They render the same and compare as unequal, enough to break an exact match, a join or a lookup. macOS has historically stored filenames decomposed and Windows precomposed, so one file copied between them carries different bytes for the same visible name. Normalising both sides to NFC before you compare fixes the mismatch without throwing anything away, rather than stripping accents to force a match.

Should ü become u or ue when the umlaut has to go?＋

Whichever the reader expects. German convention expands rather than strips: ä to ae, ö to oe, ü to ue and ß to ss, so Müller without an umlaut is Mueller. That is the spelling a German reader recognises, and the one used on forms and in the machine-readable strip of a passport. Plain mark removal gives Muller instead, a different surname that happens to exist. This tool strips the vowels and expands only ß, so German text comes out in a mixed convention. If you need the German spelling, replace those four vowels yourself first.

Does removing an accent change the meaning of a word?＋

Frequently, and sometimes badly. In Spanish, año is a year and ano is not. French sur and sûr, ou and où, are separate words. Portuguese avô and avó are grandfather and grandmother. Vietnamese leans on its marks hardest of all: they carry both vowel quality and tone, so a flattened Vietnamese sentence loses most of what separates one word from the next. None of that matters for a matching key or a filename, and all of it matters the moment a person reads the result — which is the case for keeping the original alongside.

Is unaccented text safe to use as a filename or a URL?＋

Not on its own. Removing marks deals with letters and nothing else, so spaces, em dashes, curly quotes, slashes, ampersands and question marks all survive, along with any letter that had no separable mark. A URL wants lowercase, hyphens and a restricted character set; a filename has its own forbidden characters, which differ between Windows, macOS and Linux. Treat unaccenting as the first of two steps and run a slug or filename pass over the result. That order matters, because a slug pass meeting é usually drops it rather than folding it to e.

Where does the text I paste in actually go?＋

Nowhere. The conversion is Unicode normalisation followed by a short chain of regular expressions, all running in the tab you have open. There is no dictionary to download, no server route behind it, and no request made at any point. The text lives in one piece of component state and the plain version is recalculated as you type, so reloading the page clears both. Nothing is written to browser storage and no history of past conversions is kept — which matters, because what gets pasted in here is usually a real customer export.

How do I strip accents from a whole column in Excel, SQL or Python?＋

The same two steps exist almost everywhere. In Python, unicodedata.normalize to NFD followed by dropping every character in the Mn category. In JavaScript, normalize NFD and a regex over the combining range. In PostgreSQL, the unaccent extension, which reads a rules file you can edit. In Excel there is no clean built-in, so people end up with a nested SUBSTITUTE or a Power Query step. Whichever you pick, the stroked letters and ß sit outside the general rule and need their own replacements, or German and Polish rows come through half converted.

What happens to Greek, Cyrillic or Chinese text?＋

They are different jobs. Removing the mark from Ελλάδα gives Ελλαδα — still Greek, just unaccented, because those letters were never Latin to begin with. Turning it into Ellada is transliteration, which needs a per-language table with genuine choices in it: Cyrillic ж is zh to an English speaker and j to a French one. Chinese and Japanese have no accents to strip at all, so putting them into Latin script is romanisation — for Japanese a dictionary problem and not a character mapping, since a character's reading depends on the word around it.

Why do accented names sort in the wrong place?＋

Because a naive sort compares code point numbers, and every accented Latin letter sits above z. Ángel and Ötztal therefore land after Zurich instead of near the top. Proper collation treats á as a variant of a, with rules that are per language rather than universal: Swedish deliberately places å, ä and ö after z as the last three letters of its alphabet, while Spanish sorts ñ as a distinct letter directly after n. A flattened sort key alongside the real name is the usual workaround, at the cost of those distinctions.