Unicode Normalizer

Runs your text through all four Unicode normalization forms — NFC, NFD, NFKC and NFKD — using the browser's native String.prototype.normalize, shows every result side by side with its character and UTF-8 byte counts, and flags when your original input is not already in NFC.

What is the Unicode Normalizer?

Unicode often lets the same visible character be written more than one way. An é can be a single precomposed code point, or it can be a plain e followed by a separate combining acute-accent mark that a font renders on top of it. Both look identical on screen and both are completely valid Unicode, but they are different sequences of code points — which means they will not match in a simple string comparison. Normalization rewrites text into one of four standard, predictable forms so that equivalent strings become byte-for-byte identical again.

Key Features

• All four official Unicode normalization forms computed live: NFC, NFD, NFKC and NFKD
• Uses the browser's built-in, spec-compliant String.prototype.normalize — no custom re-implementation
• Character count and UTF-8 byte length shown under each form so length differences are visible at a glance
• A banner that flags when your raw input is not already NFC-normalized
• One-click copy for each of the four results independently

Common Use Cases

• Debugging why two strings that look identical fail an equality check or a search match in code
• Preparing user-submitted text — names, usernames, form fields — for consistent storage before it hits a database
• Understanding why a file, URL or filename copied from macOS behaves differently from the same text typed on Windows
• Checking whether copy-pasted text from a PDF or design tool carries decomposed accents that need cleaning up

How to Use the Unicode Normalizer

1. Paste or type text into the input box — the sample includes both a precomposed and a decomposed accented character.
2. Watch the banner above the grid report whether your raw text is already NFC-normalized.
3. Compare the four cards below: NFC, NFD, NFKC and NFKD, each showing the transformed text plus its character and byte counts.
4. Copy whichever form you need using the copy icon on its card.
5. For per-character code point inspection instead of whole-string normalization, use the Unicode Analyzer.

Tips for Best Results

• NFC is the safest general-purpose default for storing and comparing text, since it is the most compact reversible form.
• Reach for NFKC or NFKD only when you specifically want compatibility characters — ligatures, full-width forms, the single-glyph ½ — folded into their plain equivalents, since that step can alter appearance slightly.
• If two strings that look the same are not comparing as equal in your code, normalize both to the same form before comparing.
• Byte length differences between forms do not mean data corruption — they reflect that decomposed forms use more code points, and therefore more UTF-8 bytes, to represent the same visible characters.

Why Use WiserWork's Unicode Normalizer?

Most people only meet normalization when something quietly breaks — a duplicate-looking username gets created twice, or a search fails to find text that is clearly on the page. This tool makes the invisible difference visible: paste the suspect string in and see immediately whether it is already NFC, and what it looks like under all three alternative forms with exact byte counts. Everything runs through the browser's own normalization engine, so results match exactly what a JavaScript runtime, and most other modern languages, would produce.

Who Uses the Unicode Normalizer?

Developers debugging string comparison and deduplication bugs caused by mixed composed and decomposed text. Localization and internationalization engineers checking how user input behaves across operating systems. Anyone who has copy-pasted text from a PDF, macOS Finder or a design tool and noticed accents behaving oddly afterward.

Frequently Asked Questions

What is the difference between NFC and NFD?

NFC composes characters into the smallest possible number of code points, so an accented letter becomes one combined code point where a precomposed form exists. NFD decomposes the same text into a base letter followed by separate combining marks, which is why NFD strings are usually longer than NFC strings.

What does the K mean in NFKC and NFKD?

The K stands for compatibility. NFKC and NFKD apply everything NFC and NFD do, plus they also replace compatibility characters — like ligatures, full-width digits or the single-character fraction ½ — with their plainer equivalent sequences. That extra step can change the visual appearance slightly, which the C and D forms alone never do.

Why do two visually identical strings sometimes fail to match in code?

They can be built from different code point sequences that render the same way — one composed, one decomposed — while remaining unequal at the byte level. This is one of the most common sources of silent bugs in search, deduplication and username matching, and normalizing both sides to the same form before comparing fixes it.

Which form should I normalize to before storing user input?

NFC is the most common recommendation for storage and general text processing, since it keeps the shortest representation while staying reversible and not altering how characters look. Reach for NFKC only when you specifically want compatibility characters folded into a simpler form, such as before comparing search queries.

Does normalizing change how the text displays?

NFC and NFD alone should render identically, since they only change which code points represent the same visual characters. NFKC and NFKD can change the display slightly, because folding a compatibility character like a ligature or full-width digit into its plain equivalent may alter spacing or shape.

Why is the byte length different even when the character count looks the same?

Decomposed forms add extra combining-mark code points that composed forms fold into a single character, and in UTF-8 those code points each take their own bytes. Two strings that look and even count as the same number of visible characters can still differ noticeably in byte length depending on which normalization form produced them.

Is my input already normalized if this tool shows no warning?

The banner compares your raw input against its NFC form; if they match, most everyday text is already in a stable state. It does not mean the text can never contain a normalization-related surprise elsewhere, only that this specific comparison found no difference.

Two strings can look identical and still not be equal, and normalization is the fix. Paste your text, pick the form your system expects, and copy out a version guaranteed to compare cleanly.