Make look-alike text actually equal.
Free Unicode normalizer. Convert text to NFC, NFD, NFKC or NFKD so visually identical strings compare equal. Runs in your browser, no limit.
Unicode normalizer
The same visible character can be stored as different sequences of bytes. This tool rewrites text into one of the four standard Unicode normalization forms, NFC, NFD, NFKC or NFKD, so that two strings which look identical on screen also become identical underneath, byte for byte.
It runs in your browser. Paste text, pick a form, copy the result. Nothing is uploaded, there's no account and no limit on how much you normalize.
How it works
One choice to make: which form you need.
The core problem
Take the letter é. It can be stored as one single precomposed codepoint, U+00E9, or as two separate codepoints, a plain e followed by a combining acute accent, U+0065 plus U+0301. Both render as exactly the same glyph on screen. Neither one is wrong. And a program comparing them byte by byte sees two completely different strings.
This is a genuinely common bug: two systems that both handle 'é' correctly can still fail to recognize the same word typed into each of them, because one encoded it as a single character and the other split it into a base letter plus a mark, and nothing told either one that both are equally valid representations of the same visible text.
The four forms
Unicode defines four standard normalization forms, and this tool converts between all of them.
The important distinction
NFC and NFD only reorganize how a character with marks is encoded; they never change what the text visually is. NFKC and NFKD go further: they also fold together characters that are visually distinct but considered compatible variants of the same underlying letter. A fi ligature, a single character combining f and i into one glyph, gets expanded into the separate letters f and i. Fullwidth Latin letters, a style used in some East Asian typesetting, get folded down to their ordinary-width equivalent.
That extra folding is powerful and also lossy: NFKC and NFKD can change how the text actually looks, collapsing a stylistic distinction the original text may have been using deliberately. Use NFC or NFD when you need equality checking without altering appearance, and NFKC or NFKD when you specifically need compatibility variants folded together, commonly for search or security matching.
Why it matters
A username stored one way and typed in for login using the other representation fails to match, even though both look identical to the person typing. A search index built from mixed normalization forms misses results that are, character for character on screen, exactly what was searched for. A deduplication script counts the same value twice because the two copies happen to use different encodings of the same accented letter.
Security-sensitive systems specifically use compatibility normalization to catch look-alike text used to disguise a domain name or a username, since two visually confusable strings often normalize to the same result once compatibility folding is applied.
Who uses it
Developers debugging a string comparison, a search match or a deduplication step that's silently failing on text that looks identical to a human reviewer. Anyone building a system that accepts user-entered text from multiple sources, different keyboards, operating systems, input methods, that might encode the same character differently.
It also comes up in security review, checking whether two visually similar strings are actually the same text in disguise, or genuinely different characters that merely look alike.
FAQ
Everything below is answered in full, nothing to click open.
Paste the text into the box above, choose a form (NFC, NFD, NFKC or NFKD), and the normalized result appears on the right.
Yes, entirely free. No signup, no trial and no usage limit, since it runs in your browser.
No. Normalization happens on your own machine in JavaScript. Nothing is sent over the network.
NFC combines a base letter and its accent into one precomposed character wherever possible. NFD does the opposite, splitting a precomposed character back into a base letter plus separate marks.
NFC. It's the form most text on the web is already in, and it's the right choice when you just need consistent, comparable text without changing anything visually.
NFKC does everything NFC does, and also folds compatibility variants, like ligatures and fullwidth characters, into their ordinary equivalents. That extra step can change how the text looks.
They're likely encoded with different normalization forms: one uses a single precomposed character, the other a base letter plus a separate combining mark. Normalizing both to the same form fixes the comparison.
NFC and NFD don't change how the text looks, only how it's encoded. NFKC and NFKD can change appearance, since they fold ligatures and other compatibility variants into plain equivalents.
A ligature is a single character combining two letters into one glyph, like fi. NFKC and NFKD expand a ligature back into its separate letters; NFC and NFD leave it as is.
Latin letters and digits given a wide, East Asian-style rendering, used in some CJK typesetting. NFKC and NFKD fold them down to ordinary-width equivalents.
Yes, that's the central case. NFC keeps or produces the single-character form; NFD keeps or produces the base-letter-plus-mark form.
Compatibility normalization, NFKC or NFKD, can reveal when two visually confusable strings actually reduce to the same text, which is one reason security tools use it.
Yes, it works the same in any modern mobile browser.
If the cause is mismatched normalization between the indexed text and the query, yes. Normalizing both to the same form before comparing resolves that specific failure.
Not yet. For several documents, paste, normalize and copy each one for now.
Yes, nothing is transmitted or retained, so it's fine for data you haven't shared anywhere.
No, normalization reorganizes how characters are encoded; it doesn't delete anything visible. For actually removing accents, use the accent remover instead.
NFD only decomposes canonically equivalent characters into base plus marks. NFKD does that too, and additionally folds compatibility variants like ligatures into their plain form.
The two rows likely use different normalization forms of the same visible text. Normalizing incoming data consistently before storage prevents this.
Yes, most web content and most software defaults to NFC, which is why it's the recommended starting point unless you have a specific reason to use another form.
Paste, choose a form, copy. Nothing to install, nothing leaving your browser.
Normalize my text