Paste any Unicode text — accented chars, CJK, emoji, etc.
Ready to normalize
Paste text, choose a form, and click Normalize// normalize unicode between NFC · NFD · NFKC · NFKD
Normalize Unicode text between NFC, NFD, NFKC, and NFKD forms instantly. Free browser-based tool — no upload, no sign-up required.
Ready to normalize
Paste text, choose a form, and click NormalizeEnter any Unicode text into the input box — accented characters, Asian scripts, emoji, or mixed content.
Choose NFC, NFD, NFKC, or NFKD depending on your use case. NFC is the most common for web and databases.
Click Normalize and copy the result. Toggle codepoints to inspect each character's Unicode value.
Unicode Normalization converts text into a standardized form so the same characters always have the same byte representation. This prevents silent bugs in string comparisons, database queries, and text processing where visually identical strings differ at the byte level.
Unicode normalization converts text into a consistent representation. The same visible character can be encoded in multiple ways — for example, "é" can be a single precomposed codepoint (U+00E9) or the letter "e" followed by a combining accent (U+0065 + U+0301). Normalization ensures one canonical byte sequence.
NFC (Canonical Decomposition + Canonical Composition) produces precomposed characters — "é" as one codepoint. NFD (Canonical Decomposition) decomposes into base character + combining marks — "e" + combining accent. Both are canonically equivalent; they differ only in byte representation.
NFKC and NFKD apply compatibility decomposition in addition to canonical decomposition. This folds visually similar but semantically different characters — for example, the ligature "fi" becomes "fi", or fullwidth Latin letters become standard ASCII. Use NFKC for search indexing and text matching where compatibility matters.
NFC is the recommended form for the web, HTML, and most databases. The W3C and most web standards specify NFC as the default. If you are storing user input or comparing strings, normalizing to NFC first prevents subtle bugs caused by different encodings of the same visible text.
For NFC and NFD, the rendered text looks identical — only the byte representation changes. For NFKC and NFKD, some compatibility characters may visually change: for instance, "①" (circled digit) may be mapped to "1", or fullwidth "Ａ" to "A". Always preview the output when using NFKC/NFKD.
No. All normalization happens in your browser via the JavaScript String.prototype.normalize() API. Your text never leaves your device. The tool is entirely client-side and works offline once loaded.
The codepoints table lists each character in the normalized output along with its Unicode codepoint (e.g. U+00E9) and decimal value. This is useful for debugging encoding issues, verifying which combining characters are present, or understanding how a string is structured at the Unicode level.
Yes. This tool handles the full Unicode character set including emoji, CJK (Chinese, Japanese, Korean) ideographs, Arabic, Hebrew, Thai, and all scripts supported by Unicode 15+. Emoji and most CJK characters are unaffected by NFC/NFD since they do not have combining forms, but NFKC/NFKD may affect compatibility ideographs.
A Unicode Normalizer converts text into one of the four standardized Unicode Normal Forms: NFC, NFD, NFKC, or NFKD. The Unicode Standard defines these forms to ensure that equivalent characters always have the same byte-level representation, which is essential for reliable string comparison, database storage, text search, and interoperability across systems.
The need for normalization arises because Unicode allows multiple binary representations for visually identical text. The accented character "é", for example, can be stored as the single precomposed codepoint U+00E9 (LATIN SMALL LETTER E WITH ACUTE) or as the two-codepoint sequence U+0065 (LATIN SMALL LETTER E) followed by U+0301 (COMBINING ACUTE ACCENT). Both render identically, but a byte-level string comparison will treat them as different strings — a source of silent, hard-to-debug bugs.
💡 Building multilingual web apps? MonsterONE offers unlimited downloads of web development assets — UI kits, templates, and more — worth checking out.
Unicode defines four normalization forms, each serving a different purpose:
Failing to normalize Unicode text is a common source of bugs in multilingual applications. Consider a user registration form that accepts usernames. If one user signs up as "José" (NFC, U+00E9) and another as "José" (NFD, U+0065 U+0301), a naive string comparison will treat them as different names — potentially allowing duplicate accounts that appear identical on screen.
Similar issues arise in:
The right normalization form depends on your use case. For most web development — HTML content, database storage, user-generated text — NFC is the correct choice and matches the W3C recommendation. NFC produces compact, precomposed output that most rendering engines and fonts handle optimally.
NFD is useful when you need to strip diacritics: decompose to NFD, then filter out characters in the Unicode "Mn" (Mark, Nonspacing) category, then optionally re-encode to ASCII. This is a common technique for generating URL slugs from accented text or building case-insensitive search indexes for Western languages.
NFKC is the right choice for search indexes, fuzzy matching, or any scenario where compatibility equivalents should be treated as identical. It is the normalization form used by Python's casefold() and recommended by the Unicode Consortium for identifier comparison (UAX #31).
NFKD is primarily used in NLP pipelines and tokenizers where the most granular decomposition is desired before further processing.
Most modern languages provide built-in normalization support. In JavaScript, str.normalize("NFC") (or "NFD", "NFKC", "NFKD") is available in all modern browsers and Node.js. In Python, the unicodedata.normalize(form, string) function handles all four forms. PHP provides the Normalizer class from the intl extension. Java offers java.text.Normalizer, and Swift uses String decomposition methods.
The best practice is to normalize input text to NFC as early as possible — ideally at the point of ingestion (form submission, API request, file import) — so that all downstream code can assume a consistent representation without needing to handle multiple forms.
A Unicode codepoint is an integer value in the range U+0000 to U+10FFFF assigned to a specific character or symbol. The codepoints table in this tool shows each character in the normalized output with its U+ notation and decimal value, making it easy to identify combining marks, variation selectors, zero-width characters, and other non-visible codepoints that might be present in your text.
Combining characters (Unicode category "M") are codepoints that attach to the preceding base character to form an accented or modified glyph. NFD and NFKD expose these as separate codepoints, while NFC and NFKC recombine them into precomposed forms wherever the Unicode standard defines a precomposed equivalent. Not all combining character sequences have a precomposed form — in those cases, NFC output may still contain combining marks.