Unicode Normalizer
Convert text between Unicode normalization forms NFC, NFD, NFKC and NFKD — compose or decompose accents, and fold look-alikes like fi and ① to plain text.
Canonical compose — merges combining marks into single characters. The web default.
Code points: 0 → 0
UTF-8 bytes: 0 → 0
UTF-16 code units (what .length counts): 0 → 0
Highlighted: the characters this form changes.
Normalization uses the browser’s own String.prototype.normalize — not a custom, potentially incomplete Unicode table.
What Unicode normalization does
The same visible text can be stored as different sequences of code points. An accented "é" may be a single precomposed character (U+00E9) or a plain "e" followed by a combining acute accent (U+0065 U+0301) — identical on screen, yet unequal strings that quietly break comparison, deduplication, sorting, and search. Normalization rewrites text to one canonical sequence so those variants match. This tool applies the browser’s native normalizer and reports the code-point count, the UTF-16 length (what .length counts) and the UTF-8 byte size under every form, highlighting the characters each form changes, so you can see at a glance which forms actually change your text. The Character by character table goes further: one row for each character some form changes (or for every one, with its box ticked), counting a character as you see it — a letter with its marks, or a Hangul syllable, is one row — with its code points and what NFC, NFD, NFKC and NFKD each make of it. Every compare row has its own Copy button, the Try one: row loads combining accents, ligatures, full-width letters, circled numbers, Roman numerals or Korean from a Mac to see what each form does to them, and Copy link carries the text and the chosen form; text too long for a link is left out of it, and the page says so. “Line breaks in the output” keeps the breaks as they are, the default, or rewrites every one — a CRLF counted as one — as LF, CRLF or CR in what is shown, copied and downloaded, and a line under it names the breaks the input holds, since a text box draws them all alike.
NFC vs NFD vs NFKC vs NFKD
The two canonical forms preserve the meaning of every character: NFC composes marks into precomposed characters (the form the web and most databases expect), while NFD splits them into base letter plus combining marks. The two compatibility forms go further and fold visually distinct look-alikes to a plain equivalent — the "fi" ligature becomes "fi", "①" becomes "1", "½" becomes "1⁄2" — with NFKC composing afterward and NFKD leaving them decomposed. Use NFC for storage and interchange, NFD when you need to strip diacritics, and the NFK forms for search indexing or homoglyph and spoofing checks where look-alikes must collapse. To read the text out of an image or a scan, use image to text (OCR).
Frequently asked questions
What is the difference between NFC and NFD?
NFC composes combining marks into single precomposed characters — "e" plus a combining acute accent becomes "é", one code point. NFD does the reverse, splitting "é" back into "e" plus the combining accent. Both preserve the exact characters and differ only in how those characters are encoded. NFC is the usual choice for the web and databases.
When should I use NFKC or NFKD?
Use the compatibility forms when visually similar characters must be treated as the same. NFKC and NFKD fold ligatures, circled numbers, full-width letters, and fractions to their plain equivalents (fi becomes fi, ① becomes 1, ½ becomes 1⁄2). That is what you want for search indexing, username uniqueness, and homoglyph or spoofing checks. The fold is lossy, so it is not appropriate for text you plan to display back unchanged.
Why does the UTF-8 size change when the text looks the same?
Because the forms store the same text as different code points, and UTF-8 spends one to four bytes on each. A Hangul syllable is one code point and three bytes in NFC, but three jamo and nine bytes in NFD, so 한글 is 6 bytes one way and 18 the other. The page prints UTF-8 bytes: before → after under the output and the byte size on every compare row, highlights the characters each form changed, and the Character by character table shows what each form makes of each character.
Can I copy any form, count UTF-16 units, try ready examples, or send the text as a link?
Yes. Each compare row reads its code points, UTF-16 units and UTF-8 bytes and has its own Copy button — Copy NFKD and so on — so any form can be taken without changing the menu, and the summary under the output adds the UTF-16 count that .length gives, before and after. Try one: loads combining accents, ligatures, full-width letters, circled numbers, Roman numerals or Korean from a Mac, each built from code points. Copy link carries the text and the chosen form, and a link opens on them; text too long for a link is left out and the page says so, while the form still travels.
Can it change the line breaks too?
Yes. “Line breaks in the output” keeps them as they are, which is the default, or writes every break — a CRLF counted as one — as LF (Linux, macOS), CRLF (Windows) or CR (classic Mac) in what is shown, copied and downloaded. Because a text box draws every kind alike, a line under it says which breaks the input holds and how many of each.