Unicode Inspector
Inventory the original strings when you need to explain which code points differ before normalization. Open the Unicode Inspector.
Normalization Checker
Normalization Checker is a browser utility that compares text across the four Unicode normalization forms. Compare all four standard normalization forms side by side, see which transformations alter your text, and choose a boundary policy without confusing equivalence with visual sameness.
Canonical formsNFC + NFD
Compatibility formsNFKC + NFKD
Compared locallyFour outputs
Analyze your own text
Try a sample:
Maximum 2,000 characters · no upload
Enter text or choose a sample to generate a detailed report.
Normalization in one minute
Unicode permits some strings with different code-point sequences to count as equivalent. Normalization calculates a stable representative for a selected equivalence model.
- NFC composes where the standard defines a canonical composite.
- NFD expands characters through canonical decomposition.
- NFKC composes after applying broader compatibility mappings.
- NFKD decomposes canonically and also replaces compatibility variants.
Input sequenceoriginal text
Canonical equivalence
NFCNFD
Retains compatibility distinctions
Compatibility equivalence
NFKCNFKD
May fold width, ligature, or style variants
NFC, NFD, NFKC, and NFKD compared
The letter C means composition; D means decomposition. The K marks a compatibility transformation, which can discard distinctions that the canonical pair retains.
| Form | Equivalence basis | Typical shape | Appropriate use | Risk to review |
|---|---|---|---|---|
| NFC | Canonical | Composed when possible | General text storage and exchange | Does not merge compatibility variants |
| NFD | Canonical | Decomposed sequence | Processes that operate on constituent marks | Often uses more code points |
| NFKC | Compatibility + canonical | Compatibility-folded, then composed | Controlled matching and identifier preparation | May erase formatting semantics |
| NFKD | Compatibility + canonical | Compatibility-folded and decomposed | Specialized analysis pipelines | Produces the broadest transformation |
Where the four forms diverge
The right form follows the product requirement. A transformation that is helpful for search can be destructive in archival text.
| Input kind | Canonical result | Compatibility result |
|---|---|---|
| é versus e + combining acute | NFC aligns them as é; NFD aligns them as e plus the mark | The compatibility pair reaches equivalent versions too |
| Fullwidth Ａ | NFC and NFD retain the fullwidth character | NFKC and NFKD map it to ordinary A |
| Ligature ffi | Canonical forms preserve the ligature code point | Compatibility forms expand it to ffi |
| Superscript ² | Canonical forms keep the superscript | Compatibility forms map it to 2 |
How to set a normalization policy
Follow the sequence from evidence to policy. Each stage guards against a different class of Unicode mistake.
Locate the boundary
Name the precise operation—storage, comparison, search indexing, identifier creation, or display—rather than normalizing everywhere.
Choose equivalence
Use canonical equivalence when typography must survive. Consider compatibility equivalence only when the removed distinction is irrelevant.
Test real scripts
Exercise accented Latin text, combining-mark scripts, Hangul, emoji sequences, and any legacy data your product actually receives.
Record the contract
Document the chosen form beside validation and database rules so every producer applies the same transformation once.
Questions people ask about normalization checker
Which form should a website normally use?
NFC is a common interchange choice because it preserves canonical meaning and favors composed sequences. The correct policy still depends on your data contract and should be tested with the scripts you support.
Will normalization make confusable letters identical?
Not in general. Latin a and Cyrillic а are different characters with no canonical equivalence. Confusable detection is a separate security operation.
Can normalization break emoji?
Conforming normalization preserves the identities required by standard emoji sequences, but application code can still damage a sequence by filtering joiners, selectors, tags, or modifiers separately.
Why do two equal-looking results show different U+ values?
Fonts can draw different characters alike, and some combining sequences resemble precomposed characters without being canonically equivalent. Code-point output reveals the distinction that glyphs hide.
Build the surrounding knowledge
Engineering
Unicode Normalization: NFC, NFD, NFKC, and NFKD
Understand canonically equivalent strings, compatibility mappings, and when normalization helps search, storage, comparison, and security.
Read the guide →Practical useCopying Unicode Symbols Without Damaging the Text
Choose the intended character, retain every component, and preview it in the final destination while protecting meaning and accessibility.
Read the guide →SecurityUnicode Confusable Characters and Identifier Security
Understand homoglyphs, mixed-script identifiers, normalization limits, and safer ways to validate usernames, domains, and account IDs.
Read the guide →Move to the next diagnostic
Code Point Converter
Convert the chosen normalized output when a database, stylesheet, or program needs another representation. Open the Code Point Converter.
Standards behind this tool
The browser output is designed as a practical diagnostic, while normative definitions belong to the standards publishers below.