How to normalize Unicode text
Paste text into Input text, choose a normalization form, and read the result in Normalized output. The page updates while you type or change the selected form. It also reports changed grapheme sequences when it can compute the comparison.
- Paste text into Input text.
- Select Upload for a .txt, .csv, .log, or .md file.
- Choose NFC (canonical composed), NFD (canonical decomposed), NFKC (compatibility composed), or NFKD (compatibility decomposed).
- Review the read-only Normalized output, which updates as you type or change the form.
- Inspect Changed Grapheme Sequences & Code Points, then use Copy or Download.
NFC vs NFD for canonical normalization
NFC applies canonical equivalence and recomposes a sequence into a precomposed code point when one exists. NFD uses the same equivalence rules but keeps the base character and combining marks separate. The two outputs can look identical while their code point sequences differ.
Input: é
NFC: é
NFD code points: U+0065 U+0301What NFKC and NFKD do to compatibility characters
NFKC and NFKD apply compatibility equivalence. They fold ligatures, superscripts, subscripts, and fullwidth forms into plain equivalents. The warning appears because this can remove distinctions used for math notation, CJK width, font selection, or other presentation. NFKC recomposes where possible; NFKD leaves the compatibility decomposition split.
Input: file ① Ａ
NFKC: file 1 A
NFKD: file 1 AWhat the detailed comparison shows
For non-empty Input text, the status line reports UTF-16 units, grapheme counts, and whether the selected form changed the text. Changed Grapheme Sequences & Code Points groups each change into Before and After values and lists the code points on both sides. If nothing changes, it says that the text was already in the selected form.
The detailed comparison is skipped when the product of the input and output grapheme-array lengths exceeds 400000. Normalized output still appears. Grapheme grouping uses Intl.Segmenter when available and falls back to Array.from otherwise. The normalization call uses the browser's native String.prototype.normalize API.
With no input, the output is cleared and the page asks you to enter text. If the selected form makes no change, the comparison reports that no grapheme sequences changed. Line-break characters pass through unchanged. The output area is read-only, so use Copy or Download to move the result elsewhere.
Use normalization before text comparison
Choose NFC before comparing names from different systems when the same visible character may use different canonical sequences. NFC gives equivalent sequences a composed form when one exists.
Choose NFKC for search or deduplication when text includes ligatures, circled numbers, or fullwidth letters. Keep the original text when those presentation distinctions belong in the displayed result.
When two strings look identical but compare differently, inspect Before and After in the detailed comparison. Their code points can show a combining mark or compatibility character behind the difference.
Choose another tool for other text transformations
Use Text Transformation Tools for related text work. Mojibake Fixer addresses wrong-encoding damage. Choose HTML Entity Encoder / Decoder for HTML entity references, or Hex Converter for hexadecimal character codes and conversion back to text.
Frequently asked questions
How do I normalize Unicode text for comparison?
Choose NFC for canonical normalization, or choose NFKC when compatibility characters should also fold into plain equivalents. Review Normalized output and the code point comparison before using the result.
What is the difference between NFC and NFD normalization?
NFC recomposes canonically equivalent sequences where a precomposed character exists, while NFD keeps the base character and combining marks separate. The visible result can look the same.
When should I use NFKC instead of NFKD?
Use NFKC when compatibility folding should be followed by recomposition. Use NFKD when the compatibility decomposition should remain separate. Both forms can remove presentation distinctions.
Can Unicode Normalizer fix mojibake or remove invisible characters?
Unicode Normalizer changes standardized Unicode representations. It does not repair mojibake or remove invisible characters. Use Mojibake Fixer for wrong-encoding damage and a detector when you need to find invisible characters.
Is my text sent to a server?
No. The page applies the browser's native String.prototype.normalize API to Input text. The page code has no network request or form submission that sends that text to a server.