One character, several encodings
Unicode often allows the same visible text to be stored in more than one way. “é” can be a single code point (U+00E9) or “e” followed by a combining acute accent (U+0065 U+0301). They look identical but compare as different strings. That breaks search, deduplication, sorting, passwords and file names (macOS historically stored file names decomposed).
Normalisation converts text to a standard form:
| Form | What it does | Use for |
|---|---|---|
| NFC | composes characters where possible | storage and the web (W3C recommends NFC) |
| NFD | decomposes into base letters + combining marks | stripping accents, linguistic processing |
| NFKC | NFC plus compatibility mapping: fi → fi, ① → 1, ｶ → カ, x² → x2 | search and identifiers |
| NFKD | NFD plus compatibility mapping | maximum decomposition |
Compatibility forms (NFKC/NFKD) change meaning in some cases (superscripts lose their position, fractions become digits with a fraction slash, and styled Unicode “fonts” become plain letters) so use them for matching and search, not for storing what the author wrote.
The notes under the result show how many code points changed and examples of exactly what was converted.
Worked example
Here is what the Unicode Normalizer returns for its built-in example. Settings used: Form: NFC: composed (recommended). Click Try an example in the tool above to load it, then change it as you like.
Café (decomposed: Café) · finance · ① ② · ｶﾀｶﾅ · x² · ½ · ⅫCafé (decomposed: Café) · finance · ① ② · ｶﾀｶﾅ · x² · ½ · ⅫQuestions
What is the difference between NFC and NFD?
NFC stores characters in composed form (é as one code point); NFD splits them into base letters and combining marks (e + ◌́).
Which normalisation form should I use?
NFC for storing and exchanging text. NFKC when comparing or searching, where look-alike compatibility characters should match.
Last reviewed · How Textkiln tools work