Unicode Inspector

STEP 01

Choose the unit your system actually limits

A visible symbol, a Unicode code point, a JavaScript string unit, and a stored byte are different measurements. A quota expressed only as characters is ambiguous. Before shortening a form submission, check the platform documentation or a real boundary test to learn which unit the field enforces. A word counter alone cannot explain a byte-limited rejection.

This inspector reports code points by iterating the string, UTF-16 units from JavaScript string length, and UTF-8 bytes through TextEncoder. Grapheme clusters are measured with the browser's Intl.Segmenter when available. If segmentation is unavailable, the display says unavailable rather than relabeling code points as user-perceived characters. Segmentation can vary with the Unicode data shipped in a browser.

STEP 02

Compare a composed letter with a combining sequence

Type e followed by the combining acute accent U+0301. It commonly renders as one accented letter but contains two code points. In UTF-16 it occupies two units; its UTF-8 encoding uses three bytes. NFC can turn this example into the composed letter é, with one code point and two UTF-8 bytes. The inspector's table makes that difference visible without requiring you to guess from the font.

An ordinary grinning-face emoji provides a different example: one code point, two UTF-16 units, and four UTF-8 bytes. A family emoji can contain several emoji points connected by zero-width joiners while appearing as one grapheme. These examples explain why deleting an arbitrary string unit may cut a symbol in half. Work with the unit relevant to your task instead of treating all counts as interchangeable.

e + U+0301 (combining acute accent)

Original: 2 code points · 2 UTF-16 units · 3 UTF-8 bytes
NFC: é · 1 code point · 2 UTF-8 bytes

STEP 03

Find invisible text without deleting meaningful marks

If two labels refuse to compare equal, paste a short representative sample and inspect the code-point table. A normal space and a no-break space can look alike. A zero-width space can remain after copying a web heading. The table labels selected spaces, joiners, direction controls, and combining marks; it is not a complete Unicode name database. Offsets are zero-based UTF-16 positions, matching JavaScript indexing.

An invisible character is not automatically an error. Joiners can shape script or emoji sequences, and directional marks can be important in mixed right-to-left and left-to-right text. Removing all format characters can damage names or change display order. Establish where a mark came from, compare a known-good sample, and keep the original available before applying any cleanup.

STEP 04

Make normalization an explicit data decision

Use the normalization comparison to see whether a form changes the actual sequence, then copy only the selected result. NFC and NFD handle canonical equivalence; NFKC and NFKD additionally use compatibility mappings. The latter may replace distinctions such as full-width forms. The original input is never rewritten by the inspector, and selecting a result does not mean that it is appropriate for a password, legal record, or identifier.

Agree on normalization with the system that stores and compares the data. Normalization is not transliteration, a confusable-character detector, or a guarantee that look-alike labels are safe. Keep authoritative IDs unchanged unless their specification permits transformation. TextEncoder replaces lone surrogate units with replacement-character encoding, so its byte count describes browser encoding behavior, not a repair of malformed text. For an audit, retain the original and record the chosen form.

COMMON QUESTIONS

Before you use the result