NFC vs NFKC: choose what your text may change
Compare canonical and compatibility normalization with accents, fullwidth letters, ligatures and spaces. Preview the tradeoffs before applying a form.
ON THIS PAGE
Choose a text policy before choosing a form
Normalization is useful when a system needs a consistent representation, but it cannot decide what the text is allowed to mean. Keep the original and identify the destination’s requirements first. A display name, a mathematical expression and a search key can have different reasons to preserve character distinctions.
| Form | Operation | Question to ask |
|---|---|---|
| NFC | Canonical decomposition followed by composition | Should canonically equivalent spellings share a composed representation? |
| NFD | Canonical decomposition | Does the next processing step explicitly expect decomposed sequences? |
| NFKC | Compatibility decomposition followed by composition | May compatibility distinctions such as width or presentation be discarded? |
| NFKD | Compatibility decomposition | Does the downstream policy require decomposed compatibility text? |
Read a concrete conversion
é A fi ① 12 kg −| Original part | After NFC | After NFKC | Practical consequence |
|---|---|---|---|
| e + U+0301 | é | é | Canonical spelling changes while the accent remains. |
| A | A | A | The fullwidth distinction is removed by NFKC. |
| fi | fi | fi | One ligature code point becomes two letters. |
| ① | ① | 1 | The circled presentation is lost. |
| 12 NBSP kg | 12 NBSP kg | 12 SPACE kg | The spacing distinction no longer prevents that wrap. |
| − (U+2212) | − | − | Normalization does not turn every look-alike into ASCII. |
Try the sample in Unicode Normalizer and preview NFC first, then NFKC. Read the code points as well as the rendered output. The table demonstrates why “make the text normal” is too vague: one form preserves distinctions that another removes. A successful conversion is not proof that it was appropriate for the document.
Review before applying
Preserve
Keep a separate copy of the original. GlyphIndex leaves the Input field unchanged.
Preview
Choose a form and select Preview. Check the proposed output and original/output code-point lists.
Apply deliberately
Choose Apply only after you accept the change. Copy and downloads use the applied output.
Verify the destination
Check the result in the system that will use it. Search, sorting and identifier rules may involve more than Unicode normalization.
What normalization does not solve
These forms do not repair text decoded with the wrong encoding, translate characters, remove all accents, apply a language-aware case fold, or detect confusable identifiers. Latin a and Cyrillic а remain distinct. A normalization match describes an equivalence relationship; it does not establish visual identity or safety.
Do not apply compatibility forms to an archival original merely to make comparison easier. If an application needs a separate search key, preserve the original display value and document the key policy in that application. The correct policy belongs to that system; this page cannot infer it from pasted text.
GlyphIndex uses the browser’s normalization implementation and accepts up to 10,000 UTF-16 units. It rejects isolated surrogates for conversion. Browser Unicode support can differ from the site’s pinned character-name data. Always review the actual preview, especially for text with newly assigned characters.
Sources and method
- Unicode Standard Annex #15: Unicode Normalization Forms — Canonical and compatibility equivalence.
- Unicode Technical Standard #39: Unicode Security Mechanisms — Confusable detection is a separate operation from normalization.
- Unicode Standard Annex #14: Unicode Line Breaking Algorithm — Line endings and spacing controls.