Unicode Text Normalizer

What does this tool do?

It takes any text and shows you exactly how it looks under each of the four Unicode normalization forms — NFC, NFD, NFKC, and NFKD — side by side: the normalized text, its code points in U+XXXX notation, its UTF-8 byte length, and whether that form matches your original input byte-for-byte. It also tells you which form (if any) your pasted text is already in.

Why normalization forms matter

Some characters can be represented two different ways in Unicode. An accented letter like é can be a single precomposed code point (U+00E9), or a plain e (U+0065) followed by a combining acute accent (U+0301). Both render identically on screen, but they are different sequences of bytes — so "café" === "café" can silently return false if one string came from a form that composes accents and the other from a form (like macOS's HFS+ filenames, or some IME/OCR pipelines) that decomposes them. The same applies to compatibility characters: a ligature like fi (U+FB01) is a single code point that looks like f + i, but only the K forms (NFKC/NFKD) treat it as equivalent to the two-letter sequence.

• NFC (Canonical Composition) — combines characters into their precomposed form wherever possible. The most common form on the web and in most databases.
• NFD (Canonical Decomposition) — splits precomposed characters into a base character plus combining marks.
• NFKC / NFKD — the same composition/decomposition, but also fold in "compatibility" equivalences (ligatures, fullwidth forms, superscripts) that NFC/NFD leave alone. Lossy for formatting, but useful for search/matching.

How to use it

Paste or type any text. The tool immediately shows which normalization form(s) your input already matches, then a table with all four forms — their normalized text, code points, and UTF-8 byte length — so you can see precisely which characters change (and by how many bytes) under each transformation.

Common uses

• Debugging string-comparison or lookup bugs caused by mismatched composed/decomposed forms (a classic pain point comparing filenames or user input against a database)
• Deciding which normalization form to apply before storing, hashing, or indexing user-submitted text
• Understanding why a search doesn't match text that looks identical on screen
• Checking whether an accented or ligature-heavy string will change size when normalized (affects fixed-length fields, hashes, or byte-length checks)

Related tools

• Unicode Character Info — look up the full Unicode properties (block, category, bidi class) of any character
• Unicode to HTML Entities — convert Unicode characters to &#...; HTML entities
• Text to Unicode Converter — convert text to raw U+XXXX codepoint notation

Privacy

This tool runs entirely in your browser using the built-in String.prototype.normalize() API. Your text is never uploaded to a server.