Unicode normalizer

Unicode normalizer

What the Unicode normalizer does

The same visible character can be stored as more than one sequence of bytes underneath. This app rewrites text into one of the four standard Unicode normalization forms, NFC, NFD, NFKC or NFKD, so two strings that look identical on screen actually become identical underneath too.

It's local. Normalization runs entirely in your browser, nothing you paste is uploaded, and there's no cap on how much text you process or how often.

That matters here specifically because normalization bugs are the kind that hide in plain sight: the text looks completely fine, so there's rarely anything visual to check. The value of doing this on your own device is that you can test exactly the text that's failing without sending it anywhere first.

Workflow

How to normalize Unicode text in three steps

One decision to make: which form fits the job.

Step 1

Paste the text into the box.

Step 2

Pick a form: NFC, NFD, NFKC or NFKD.

Step 3

Copy the normalized result.

The core problem

Why two strings that look identical can compare unequal

Take é. It can be stored as a single precomposed codepoint, or as two separate codepoints, a plain e followed by a combining acute accent, rendering as exactly the same glyph either way. Neither encoding is wrong. And code comparing the two byte by byte sees two completely different strings.

This causes real, if quiet, bugs: two systems that both display 'é' correctly can still fail to recognize the same word entered into each of them, because one stored it as a single character and the other split it into a base letter plus a mark, with nothing telling either system the two are equally valid forms of the same visible text.

The four forms

NFC, NFD, NFKC and NFKD, explained

Unicode defines four standard normalization forms, and this app converts freely between all of them.

NFC

Canonical composition: combines a base letter and its marks into a single precomposed character wherever one exists. The default, and what most web text already uses.

NFD

Canonical decomposition: splits every precomposed character back into a base letter plus separate combining marks.

NFKC

Compatibility composition: does everything NFC does, plus folds compatibility variants, like ligatures and fullwidth characters, into their ordinary equivalent, then recomposes.

NFKD

Compatibility decomposition: does everything NFD does, plus folds compatibility variants into their ordinary equivalent, without recomposing.

The distinction that matters

Canonical versus compatibility normalization

NFC and NFD only reorganize how a character with marks is encoded; neither one changes what the text actually looks like. NFKC and NFKD go a step further: they also fold together characters that are visually distinct but count as compatible variants of the same underlying letter. A fi ligature, one character combining f and i into a single glyph, gets expanded into the two separate letters. Fullwidth Latin characters, used in some East Asian typesetting, get folded down to their ordinary-width equivalents.

That extra folding is useful and genuinely lossy at the same time: NFKC and NFKD can change how text actually appears, collapsing a stylistic distinction the original text might have used on purpose. Reach for NFC or NFD when you need equality checking without touching appearance, and NFKC or NFKD specifically when compatibility variants need folding together, most often for search or security matching.

Why it matters

What un-normalized text breaks in real systems

A username stored one way but typed in later using the other representation fails to log a user in, even though both look identical on the screen. A search index built from mixed normalization forms misses results that are, character for character visually, exactly what someone searched for. A deduplication pass counts the same value twice, purely because the two copies happen to use different encodings of the same accented letter.

Security-conscious systems use compatibility normalization specifically to catch look-alike text used to disguise a domain name or a username, since two visually confusable strings frequently normalize down to the same result once compatibility folding is applied.

Who it's for

Who uses a Unicode normalizer, and when

Developers debugging a string comparison, a search match or a dedup step that's silently failing on text that looks completely identical to a human reviewer. Anyone building a system that accepts text from a mix of keyboards, operating systems and input methods, which can encode the same visible character in more than one way.

It also comes up in security review, checking whether two visually similar strings are actually the same text disguised, or genuinely different characters that merely look alike.