Unicode Normalizer

Input

10 graphemes11 code points14 bytes

Normalization form

Live result

Café and ①

Changed: Yes
Code points: 10
Bytes: 13

Good fit

Use this tool when

Visually identical strings fail equality checks.
Accents arrive in mixed composed and decomposed forms.
You need to test compatibility folding before validation.

Keep the original

Avoid it when

You have not reviewed the effect of NFKC or NFKD.
The original code-point sequence must be preserved.
Normalization is being treated as a complete security sanitizer.

Reviewed truth vectors

Examples that expose the edge cases

Inpute + ◌́

Outputé (NFC)

Canonical composition combines the sequence.

Inputé

Outpute + ◌́ (NFD)

Canonical decomposition separates base and mark.

Input①

Output1 (NFKC)

Compatibility normalization changes the circled digit.

Transparent implementation

How it works

01
Call the standards-based JavaScript normalize method with the selected form.
02
Compare output code points and counts with the original.
03
Warn whenever a compatibility form changes the source.

Known limitations

What the result cannot promise

Normalization does not remove all invisible or dangerous controls.

It does not make mixed-script identifiers safe.

Runtime Unicode support depends on the deployed JavaScript engine.

Questions before copying

Frequently asked questions

Which form should I use by default?

NFC is a common storage and interchange default, but the correct choice depends on your system and matching rules.

Can normalization change appearance?

Compatibility forms can. Canonical forms should be canonically equivalent, though fonts and tooling may still expose differences.

Is NFKC a security sanitizer?

No. It can reduce some compatibility differences, but mixed scripts, bidi controls, and confusables need separate checks.

Experience, expertise & trust

How we verify this tool

GlyphSift Editorial — Text-engine authors & reviewers

The GlyphSift Editorial team designs the deterministic text engine, writes each tool's examples against real Unicode edge cases, and reviews every claim before a page becomes eligible for indexing. We build and test the software we document; we do not outsource the copy to generic content mills.

Each tool page is reviewed against the same six input classes the engine is tested with — ASCII, emoji, combining marks, non-Latin scripts, empty input, and 5,000-grapheme input — and cannot become eligible if it is only a parameter variation of another page.

Automated evidence

Tool-contract & coverage suite30 deterministic cases
tests/tools-30.test.mjs mirrors the ToolRunner dispatch and asserts every registered engineId returns the contracted output shape, plus a coverage guard so no tool silently drops characters.
Run in: node --test after a production build (vinext build)
Rendered-HTML suite12 deterministic cases
tests/rendered-html.test.mjs renders the deployed server bundle and asserts the Unicode-version manifest and each wave's tool markup are present in the server-rendered HTML.
Run in: node --test against the built dist/server bundle
Unicode inspection suite11 deterministic cases
tests/unicode-inspection.test.mjs verifies grapheme/code-point/byte counting and hidden-control detection using explicit \u escapes for combining and bidirectional characters.
Run in: node --test against the runtime's Unicode data
Compatibility risk suite13 deterministic cases
tests/compatibility.test.mjs checks that bidirectional controls, invisible characters, mixed scripts, and NFKC-changing input raise the documented risk status, and that safe-text stripping preserves ordinary content.
Run in: node --test, deterministic analyzer

Standards this tool follows

UTS #39: Unicode Security Mechanisms
Confusable and mixed-script detection methodology.
UAX #9: Unicode Bidirectional Algorithm
Bidirectional control characters flagged during inspection.
UAX #15: Unicode Normalization Forms
NFC/NFKC normalization comparisons.
RFC 3629: UTF-8
Byte-length counting for the UTF-8 encoding.