Find out which normalization form your text uses, then convert it. Handy when a filename, search or string comparison fails even though the text looks the same.
This tool runs entirely in your browser. What you enter is never sent anywhere.Your input is never sent anywhere.
DetailsCurrent state of your text
Combining marks (accents, diacritics)
None found
Compatibility characters
None found
Convert to
Already in NFC (no change)
See the diff below for the exact changes
Your result appears here
Diff
No changes
TIP
If a filename or string looks right but will not match, the cause is often an accent stored as a separate character. Converting to NFC fixes that without changing anything else. Use NFKC only if you also want ligatures and full-width letters replaced.
What Unicode normalization does to text that looks identical
The letter é can be stored in two ways. One is a single code point, U+00E9. The other is a plain e (U+0065) followed by a combining acute accent (U+0301). Both display as é, but to a program they are two different strings.
That difference breaks string equality checks, database unique constraints, search matches and filenames that travel between operating systems. Normalization rewrites text into one consistent form so that visually identical text is also identical in code.
This tool tells you which of NFC, NFD, NFKC and NFKD your text already matches, converts it to the form you pick, and highlights what changed. It runs the browser's built-in String.prototype.normalize(), so nothing leaves your device.
When two identical-looking strings don't match
Filenames that differ between Mac and other systems
A file copied from a Mac arrives with an accent stored as a separate character, so searches, scripts or sync tools treat it as a different name. Check the names and convert them to NFC.
Debugging a failed string comparison
If a === b is false for text that looks the same, paste both values here. The Current state panel shows which form each one uses and how many combining marks it contains.
Cleaning text pasted from PDFs, Word and web pages
Copied text can contain ligatures like fi, non-breaking spaces, superscripts or full-width characters. NFKC converts them to plain characters so the text is easier to search and match.
Checking a list of names before an import
Paste a column of filenames, usernames or product names in List mode to see which lines change and which would collapse into the same value after normalization.
How to check and convert your text
- Paste your text into the input box, or click one of the example buttons.
- Read the Current state panel. It shows which forms your text already matches, plus the number of combining marks and compatibility characters found.
- Choose NFC, NFD, NFKC or NFKD. If you are not sure, start with NFC.
- Check the diff and the code points, then copy the result or download it as a .txt file. For many filenames, switch on List mode first.
Note: All processing happens in your browser with String.prototype.normalize(). Your text is not sent to a server.
Limits and things to watch for
- NFKC and NFKD discard some distinctions: x² becomes x2, fi becomes fi and full-width letters become regular letters. Use NFC if you only want to fix accents.
- Normalization does not change letter case, remove invisible characters such as zero-width spaces, or strip accents. It only rewrites characters into an equivalent form.
- The diff compares code points and is skipped for text longer than 400 characters. The converted text is still shown and can be copied.
- In List mode each line is normalized separately, both \n and \r\n line breaks are accepted, and blank lines are dropped from the copied and downloaded result.
- Combining marks have no width of their own, so in the diff they are shown after a dotted circle (◌) to keep them visible.
NFC vs NFD vs NFKC vs NFKD: what each form does
The four forms differ in two ways: composed or decomposed, and whether compatibility characters are replaced.
| Form | What it does | Typical use |
|---|---|---|
| NFC | Decomposes canonically, then recomposes: e + ́ becomes é | Default for stored text, filenames and data exchange |
| NFD | Splits characters into base letter + combining marks: é becomes e + ́ | Intermediate step, for example before removing accents |
| NFKC | Like NFC, and also replaces compatibility characters: fi → fi, ² → 2, Ａ → A | Loose matching: search indexes, usernames, duplicate detection |
| NFKD | Like NFD, and also replaces compatibility characters | Pre-processing for accent-insensitive search |
If you are unsure, use NFC. Choose NFKC only when you want to merge look-alike characters and can accept losing the original formatting.
Which form to use for filenames, databases and search
A quick guide to picking a form for the most common jobs.
Filenames and shared folders: NFC
Windows and Linux software mostly produces NFC, and Windows does not normalize filenames. The older macOS file system, HFS+, stores names in a form close to NFD, and APFS keeps the form it receives. Converting names to NFC before you zip, upload or sync them keeps one name per file.
Databases and user input: normalize on the way in
If "José" can be typed as precomposed or decomposed text, a unique constraint may accept both as separate values. Normalizing to NFC before saving, and normalizing search queries the same way, keeps lookups consistent.
Search and de-duplication: NFKC
NFKC folds ligatures, full-width letters, superscripts and non-breaking spaces into plain characters, which makes loose matching more reliable. It is a one-way cleanup, so keep the original text if you need to display it as typed.
Removing accents: start from NFD
Accent stripping works by converting to NFD, which separates the base letter from the accent, and then deleting the combining marks. This tool shows you the decomposed result and its code points, but it does not delete the marks for you.
Common problems caused by mixed normalization forms
The same file shows up twice after a sync or upload
One copy of Résumé.pdf was saved with é as one code point and another with e plus a combining accent. They look identical in a folder listing but are different names.
💡 See the solution▼
A lookup or equality check returns false for matching text
You compare a typed value with a stored one, and the visible text matches but the code points do not.
💡 See the solution▼
A search for café does not find café
The index contains decomposed text, and the query is typed in precomposed form, or the other way around.
💡 See the solution▼
NFKC changed more than you wanted
After converting, x² became x2 and ™ became TM, which changes the meaning of a formula or a product name.
💡 See the solution▼
Frequently asked questions about normalization forms
Q.What is the difference between NFC, NFD, NFKC and NFKD?
A. NFC and NFD only change how a character is built. NFC merges a base letter and its combining accent into one code point (e + ́ becomes é), and NFD splits it back apart. NFKC and NFKD do the same and also replace "compatibility" characters with plain equivalents, such as the ligature fi with fi, a superscript ² with 2, and full-width Ａ with A.
Q.Why does a string that looks identical fail an equality check?
A. The two strings probably use different code points for the same visible text. In JavaScript, "caf\u00e9" === "cafe\u0301" is false even though both display as café. Normalizing both sides to the same form (usually NFC) before comparing fixes it. Paste both strings here and the Current state panel shows which form each one is in.
Q.Why do filenames look the same on a Mac and a PC but behave like different files?
A. The older macOS file system, HFS+, stores filenames in a form close to NFD, while Windows and Linux software usually produce NFC. APFS keeps whatever form it was given, and Windows does not normalize names. A name like Résumé.pdf can therefore reach another system as e + accent instead of é. Normalizing the names to NFC before you copy, zip or upload them avoids mismatches.
Q.Which normalization form should I use?
A. NFC is the usual choice for stored text, filenames and data you exchange between systems. Use NFKC when you want to match text loosely, for example when building a search index or comparing usernames, and you accept that formatting differences like ligatures and full-width letters will be lost. NFD and NFKD are mostly used as an intermediate step, for instance before stripping accents.
Q.Does NFKC change the meaning of my text?
A. It can. NFKC and NFKD replace compatibility characters, so x² becomes x2, ① becomes 1, and ™ becomes TM. Full-width letters become regular letters, and non-breaking spaces become normal spaces. That is helpful for matching and cleanup, but it can change the meaning of formulas or formatted text, so use NFC if you only want to fix accents.
Q.Can I check a list of filenames at once?
A. Yes. Turn on List mode and paste one name per line. Each line is normalized on its own and labeled Changed or Unchanged. The tool also warns you when two different lines would end up identical after normalization, which is how duplicate filenames usually show up.
Q.Is my text uploaded anywhere?
A. No. The tool calls the browser's built-in String.prototype.normalize() on your device. Your text and filenames are not sent to a server.
Your feedback
makes this tool better.
Tell us which features you'd like, what should be fixed, or which new tool you'd like to see. An engineer reads every submission and uses it to guide development.