How it works
NFD performs canonical decomposition and orders combining marks; NFC additionally composes eligible sequences. NFKD and NFKC also apply compatibility decomposition: for example, circled ① becomes 1. The tool uses the browser’s standard String.normalize implementation. The report shows forms the input already satisfies and code point sequences before and after conversion.
Practical example
In Café, é can be one code point U+00E9 or the sequence U+0065 U+0301. NFC turns this example into the composed letter; NFD produces the letter and a separate combining mark. NFKC also converts Ａ to A and the fi ligature to fi.
Local processing
Input and output are not sent to a server, included in analytics, or saved in browser storage. Copying and downloading happen only when you request them.
Frequently asked questions
Which form should I choose?
Use the form expected by your system. NFC is often useful for canonically equivalent text. NFKC and NFKD may remove semantic or presentation distinctions; use them only with clear requirements and after reviewing the output.
Does normalization remove invisible characters or turn Cyrillic into Latin?
No. It is not text cleanup, transliteration, or a confusable-letter check. Canonical normalization does not remove arbitrary invisible characters. Use the separate detector to inspect them.
What are the limits?
Input is limited to 50,000 UTF-16 code units; unpaired surrogates are rejected. All text is converted, but the report shows only the first 80 code points of each version. Support for newly added characters depends on the browser’s Unicode version. NFKC/NFKD can erase distinctions that cannot be recovered from the output.