Accent remover with stated limits

The accent remover performs one transformation: it decomposes the input with NFD, deletes every codepoint in the Unicode Mark category, and recomposes the remainder with NFC. Café resolves to cafe, naïve to naive, jalapeño to jalapeno, and every character outside that category is returned unmodified.

It executes in the browser. No request is issued, no allowance applies and no length cap exists, which is worth stating precisely because several tools ranking for this term process on their own servers. The typical input for this operation is a column of real names being turned into keys, and that is not a workload most people intend to transmit.

No configuration and no options, because the transformation has no parameters.

Step 1

Paste the source text, in whatever script it is written in.

Step 2

Run the removal. The transform completes locally and synchronously.

Step 3

Copy the output, and check the boundary cases below if your data contains Nordic, Polish or Vietnamese names.

Unicode encodes an accented letter in two canonically equivalent ways. É may be the single precomposed codepoint U+00C9, or it may be U+0045 followed by the combining acute accent U+0301. Both render identically, and a naive character filter sees two entirely different strings.

NFD eliminates that ambiguity by forcing every precomposed form into its decomposed equivalent. Once decomposed, the accent is a separate codepoint carrying the Unicode general category Mark, and removing it is a category filter rather than a table lookup. NFC then recomposes what remains, so the output is in the normal form most systems expect.

The practical consequence is coverage. A lookup table covers the letters someone remembered to add. A category filter covers every combining mark Unicode defines, including ones added after the code was written.

Competing pages in this category commonly state that their tool does not support Cyrillic, Greek, Arabic or other non-Latin scripts. That limitation follows from a Latin lookup table and does not apply to a category filter.

Greek tonos and dialytika are Marks, so Ελλάδα resolves to Ελλαδα. Cyrillic Й decomposes to И and ё to е, because the breve and the diaeresis are combining marks like any other. Arabic harakat and Hebrew niqqud are Marks and are removed, leaving the consonant skeleton, which is the normalised form Arabic and Hebrew search systems generally index against.

Vietnamese is the most complete case. It stacks a vowel diacritic and a tone diacritic on a single letter, and both are Marks, so Tiếng Việt resolves to Tieng Viet. Whether that is desirable is a separate judgement: tone is lexical in Vietnamese, so this belongs in an identifier pipeline rather than in prose.

A decomposition-based transform can only remove what decomposes. Letters whose distinguishing feature is a stroke, a bar or a ligature have no canonical decomposition, so no mark exists to filter. At least one page ranking for this term lists these among its conversions. This one lists them among its exclusions, verified by running them.

Ø and ø

O with stroke. No decomposition, no conversion. Returned unchanged.

Ł and ł

L with stroke. Returned unchanged.

Đ, Ð and đ

D with stroke and eth. Returned unchanged, including inside Vietnamese text where every other mark is removed.

Æ, æ, Œ and œ

Ligatures. No decomposition exists, and expanding them to ae and oe would be transliteration rather than mark removal.

ß

Sharp s. Not a marked letter, and not expanded to ss by this transform.

Å and å

The counterexample worth knowing: the ring above is a combining mark, so this one does reduce to a while its Nordic neighbour ø does not.

The subtlest failure is canonical equivalence itself. Two spreadsheet cells both displaying café may hold different byte sequences, one precomposed and one decomposed, and an exact-match lookup compares codepoints rather than glyphs. The lookup fails against a value that is visibly identical, which is among the hardest data defects to diagnose by eye.

Beyond that: slug generators that drop rather than transliterate accented characters, collation that sorts é far from e under a weak collator, and single-byte legacy exports that replace accented letters with unrecoverable substitution characters. Normalising both sides of a comparison through this transform removes the class of problem rather than the instance.

Accent removal is lossy and sometimes lexically significant. In French, ou and où are different words. In Spanish, año and ano differ by one mark. In Vietnamese, tone distinguishes unrelated words entirely. Applying this transform to published prose in those languages degrades it.

The correct pattern is almost always to store both forms: the original for display and the stripped form for matching, sorting or key generation. Replacing the original is a decision to discard information, and it should be a deliberate one rather than a side effect of cleaning a column.

Engineering teams deriving slugs, filenames, usernames, email local parts and programming identifiers from user-supplied text, where the source language is unbounded and the destination system is not. Data teams reconciling name lists from systems with inconsistent normalisation.

Search and indexing work, where the stripped form becomes the match key so an unaccented query reaches an accented record. And migration work into systems whose character support is narrower than the corpus being moved.