Browse the guides
Docs

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
  1. Choose a text policy before choosing a form
  2. Read a concrete conversion
  3. Review before applying
  4. What normalization does not solve

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.

FormOperationQuestion to ask
NFCCanonical decomposition followed by compositionShould canonically equivalent spellings share a composed representation?
NFDCanonical decompositionDoes the next processing step explicitly expect decomposed sequences?
NFKCCompatibility decomposition followed by compositionMay compatibility distinctions such as width or presentation be discarded?
NFKDCompatibility decompositionDoes the downstream policy require decomposed compatibility text?

Read a concrete conversion

Actual characters: combining accent, fullwidth A, fi ligature, circled one, NBSP, and minus sign.
é A fi ① 12 kg −
Original partAfter NFCAfter NFKCPractical consequence
e + U+0301ééCanonical spelling changes while the accent remains.
AAAThe fullwidth distinction is removed by NFKC.
fififiOne ligature code point becomes two letters.
①①1The circled presentation is lost.
12 NBSP kg12 NBSP kg12 SPACE kgThe 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

  1. Preserve

    Keep a separate copy of the original. GlyphIndex leaves the Input field unchanged.

  2. Preview

    Choose a form and select Preview. Check the proposed output and original/output code-point lists.

  3. Apply deliberately

    Choose Apply only after you accept the change. Copy and downloads use the applied output.

  4. 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

Copy manually

Couldn’t copy automatically. Select the text below and use your device’s Copy command.

Use your device’s Copy command, then paste the text where you need it.

Character details

Code points
UTF-8 bytes
View character details

Appearance can vary by font.

Your saved symbols

Save symbols for another visit in this browser. They won’t appear on your other devices or browser profiles.