Normalize equivalent Unicode sequences deliberately

Unicode Normalizer

Convert text to NFC, NFD, NFKC, or NFKD while reporting code-point changes, preserving the source for comparison, and documenting compatibility risks. Canonical forms can change encoding without changing appearance, while compatibility forms can intentionally fold distinctions such as width or presentation characters.

01Private by designYour text stays in this browser tab.
02Bounded and responsiveUp to 500,000 characters in each main text field.
03Ready to reuseCopy the result or download a branded TXT file.

No text upload to Nirmion

Counting and transformations run locally. Nirmion does not send the text in this workspace to an API.

01 / Input

Paste text and choose a Unicode normalization form

Use the exact text sequence whose storage, matching, indexing, import, or comparison behavior needs normalization. The source is bounded to 500,000 JavaScript string units and the operation uses the browser implementation of the selected Unicode normalization form.

Unicode textPaste up to 500,000 characters, including any combining or compatibility forms to inspect.0 / 500,000 charactersNormalization formChoose canonical composition or decomposition, with or without compatibility folding.

Complete the required fields to enable this action.

Runs in this tab without an API request.

Product guide

Choose canonical or compatibility normalization knowingly

Normalization is useful for consistent storage and comparison, but choosing NFKC or NFKD can erase distinctions that some identifiers, scholarly text, or typography needs. Review the complete result in its destination because automated text rules cannot infer every language, house style, data model, or publishing intention.

Step A

Prepare the input

Paste a representative sample containing accents, combining marks, width variants, ligatures, symbols, or imported text that behaves inconsistently.

Step B

Choose the rule

NFC composes canonical sequences, NFD decomposes them, NFKC composes after compatibility folding, and NFKD decomposes after compatibility folding.

Step C

Review the output

Compare code points and test the result in search, validation, signatures, identifiers, rendering, and downstream systems before changing stored production data.

How it works

Native Unicode normalization with explicit form selection

JavaScript String.normalize receives one of the four standardized forms. NFC and NFD apply canonical equivalence, while NFKC and NFKD also apply compatibility mappings. The tool counts Unicode code points before and after but does not transliterate, case-fold, trim, or remove invisible characters. The operation handles at most 500,000 input units and one million output units, and rejects any unlisted normalization form. The operation runs in this browser tab, applies explicit bounds before expensive work, and does not send workspace text to a Nirmion API.

Useful when

Make text comparison and storage more consistent

Use Unicode normalization when equivalent-looking sequences create a known technical problem and the chosen form matches the data contract.

Preflight imported names, search text, filenames, tags, or catalog values before a documented normalization pipeline.
Compare composed and decomposed accents that render alike but produce different code-point and byte sequences.
Test compatibility folding on width forms or ligatures before adopting it for indexing or validation.

Questions answered

Unicode Normalizer questions

Practical boundaries matter with text tools. These answers explain what is measured, what is retained, and when a manual review is still needed.

Which form should I use?

NFC is a common storage default, but the correct choice belongs to the receiving specification. Do not choose compatibility forms without understanding their folding behavior.

Does normalization remove accents?

No. NFD can separate a base letter and mark, but both remain. Use Accent Remover only when mark deletion is actually intended.

Can appearance stay the same?

Yes. Canonically equivalent sequences often render identically while code-point count and bytes change.

Privacy and retention

Your draft stays on your device.

Nirmion performs these operations with browser JavaScript. The workspace does not call the catalogue API with your source text, and completed-job content is kept only in this component memory for re-download.

A downloaded file remains in your browser downloads, device storage, backups, and any location where you share it. Clear or close the page when working on a shared device, and avoid pasting secrets into extensions or third-party clipboard managers.

Tool details

Four Unicode normalization forms with visible caveats

Nirmion Unicode Normalizer applies NFC, NFD, NFKC, or NFKD to text up to 500,000 characters and reports input and output code-point counts. It helps developers, editors, data teams, and localization workflows inspect equivalent-looking sequences before storage or comparison. JavaScript String.normalize receives one of the four standardized forms. NFC and NFD apply canonical equivalence, while NFKC and NFKD also apply compatibility mappings. The tool counts Unicode code points before and after but does not transliterate, case-fold, trim, or remove invisible characters. This makes the behavior inspectable and repeatable instead of presenting an unexplained result.

The result downloads as text_nirmion_tools_unicode_normalized.txt. The page distinguishes canonical composition from compatibility folding and warns about identifiers, signatures, hashes, byte offsets, width forms, ligatures, and symbols. The operation runs in this browser tab, applies explicit bounds before expensive work, and does not send workspace text to a Nirmion API. Downloading clears the active workspace while the latest three completed results remain available in this tab for re-download.