How to use the Unicode Normalizer
Normalize text in the browser and review the result in this order:
- Paste text into the input area.
- Choose NFC (canonical composed), NFD (canonical decomposed), NFKC (compatibility composed), or NFKD (compatibility decomposed).
- Review the read-only output. It updates as you type or change the selected form.
- Inspect Changed Grapheme Sequences & Code Points.
- Use Copy or Download below the output.
Upload text from a file
Select Upload to open a file picker for supported text files. The selected file is read as text and placed into the input. You can also drop a supported file anywhere on the page or paste text outside the input; the shared text uploader routes it here.
What is Unicode Normalizer? It is a normalization tool, not a corruption repair or representation-conversion tool. It rewrites text into NFC, NFD, NFKC, or NFKD and provides changed-sequence details when the comparison can be computed.
Choose a normalization form
Canonical equivalence (used by NFC and NFD) covers only sequences the Unicode standard defines as strictly identical in appearance and meaning - nothing is visually or semantically lost when converting between them. Compatibility equivalence (used by NFKC and NFKD) is broader and lossier: it also folds together characters that look or behave similarly for many purposes but aren't truly identical, such as ligatures, superscript and subscript digits, fullwidth and halfwidth letters, and other formatting or presentation variants. Choosing a compatibility form means intentionally discarding those distinctions in exchange for more aggressive matching - useful for search and deduplication, risky for anything where the original presentation matters.
NFC vs. NFD, and NFKC vs. NFKD
- NFC (canonical composed) uses canonical equivalence and recomposes where a precomposed character exists. For example,
éis one precomposed code point. - NFD (canonical decomposed) uses canonical equivalence and separates characters into a base code point and combining marks, such as
eplusU+0301. - NFKC (compatibility composed) applies compatibility decomposition, then recomposes where possible.
- NFKD (compatibility decomposed) applies compatibility decomposition without recomposing.
Canonical forms remove differences between canonically equivalent sequences. Compatibility forms can also fold ligatures, superscripts, subscripts, fullwidth or halfwidth forms, and other presentation characters into plain equivalents. Review the warning before using them when those distinctions matter.
Understand the result states
- With no input, the output is cleared and Enter text to compare normalization forms. appears.
- If the text is already in the selected form, the comparison says No grapheme sequences changed and the stats identify the text as unchanged.
- For non-empty input, the stats show input and output UTF-16 units, grapheme counts, and whether normalization changed the text.
- The output area is read-only. Use Copy or Download to move the normalized text elsewhere.
Review changes and limitations
Changed Grapheme Sequences & Code Points shows computed before-and-after groups and their code points. The detailed diff is not computed when the product of the input and output grapheme-array lengths exceeds 400000; normalization still runs and the output is still produced.
The detailed view uses Intl.Segmenter when available. Otherwise it falls back to Array.from, which is code-point iteration and is not equivalent to full grapheme segmentation in every environment. Normalization itself uses the browser's native String.prototype.normalize API.
Why This Isn't Mojibake Fixer, Unicode Converter, Unicode Inspector, or Invisible Text Tools
The Mojibake Fixer assumes text was corrupted by a wrong encoding decode and reverses that specific mistake - it does not standardize already-correct text. The Unicode Converter changes how correctly-decoded text is represented, as \uXXXX escapes or numeric code points, without changing which characters it contains. The Unicode Inspector reports character properties (scripts, categories, names) without rewriting the text. The Invisible Character Detector finds and flags zero-width and invisible characters, and the Invisible Text Generator inserts them - this tool does neither; normalization never adds or strips invisible characters on its own. Unicode Normalizer's job is narrower than all of these: it only rewrites text between the four standardized, equivalent Unicode normalization forms.
Other limitations
Line-break characters are not affected by the four forms. This tool normalizes Unicode representation; it does not repair mojibake, convert escape sequences or numeric code points, inspect character properties, or detect invisible characters. Use the related tools below for those separate tasks.
Frequently Asked Questions (FAQs)
What is Unicode normalization?
Unicode allows the same visible character to be represented by different code point sequences. Normalization rewrites text into one of four standard forms so equivalent sequences become byte-for-byte identical, which matters for comparison, search, and storage.
What is the difference between canonical and compatibility normalization?
Canonical forms (NFC, NFD) merge or split only strictly equivalent sequences - nothing is lost. Compatibility forms (NFKC, NFKD) also fold in characters that are equivalent for many purposes but not identical, such as ligatures and fullwidth forms, so some distinctions are intentionally lost.
What is the difference between NFC and NFD, or NFKC and NFKD?
The C forms recompose into precomposed code points where possible; the D forms decompose into base plus combining marks and don't recompose. NFC/NFD use canonical equivalence only; NFKC/NFKD add compatibility equivalence.
Will normalization remove invisible characters or fix garbled text?
No. It only rewrites text between standardized, equivalent representations - it does not repair mojibake, convert to or from escapes or numeric code points, inspect character properties, or strip invisible characters.
Are line breaks preserved?
Yes. Line break characters are not affected by any of the four normalization forms.
Is my text sent to a server?
No. Normalization runs entirely in your browser using the native String.prototype.normalize API. Nothing is uploaded.