What is the difference between NFC and NFD?

Both are canonical and reversible, but NFC composes while NFD decomposes. NFC packs a base letter and its accent into one code point where a single character exists, so é is U+00E9, one code point and two UTF-8 bytes. NFD splits the same é into e (U+0065) plus a combining acute (U+0301), two code points and three bytes. They render identically and mean the same thing, so for storage and comparison pick NFC, the web default; for stripping accents or sorting, NFD is handier.

Why does é have two different representations?

Unicode kept precomposed characters like é (U+00E9) for round-trip compatibility with older charsets, but also lets you build the same glyph from a base e plus a combining acute accent (U+0301). Both are valid and look the same on screen, yet a byte comparison says they differ. That is exactly why a copied filename or a pasted name sometimes fails an equality check that should pass. Normalizing both sides to NFC first makes them match.

What does NFKC actually do?

NFKC is NFC plus compatibility folding, which flattens formatting-only variants to their plain form. Fullwidth ＡＢＣ collapses to ASCII ABC, the circled ① becomes the digit 1, the ﬁ ligature becomes the two letters fi, and superscripts and many symbol variants reduce to their base. It is lossy on purpose: you trade exact appearance for a single searchable shape, which is why search engines and username checks normalize to NFKC before comparing.

Why should search and dedupe normalize text first?

If one record stores José as NFC and another stores it as NFD, a plain string equality test treats them as different people and your dedupe misses the duplicate. Normalizing every value to the same form (usually NFC, or NFKC when fullwidth and ligature variants must also match) before you index or compare guarantees that visually identical text compares equal. Do it once on input, not on every read.

Does normalization affect Korean Hangul and CJK?

Korean yes, Chinese mostly no. A Hangul syllable like 한 is one precomposed code point under NFC, but NFD decomposes it into its jamo components (ㅎ, ㅏ, ㄴ), which matters for search and for some fonts. Chinese and Japanese ideographs have no canonical decomposition, so 中文 is unchanged by NFC and NFD; however NFKC still folds fullwidth Latin and width-variant kana, so it touches mixed CJK text that contains those.

Is my text uploaded anywhere?

No. Normalization runs entirely in your browser through the standard String.prototype.normalize call, so the text never leaves the page and nothing is logged. The only thing to watch is the share link, which encodes your input and chosen form into the URL query string; a link pasted into chat will record that text in the recipient server's access log. For anything private, use the copy button instead of sharing the URL.

Fix a search that misses accented names

Your app stores José typed on a Mac (often NFD: e plus combining accent) but the search box sends José from a Windows keyboard (NFC, one code point). The query never matches and the user swears the record is there. Paste both strings here, normalize each to NFC, and watch the code-point counts line up. Then normalize on input in your code so the mismatch can never happen again.

Dedupe a contact or product list

A CSV merged from two sources holds Café and Café that look identical but compare as different rows, so your dedupe leaves both. Run the column through NFC (or NFKC if fullwidth or ligature variants also appear) and the visually equal entries become byte-equal, collapsing into one. The byte-count delta shown here tells you at a glance which rows were actually decomposed.

Clean fullwidth and ligature noise before indexing

User-submitted text arrives with fullwidth ＡＢＣ, circled ①②③, and ﬁ ﬂ ligatures pasted from PDFs. None of that should change what a search matches. NFKC folds all of it to plain ABC, 123, fi fl in one pass, so your search index and your equality checks see the same characters a human reads, not the formatting variant underneath.

Teach or debug Unicode equivalence

Explaining why "é === é" is false in JavaScript lands better when the class can see it. Type the precomposed é, switch to NFD, and the code-point count jumps from 1 to 2 while the glyph stays the same. Toggle the per-character view to point at the combining acute U+0301 that appeared. Share the URL and the example reopens exactly as built.

Unicode Normalizer (NFC NFD NFKC NFKD)

Normalize text to NFC, NFD, NFKC or NFKD, see code-point and byte counts shift, spot which characters changed, copy in one click, all in your browser

Runs locally
Category Text
Best for Removing repetitive cleanup work from everyday writing and operations.

Text to normalize

Form

Canonical Composition — combine marks into single code points where one exists (é stays one character). The web default; use this for storage and comparison.

code pointsInput0→Output0(change 0)

UTF-8 bytesInput0→Output0(change 0)

Normalized output

Normalized text and its code points appear here.

What this tool does

Free online Unicode normalizer that converts any text into NFC, NFD, NFKC or NFKD using your browser's built-in normalize() engine. The same visible letter can be stored two ways: é can be one code point (U+00E9) or two (e plus a combining acute U+0301). They look identical but are not equal as strings, so search, dedupe and database keys silently miss matches. This tool collapses both into one canonical shape and shows the code-point count and the UTF-8 byte count before and after, so you can watch combining marks merge under NFC or split under NFD. NFC and NFD are canonical and reversible, while NFKC and NFKD add compatibility folding: fullwidth ＡＢＣ becomes ABC, circled ① becomes 1, the ﬁ ligature becomes fi. An optional per-character view lists every code point and highlights the ones that changed. Everything runs client-side, with one-click copy and a shareable URL that reopens your exact text and form. No upload.

Tool details

Input: Text; The page exposes text boxes, numeric controls, file pickers, or structured inputs depending on the tool.
Output: Live result + Copy; The result area focuses on usable output, with copy, download, or preview actions when supported.
Privacy: Browser-side processing; The main tool logic does not call an external API, so inputs normally stay in the current tab.
Save / share: Shareable URL state; Key settings are encoded in the URL so another person can reopen the same setup.
Performance budget: Initial JS <= 9 KB; No WASM budget is declared, keeping the tool quick to open on mobile.
Best fit: Text · Developer; Category and role tags drive related tools, internal links, and quick fit checks.

How to use

1. Input

Paste or drop your content into the tool panel.
2. Process

Click the button. All processing is local in your browser.
3. Copy / Download

Copy the result or download to disk in one click.

How Unicode Normalizer fits into your work

Use it to clean, compare, reshape, or extract plain text before it goes into a document, CMS, spreadsheet, or prompt.

Text jobs

Removing repetitive cleanup work from everyday writing and operations.
Making text easier to compare, paste, publish, or feed into another tool.
Working with content locally when the text is private or unfinished.

Text checks

Scan for unintended whitespace, duplicate lines, and lost punctuation.
For long text, test the first few lines before applying the whole change.
Copy the final output only after checking the preview.

Good next steps

These links move the current task into a more complete workflow.

Real-world use cases

Fix a search that misses accented names
Your app stores José typed on a Mac (often NFD: e plus combining accent) but the search box sends José from a Windows keyboard (NFC, one code point). The query never matches and the user swears the record is there. Paste both strings here, normalize each to NFC, and watch the code-point counts line up. Then normalize on input in your code so the mismatch can never happen again.
Dedupe a contact or product list
A CSV merged from two sources holds Café and Café that look identical but compare as different rows, so your dedupe leaves both. Run the column through NFC (or NFKC if fullwidth or ligature variants also appear) and the visually equal entries become byte-equal, collapsing into one. The byte-count delta shown here tells you at a glance which rows were actually decomposed.
Clean fullwidth and ligature noise before indexing
User-submitted text arrives with fullwidth ＡＢＣ, circled ①②③, and ﬁ ﬂ ligatures pasted from PDFs. None of that should change what a search matches. NFKC folds all of it to plain ABC, 123, fi fl in one pass, so your search index and your equality checks see the same characters a human reads, not the formatting variant underneath.
Teach or debug Unicode equivalence
Explaining why "é === é" is false in JavaScript lands better when the class can see it. Type the precomposed é, switch to NFD, and the code-point count jumps from 1 to 2 while the glyph stays the same. Toggle the per-character view to point at the combining acute U+0301 that appeared. Share the URL and the example reopens exactly as built.

Common pitfalls

Comparing strings without normalizing first. Two visually identical names can be one NFC code point versus a base letter plus a combining mark, so a plain equality test returns false. Normalize both sides to the same form before any compare, index or dedupe.
Reaching for NFKC when you only need NFC. NFKC is lossy because it folds fullwidth, ligatures and circled digits away for good. If you must preserve exact appearance (display text, a stored original), use NFC, which is reversible, and keep NFKC for the search key only.
Assuming CJK is untouched. Chinese ideographs have no canonical decomposition, but NFKC still folds fullwidth Latin and half-width kana inside mixed text, so a string that looks all-Chinese can still change. Check the byte-count delta before assuming nothing happened.

Privacy

Normalization runs entirely in your browser tab through the standard String.prototype.normalize call, so your text is never uploaded and nothing is logged. The one caveat: the shareable link encodes your input and the chosen form into the URL query string, so a link pasted into chat will record that text in the recipient server's access log. For anything private, use the copy button and paste the result rather than sharing the URL.

FAQ

Tool combos

Folks in your role tend to reach for these alongside this tool.

Developer

Browse all tools for this role

Unicode Normalizer (NFC NFD NFKC NFKD)

What this tool does

Tool details

How to use

1. Input

2. Process

3. Copy / Download

How Unicode Normalizer fits into your work

Text jobs

Text checks

Good next steps

Real-world use cases

Fix a search that misses accented names

Dedupe a contact or product list

Clean fullwidth and ligature noise before indexing

Teach or debug Unicode equivalence

Common pitfalls

Privacy

FAQ

Unicode Character Inspector

Text to Hex Converter

Traditional ⇄ Simplified Chinese Converter

Find and Replace Text

A1Z26 Cipher (Letter ⇄ Number)

Chinese Acupoint Locator

Add Line Numbers

Aesthetic Text Generator

AI Eval Planner

AI Model Comparison

AI Token Counter

Anagram Solver