Unicode inspector

Inspect the original Unicode code points and grapheme clusters, and apply explicit normalization to a separate text result.

Processing is local with no automatic storage. Worker deadline: 5 seconds; complete result including details: 2 MiB. Preview is bounded; copy and download are complete.

Up to 4,096 UTF-16 units. Tables describe the original with zero-based indexes; result text applies only the selected normalization. NFKC/NFKD can change character forms and meaning. We identify specified directional controls, not sanitize text or provide a full Unicode-name database.

How to use

Paste text, choose a normalization policy and process. Inspect the original code points, clusters and flagged direction controls. Review the resulting text before copying or downloading; copy and download use that text, not the inspection table.

Try an example

The letter e followed by U+0301 consists of two Unicode code points and one grapheme cluster. NFC produces é at U+00E9; the original-input report still shows the two code points you entered.

Support & limits

Code points and grapheme clusters are not UTF-16 units or pixel widths. Inspection records describe the original input; copied or downloaded text follows the selected normalization, while none retains the text. Direction flags cover ALM, LRM, RLM, LRE, RLE, PDF, LRO, RLO, LRI, RLI, FSI, PDI only, not a complete Unicode name database or every character’s direction. NFKC/NFKD can change compatibility distinctions such as character forms; they are not language correction.

Common questions

Does flagging hidden characters sanitize the text or make it safe?

No. Inspection displays information; it does not remove all hidden characters or detect every confusable or visual spoof. Normalization is a defined Unicode transformation, not sanitization or a security audit.

Related tools