Unicode Normalizer
Normalize Unicode text to NFC, NFD, NFKC or NFKD.
Unicode Normalization Checker
Check whether text already matches NFC, NFD, NFKC or NFKD. Compare normalized output, Unicode code points and UTF-8 byte differences directly in your browser.
The checker preserves the original input and tests all four normalization forms without submitting text to UnicodeNow.
Input is preserved exactly. The checker compares normalized copies against the original text.
NFC, NFD, NFKC and NFKD results
Compatibility normalization may change formatting or character distinctions. Review NFKC and NFKD output before replacing original text.
| Form | Input matches | Changed | Code points | UTF-8 bytes | UTF-16 units | Grapheme clusters | Actions |
|---|
Check Unicode normalization online
This Unicode normalization checker tests NFC, NFD, NFKC and NFKD simultaneously. It preserves the original input, shows which forms already match, generates normalized previews, compares code points, UTF-8 bytes, UTF-16 code units and grapheme clusters where supported, and warns about compatibility normalization. Everything runs locally in the browser.
Unicode normalization example
The default input is Café, where the final accented letter is stored as U+0065 U+0301 rather than U+00E9.
Input:
Café
Input matches: NFD, NFKD
Input does not match: NFC, NFKC| Form | Input matches | Output code points |
|---|---|---|
| NFC | No | U+0043 U+0061 U+0066 U+00E9 |
| NFD | Yes | U+0043 U+0061 U+0066 U+0065 U+0301 |
| NFKC | No | U+0043 U+0061 U+0066 U+00E9 |
| NFKD | Yes | U+0043 U+0061 U+0066 U+0065 U+0301 |
Canonical vs compatibility normalization
NFC uses canonical decomposition followed by composition. NFD uses canonical decomposition. NFKC uses compatibility decomposition followed by composition, and NFKD uses compatibility decomposition. NFC and NFD preserve canonical equivalence. NFKC and NFKD may replace compatibility characters, so typography or distinctions can change.
For example, composed é and decomposed é can be canonically equivalent. Compatibility normalization may also transform ① to 1 or fi to fi.
Composed vs decomposed Unicode text
Composed é is U+00E9. Decomposed é is U+0065 U+0301. They may render identically but compare as different strings before normalization. This matters for search, database uniqueness, filenames, usernames, string equality, cache keys, tests and sorting.
Code points and UTF-8 byte differences
Normalization may change code-point count, UTF-8 byte length, UTF-16 code-unit count and binary representation while the visible appearance stays similar. Composed é has one code point, two UTF-8 bytes and one UTF-16 unit. Decomposed e plus U+0301 has two code points, three UTF-8 bytes and two UTF-16 units.
When should text be normalized?
Normalization is useful for consistent database storage, search indexing, equality comparison, deduplication, filenames, user-generated text, API boundaries and test fixtures. Choose a policy deliberately, normalize at defined system boundaries, and preserve original user input when fidelity is required. Do not normalize cryptographic signatures after signing, and do not assume NFKC is always appropriate.
Risks of compatibility normalization
NFKC and NFKD can replace compatibility characters, remove formatting distinctions and produce output that may not be appropriate for display. Identifier policies require domain-specific decisions, and passwords or security-sensitive identifiers require careful standards-based handling. Compatibility normalization does not solve all confusable-character problems.
How to use the checker
- Paste or type Unicode text into the input field.
- Run the normalization check.
- Review which of NFC, NFD, NFKC and NFKD match the input.
- Compare normalized previews, code points and byte counts.
- Copy a normalized form only after reviewing the changes.
Common use cases
- Check whether database text is NFC normalized.
- Compare composed and decomposed characters.
- Debug strings that look identical but compare differently.
- Inspect normalization-related byte-length differences.
- Prepare consistent search and indexing input.
- Review compatibility normalization before applying it.
- Test filenames, identifiers and imported text.
- Create Unicode normalization test fixtures.
Privacy and local processing
This checker compares Unicode normalization forms with JavaScript directly in your browser. Your input is not submitted to UnicodeNow servers.
Frequently asked questions
How can I check whether text is NFC normalized?
Paste the text and run the checker. The NFC row says whether the original input exactly matches its NFC-normalized form.
What is the difference between NFC and NFD?
NFC uses canonical decomposition followed by composition where possible, while NFD keeps canonical decomposed sequences such as e plus U+0301.
What is the difference between NFKC and NFKD?
NFKC and NFKD use compatibility decomposition; NFKC then composes where possible, while NFKD stays decomposed.
Can text look identical but contain different code points?
Yes. A composed é can be U+00E9, while decomposed é is U+0065 followed by U+0301, even when they render alike.
Does normalization change UTF-8 byte length?
It can. Composed and decomposed forms may have different code-point sequences and therefore different UTF-8 byte counts.
Is NFKC safe for usernames and identifiers?
Not automatically. Compatibility normalization can be useful under a documented identifier policy, but security-sensitive identifiers need standards-based rules beyond normalization alone.
Does normalization remove accents?
No. Normalization may compose or decompose accents, but it does not generally delete accent marks.
Which normalization form should I use?
There is no universal best form. NFC is common for general text storage, but choose a policy based on your database, search, filenames, identifiers and interoperability needs.
Can I copy the normalized result?
Yes. Each result row has a Copy NFC, Copy NFD, Copy NFKC or Copy NFKD button, and Copy report copies the full comparison.
Is my text sent to a server?
No. This checker uses JavaScript normalization directly in your browser and does not submit your input to UnicodeNow servers.
Related tools
To actively convert text to a selected form, use the Unicode Normalizer. To inspect individual characters, use the Unicode Character Lookup.
Unicode Character Lookup
Search Unicode characters by glyph, code point, name, script or block.
Unicode Character Inspector
Inspect each Unicode character, encoding, category, script and normalization form.
Byte Length Calculator
Count UTF-8 bytes, code points, grapheme clusters and UTF-16 code units for text.
Invisible Character Detector
Find zero-width, control, variation, private-use and spacing characters.
Unicode Escape Converter
Convert text to and from Unicode escape sequences and numeric entities.
Unicode Text Compare
Compare strings exactly and after Unicode normalization.
Related guides
Read Unicode Normalization Explained for canonical and compatibility forms, or compare the most common canonical forms in NFC vs NFD.
What Is a Unicode Code Point?
Learn what Unicode code points are, how U+ notation works, and how code points differ from glyphs, bytes, code units and visible characters.
Code Points vs Code Units
Understand Unicode code points, UTF-8 bytes, UTF-16 code units, surrogate pairs, grapheme clusters and why string length can mislead.
What Is a Grapheme Cluster?
Learn how grapheme clusters represent user-perceived characters, why emoji and combining marks affect length, and how to handle text safely.
Unicode Normalization Explained
Learn NFC, NFD, NFKC and NFKD, canonical and compatibility equivalence, and safe normalization for comparison, search and identifiers.
NFC vs NFD
Compare NFC and NFD Unicode normalization with composed and decomposed examples, byte counts, equality checks and developer guidance.