SimpleWebUtils
ENKO
Back to All Tools

Unicode Normalizer | Compare NFC, NFD, NFKC and NFKD

EncodingRuns in Your Browser (No Uploads)

Normalize Unicode text to NFC, NFD, NFKC, or NFKD in a bounded browser Worker. Compare code points and UTF-8 bytes, detect compatibility folding, and review zero-width or replacement characters before export.

What to do next

Continue with a related workflow or open the next tool that usually follows this task.

Workflow guide

Recover garbled text from the original file bytes

Character-set detection narrows decoder candidates; it does not reverse already-corrupted text by itself. Preserve the source, identify where the wrong decode happened, compare controlled previews, and convert once only after known values round-trip correctly.

OpenRelated tool

Detect Text File Encoding from Byte Evidence

Inspect BOM, strict UTF-8, Unicode structure, ASCII compatibility, and binary clues from local file bytes.

OpenRelated tool

Diff Checker for Text, Code, and Unified Patches

Compare bounded text locally with exact line hunks, code-point highlights, and unified patch export.

OpenRelated tool

IDN Converter for Unicode and Punycode Domains

Convert one IDN between Unicode and Punycode with strict validation and label review.

Open

How to Use This Tool

Keep the original text and identify whether it is prose, a filename, an identifier, a signed value, or another field with an external format contract.

Paste text or select a local text file within the displayed UTF-8 byte and line limits.

Choose NFC or NFD for canonical normalization, or choose NFKC or NFKD only when compatibility folding is intended.

Run the bounded Worker and compare input and output code-point counts, UTF-8 byte counts, and the 64-value previews.

Treat a compatibility warning, remaining format characters, or U+FFFD replacement characters as a reason for deeper review.

Compare the exact result with the source, test it in the destination system, then copy or download the reviewed text.

When to Use This Tool

Equality and lookup debugging

Normalize a completed comparison key before testing values that render alike but use composed or decomposed code points.

Cross-platform filename review

Review filename normalization when text moves between macOS, Windows, Linux, archives, and version-control systems.

Multilingual data import

Inspect combining sequences and Hangul composition before importing multilingual labels into a system with a documented normalization contract.

Compatibility-aware search keys

Evaluate whether fullwidth forms, ligatures, circled numbers, or presentation variants may be folded for a restricted search key.

Invisible representation diagnostics

Compare exact code points and bytes when a visually identical value fails a test, cache key, route lookup, or deduplication rule.

Common Mistakes

Applying compatibility normalization to arbitrary text

NFKC and NFKD can fold circled numbers, width variants, ligatures, superscripts, and mathematical letters. Review the compatibility warning instead of treating the result as lossless cleanup.

Using normalization to repair mojibake

Normalization standardizes equivalent Unicode sequences. It does not recover bytes decoded with the wrong character set or reverse U+FFFD replacement characters.

Expecting zero-width characters to disappear

Zero-width and other format characters normally remain after normalization. Use the count and a dedicated inspector when hidden characters are the actual problem.

Treating normalization as a security filter

A normalized identifier can still contain confusable characters from different scripts. Normalization is not a spoofing, security, or authorization check.

Normalizing fragments before concatenation

Concatenating two normalized strings can create a sequence that is no longer normalized at their boundary. Normalize the completed value before comparison or storage.

Examples

Compose canonically equivalent text with NFC

NFC composes the decomposed acute accent and Hangul jamo while preserving line endings and canonical identity.

Input
Café
각
Output
Café
각

Inspect compatibility folding with NFKC

NFKC folds a mathematical letter, circled digit, ligature, and fullwidth letter. The visible warning marks this as more than canonical re-encoding.

Input
ℌ ① fi Ａ
Output
H 1 fi A

Canonical composition and compatibility-folding contract

NFD performs canonical decomposition. NFC performs that decomposition, canonically orders combining marks, and composes eligible sequences such as e plus acute accent or Hangul jamo.

NFKD performs compatibility decomposition, while NFKC adds canonical composition afterward. Compatibility mappings can erase distinctions in widths, presentation forms, ligatures, superscripts, circled values, and mathematical letters.

The engine marks canonical equivalence by comparing NFD forms. A changed NFKC or NFKD result that is not canonically equivalent receives a compatibility-folding warning.

Code-point inspection iterates Unicode scalar sequences rather than UTF-16 code units. It counts combining marks, format characters, and U+FFFD while limiting each visible preview to 64 values.

Normalization does not change CR, LF, ordinary zero-width format characters, or earlier decoding loss. Lone UTF-16 surrogates are rejected before TextEncoder or normalization can substitute data.

Input, line, output, and Worker deadlines bound processing. Only numeric metrics, the selected form, and boolean diagnostics enter analytics; text remains inside the browser workflow.

Frequently Asked Questions

What is the difference between NFC and NFD?

NFC performs canonical decomposition and then composition. NFD keeps the canonical decomposition. Both preserve canonical identity, though their code-point and byte sequences can differ.

Why are NFKC and NFKD marked as potentially lossy?

NFKC and NFKD additionally apply compatibility decompositions. They can merge distinctions such as ① and 1, fullwidth and ASCII letters, ligatures and separate letters, or mathematical and ordinary forms.

Should every database field use NFC?

NFC is commonly used for interoperable web text, but the correct choice depends on the system contract. Preserve a source copy and do not change identifiers, signatures, or protocol fields without checking their specification.

Does normalization remove zero-width characters?

No. Normalization does not remove U+200B and most other format characters. The result reports how many remain so you can inspect them separately.

Can normalization repair replacement characters or garbled text?

No. A U+FFFD replacement character usually means information was lost during an earlier decode. Re-read the original bytes with the correct character set when possible.

Why does the code-point preview stop after 64 values?

The preview lists at most 64 code points so a large result cannot expand the page. The full normalized text is still available in the output, copy action, and download.

What are the processing and privacy limits?

Input is limited to 1,048,576 UTF-8 bytes and 200,000 lines, output to 2,097,152 bytes, and the Worker to one second. Analytics receives counts, the selected form, and warnings, never source or output text.

How This Tool Was Verified

Maintained and tested by Reviewed

Method: The review loaded the unmodified “Normalize a multilingual lookup key without compatibility folding” sample into Unicode Normalizer. We exercised the path from “Preserve the original representation” to “Investigate every warning”, checked the displayed or downloaded result against the example, and separately examined “Using NFKC as universal cleanup” and “Assuming hidden characters are removed”.

Expected result: NFC produced “Café / 각” as canonically equivalent text, reported no compatibility fold, and left unrelated full-width or mathematical characters distinct.

Sources and standards

Open the tested workflow

Related workflow guides

Use these focused guides when you need a practical workflow before opening the tool.

Workflow guide

Recover garbled text from the original file bytes

Character-set detection narrows decoder candidates; it does not reverse already-corrupted text by itself. Preserve the source, identify where the wrong decode happened, compare controlled previews, and convert once only after known values round-trip correctly.

Workflow guide

Choose and verify a binary-to-text encoding for data handoffs

Use this workflow when an API, database field, DNS label, email body, configuration file, or legacy transport asks for Base32, Base58, Base62, Base85, hexadecimal, entities, Punycode, quoted-printable, UTF-16, or UUEncode but does not fully describe the variant.

Workflow guide

Convert an international domain to Punycode for DNS checks

Use this workflow when an internationalized hostname appears as readable Unicode in one place and xn-- ASCII labels in another, and you need a precise comparison without confusing conversion with registration or security approval.

Workflow guide

Audit text metrics before publishing or comparing drafts

Use this workflow when an editor, researcher, support team, or SEO review asks whether a draft repeats words, contains a target phrase too often, reads easily, sounds negative, or resembles another version. It records the unit, language, normalization, denominator, limits, and interpretation before analysis, then separates deterministic evidence from editorial judgment.

Workflow guide

Prepare reproducible text fixtures and decorative samples safely

Use this workflow when a test, mockup, terminal demo, documentation example, or harmless visual experiment needs generated or rearranged text. It separates structural operations from decoration, preserves source and separator behavior, records every seed and limit, and requires a plain-text alternative whenever FIGlet, mirror, upside-down, Braille-subset, or Zalgo output may not survive fonts, assistive technology, search, or copying.

Workflow guide

Normalize Unicode before comparing text across systems

A reliable Unicode-normalization workflow preserves the original representation, confirms the target system's contract, distinguishes canonical normalization from compatibility folding, inspects exact code points and hidden characters, compares the result, and validates the completed value where it will be stored or matched.

Workflow guide

Verify text limits across Unicode counting units

A reliable text-limit check starts from the destination contract, preserves the source representation, measures several Unicode units, includes normalization and invisible-character fixtures, exercises the limit on both sides, and verifies the value after storage or transmission.

Workflow guide

Inspect zero-width characters before removing them from text

Use this workflow when two values look identical but compare, search, wrap, parse, or render differently. Map supported controls before editing, distinguish common hidden separators from joining and line-break controls, retain exact line endings and normalization, and record why each removal was safe.

Related Tools

Continue with another maintained workflow

Detect Text File Encoding from Byte Evidence

Inspect BOM, strict UTF-8, Unicode structure, ASCII compatibility, and binary clues from local file bytes.

Encoding

Diff Checker for Text, Code, and Unified Patches

Compare bounded text locally with exact line hunks, code-point highlights, and unified patch export.

Text

IDN Converter for Unicode and Punycode Domains

Convert one IDN between Unicode and Punycode with strict validation and label review.

Encoding

Find and Replace Text | Literal and Regex Replacement

Replace literal or regex matches with Unicode boundaries, capture tokens, exact counts, and Worker limits.

Text

Inspect and Remove Zero-Width Characters Safely

Detect six zero-width controls, inspect their positions, and remove only approved types.

Text
Browse All Tools