Unicode Normalizer
Normalize Unicode locally with code-point comparisons and clear NFC, NFD, NFKC and NFKD choices.
This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.
Normalize text to NFC, NFD, NFKC or NFKD locally, with code-point comparison and compatibility warnings.
How to use it
- 1Paste text or load the original UTF-8 text file.
- 2Choose the intended normalization form; review the warning for compatibility forms.
- 3Compare the result, then copy or download the complete normalized text.
Example
- Input
- Café
- Output
- Café
With NFC selected, the e plus U+0301 combining acute accent becomes é.
What happens to your data
Text is processed in browser memory without source upload or storage. File BOM and original line endings are retained on download; pasted text can already have browser-normalized endings. Runtime Unicode support depends on your browser.
Last updated October 2026
Two words can look identical but contain different Unicode sequences. An accented character may be one precomposed code point or a letter followed by a combining mark. Exact comparisons, search indexes and data joins can therefore disagree even when the screen looks right. The Unicode Normalizer makes one of four normalization forms explicit and shows the original and generated code points before you keep the result.
Choose NFC for canonical composition, NFD for canonical decomposition, or deliberately select the compatibility forms NFKC and NFKD. Nothing is silently called an error just because it is not NFC. The correct form depends on the receiving application and the meaning of the text. This is a focused representation repair, not translation, spelling correction, accent removal or a security verdict about look-alike characters.
How it works
Paste text or load one valid UTF-8 file, choose the form and press Normalize text. The result reports whether any text changed, the before/after code-point and UTF-8 byte counts, and which forms already matched the original. The first 24 code points from each version are listed separately. These lists expose a combining sequence without implying a character-by-character alignment: decomposition can turn one point into several. A code point is not the same as a visible letter or grapheme.
NFC and NFD use canonical equivalence. For example, Cafe followed by U+0301 becomes Café under NFC; NFD can represent the accented letter as e plus the combining mark. NFKC and NFKD also apply compatibility mappings. A circled digit, full-width Latin letter or ligature can become ordinary text. That may help a deliberately defined matching key, but it can also remove a distinction important in mathematics, typography or an identifier. Compatibility forms show a visible warning and are never the default. Keep an original copy when those distinctions matter.
The operation uses the browser's String.normalize implementation. Its supported Unicode version depends on the browser; the page does not certify conformance to a particular latest Unicode release. The current Unicode normalization annex explains the forms and stability rules, while the actual output here follows your runtime. Unicode normalization does not generally make different scripts identical or detect spoofing. It also does not remove every invisible character, strip accents, change case, validate a username or repair mojibake caused by the wrong file encoding.
Input is limited to 1 MiB of UTF-8 and output to 4 MiB. Empty text is a valid no-change case. An original file is decoded strictly: malformed UTF-8, UTF-16/32 BOMs, NUL and selected non-text controls are refused instead of replaced or guessed. A leading UTF-8 file BOM is kept separately and restored on the download. Other accepted text, including line endings, is retained except for changes required by the chosen normalization form. Pasted text has already passed through a browser text box, which can normalize its line endings.
Loaded files remain separate from the read-only source preview so preview rendering cannot change their contents. The text preview shows at most 12,000 characters; copy and download include the complete result. Clipboard behavior is not an exact-byte archive, so use the UTF-8 download when line endings and the file BOM matter. Editing the text, replacing the file or changing the form removes the previous export. A delayed file read cannot replace a newer input.
Text processing stays in browser memory without uploading or persisting the source. Page assets and anonymous usage events can use the network, but the widget does not place your text in those events or the address. A downloaded copy can still be sensitive. Check the result in the application whose matching behavior you are trying to repair.
Worked example: Compose an accent without folding compatibility characters
- Input
- Café · ① · Ａ · fi
- Result
- Café · ① · Ａ · fi
With NFC selected, the input's e plus U+0301 combining acute accent becomes é. NFKC deliberately produces Café · 1 · A · fi instead.
Common use cases
- Make canonically equivalent names consistent before an exact-text comparison
- Inspect whether an accented letter is precomposed or a combining sequence
- Prepare a deliberately compatibility-folded search key while retaining the source
- Compare normalization forms before changing an integration's text handling
Frequently asked questions
Which Unicode normalization form should I use?＋
NFC is the default canonical-composition option, not a universal requirement. Follow the receiving format or application's rules. Use NFKC/NFKD only when removing compatibility distinctions is an intended part of the job.
Why can the code-point count change without a visible difference?＋
One precomposed character can correspond to a base character and combining marks. The displayed word may look the same while the stored sequence and byte count differ. The code-point preview makes that representation visible.
Does Unicode normalization remove accents or invisible characters?＋
No. NFD decomposes many accented characters but retains their combining marks. No general mark-stripping or invisible-character removal is applied. This is different from an accent-removal tool.
Is NFKC reversible or safe for every identifier?＋
No. Compatibility folding can erase distinctions such as a circled digit or superscript. Review the receiving system's policy and keep the original. This tool is not an identifier-security or confusable-character checker.
Does this fix text such as Café?＋
Not reliably. That usually reflects an incorrect encoding interpretation rather than a normalization form. Work from the original bytes and the correct known encoding; do not use normalization as an encoding guess.
Will my file's line endings or BOM change?＋
The download restores a detected leading UTF-8 file BOM and retains original CR/LF text through normalization. Pasted text can already have LF-normalized endings. Use the original file input for byte-sensitive work, and check the actual download.
Why does the page not promise the latest Unicode version?＋
The browser provides the normalization implementation. Browser versions can support different Unicode data. This page explains the forms but does not bundle or certify a specific Unicode-version implementation.
Related tools
Text Encoding Converter
Decode supported text encodings and save UTF-8 or UTF-16 with strict byte checks and BOM options.
Unicode Escape/Unescape
Turn text into \uXXXX sequences and back; by default only non-ASCII goes, or tick Escape everything.
Text Diff Checker
Compare two texts side by side. Highlight character, word, or line changes and download a private diff.
JSON String Escape
Escape text to one JSON string or strictly decode it, preserving embedded text and numeric IDs.