How to normalize and inspect text
- Paste the text you want to check.
- Choose a normalization form: NFC (default), NFD, NFKC or NFKD.
- Compare the lengths before and after, check which forms the input is already in, read the code point table, and copy the normalized output.
Examples
Before
café
After
café
Before
Ñandú
After
Ñandú
Before
finance ①②③ Ｈｅｌｌｏ x²
After
finance 123 Hello x2
When to use it
- Find out why two strings that look identical fail an equality check.
- Fix file names copied from macOS, which are often stored in NFD.
- Check the UTF-8 byte length of a value before storing it in a column or field with a byte limit.
- Spot invisible characters such as zero-width spaces, joiners or byte order marks.
- Normalize data before deduplication, search indexing or enforcing unique keys in a database.
Understanding Unicode normalization
Many accented letters can be stored in two ways: as one precomposed code point, or as a base letter followed by a combining mark. In NFC, “café” is 4 code points; in NFD it is 5, because “é” becomes “e” plus U+0301. Both render the same, but string comparison, search, deduplication and database uniqueness checks see them as different. macOS file names and some apps produce NFD, which is a common cause of mismatches. NFC is the usual choice for storage and the web; Vietnamese text in particular is very often affected, because a single letter like “ệ” can be stored in several sequences.
NFKC and NFKD are compatibility forms. Besides composing or decomposing accents, they replace characters with a plain equivalent: “fi” becomes “fi”, “²” becomes “2”, full-width “Ａ” becomes “A” and “①” becomes “1”. This is useful for search and identifiers, but it can change meaning or appearance (x² becomes x2), so do not apply it to text you want to publish unchanged.
The tool shows four lengths for the input and the output. UTF-16 code units are what JavaScript’s length returns; code points are Unicode characters; grapheme clusters are what readers see as characters; UTF-8 bytes are what most files, APIs and databases store. For example, “é” is 2 UTF-8 bytes in NFC, and 👍🏽 is 1 grapheme, 2 code points, 4 code units and 8 bytes.
The table lists the first 500 code points of the input with the character, its U+XXXX code, its UTF-8 bytes in hex and a category: letter, combining mark, number, punctuation, symbol, whitespace, or control/format. Format characters such as U+200B (zero-width space) appear there even though they are invisible in the text.
Frequently asked questions
Which normalization form should I use?
Use NFC for storing and displaying text; it is the most common form on the web. Use NFD when you need to process accents separately. Use NFKC or NFKD only when you deliberately want compatibility characters folded into plain ones, for example for search keys.
Does normalization remove accents?
No. NFD separates accents from letters but keeps them. To remove accents, use the Remove Accents tool.
Why is the JavaScript length different from the number of characters I see?
JavaScript counts UTF-16 code units. Characters outside the Basic Multilingual Plane, such as most emoji, use two code units, and combined emoji or letters with combining marks use several code points for one visible character.
Will NFC fix every string comparison problem?
No. It makes equivalent sequences identical, but it does not remove zero-width characters, unify look-alike letters from different scripts, or change letter case. Use the code point table to find those differences.