Paste text to convert it to any of the four Unicode normalization forms and see exactly which characters changed, with their code points before and after. Use NFC for storage and comparison, or NFKC to fold look-alike compatibility characters such as fi, ① and full-width Ｈｅｌｌｏ.
Last updated:
Compare all four forms
Changed characters
Advertisement
Advertisement
How to use the Unicode Normalizer
Paste your text into the input box, or load the example to see typical cases.
Choose a form: NFC (most common), NFD, NFKC or NFKD.
Tick extra options if you also want to remove accents, invisible characters or special spaces.
Review the changes table to see which code points changed and why.
Copy or download the normalized text, or copy it as escaped \u sequences for code.
How the four forms treat common characters
Input
Code points
NFC
NFD
NFKC
NFKD
é (precomposed)
U+00E9
é
e + U+0301
é
e + U+0301
e + ◌́ (combining)
U+0065 U+0301
é (U+00E9)
unchanged
é (U+00E9)
unchanged
Å Angstrom sign
U+212B
Å (U+00C5)
A + U+030A
Å (U+00C5)
A + U+030A
Ω Ohm sign
U+2126
Ω (U+03A9)
Ω (U+03A9)
Ω (U+03A9)
Ω (U+03A9)
fi ligature
U+FB01
unchanged
unchanged
fi
fi
Full-width Ａ
U+FF21
unchanged
unchanged
A
A
Superscript ²
U+00B2
unchanged
unchanged
2
2
Circled ①
U+2460
unchanged
unchanged
1
1
½ vulgar fraction
U+00BD
unchanged
unchanged
1⁄2 (with U+2044)
1⁄2
™ trade mark
U+2122
unchanged
unchanged
TM
TM
No-break space
U+00A0
unchanged
unchanged
space U+0020
space U+0020
각 Hangul syllable
U+AC01
각
3 jamo U+1100 U+1161 U+11A8
각
3 jamo
NFC and NFD only make canonical changes: the text means exactly the same thing. NFKC and NFKD also apply compatibility mappings, which can change appearance and lose information.
When normalization matters
String comparison and deduplication: "Café" typed on a Mac and "Café" pasted from a PDF may differ byte for byte. Normalize both to NFC before comparing or hashing.
Search: normalize the index and the query the same way. NFKC plus case folding makes full-width, ligature and styled letters findable.
File names: some file systems store names decomposed (close to NFD) while others keep what you typed, which can create apparent duplicates when files are synced.
Usernames and identifiers: NFKC folds many look-alike characters, which reduces spoofing. It does not catch all confusables (Cyrillic а vs Latin a stay different).
Databases and APIs: normalize at the boundary (when data arrives) so everything stored is in one form.
Unicode often has more than one way to write the same visible text. For example é can be one code point (U+00E9) or an e followed by a combining acute accent (U+0065 U+0301). Normalization converts text to one agreed form so that strings which look the same also compare as equal, sort consistently and can be searched reliably.
What is the difference between NFC, NFD, NFKC and NFKD?
NFD decomposes characters into base letters plus combining marks; NFC decomposes and then recomposes them into precomposed characters where possible. Both only make canonical changes that never alter meaning. NFKD and NFKC additionally apply compatibility mappings, which fold formatting variants into plain characters: the ligature fi becomes f + i, ① becomes 1, x² becomes x2 and full-width Ｈ becomes H.
Which normalization form should I use?
NFC is the usual choice for storing and exchanging text and is recommended by the W3C for the web; most text is already in NFC. Use NFD when you need to work with accents separately, for example to strip them. Use NFKC for search, usernames and identifiers, where you want look-alike variants to match, but keep the original text for display because NFKC can lose formatting meaning such as superscripts.
Is NFKC normalization reversible?
No. Compatibility normalization throws away the distinction between variants, so after NFKC you cannot tell whether a 2 was originally ² or ②. Canonical forms (NFC and NFD) are reversible with each other: converting NFC to NFD and back gives the same NFC text.
Why does my text get longer in NFD?
NFD splits precomposed letters into a base letter plus one or more combining marks, so é (1 code point, 2 UTF-8 bytes) becomes e + ◌́ (2 code points, 3 UTF-8 bytes). Korean Hangul syllables decompose into 2 or 3 jamo each. The comparison table shows the code point and byte counts for every form.
Does normalization remove accents?
No. Normalization keeps accents; NFD only separates them from the letter. To remove them, decompose to NFD and delete the combining marks, which is what the 'Also remove accents' option does. Letters that are not built from a base letter plus an accent, such as ø, ł or ß, are not changed by this.
Does normalization remove zero-width or invisible characters?
No. Zero-width spaces, zero-width joiners, soft hyphens and byte order marks survive all four forms. Use the 'Also remove invisible characters' option to delete them, but be careful with emoji: zero-width joiners hold multi-person and family emoji together.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.