Unicode Inspector

Text is more complicated than it looks. The string `café` could be four codepoints (U+0063 U+0061 U+0066 U+00E9) or five (U+0063 U+0061 U+0066 U+0065 U+0301 — where the last is a combining acute accent over a separate 'e'). Both render identically on screen. They compare unequal under `===` in JavaScript. They produce different bytes when serialized. They fail database UNIQUE constraints differently. The user can't tell which they have until something breaks; the Unicode Inspector is what you use to find out.

The tool's primary job is to surface **invisible characters** — codepoints that take up zero or near-zero visual space but exist in the text and affect everything downstream of rendering. The greatest hits:

- **U+200B ZERO WIDTH SPACE** — a word boundary that's invisible. Sneaks into pasted content from rich-text editors. Breaks regex like `/^\w+$/` because the word boundary is real but the input visually looks like one word. - **U+200C ZERO WIDTH NON-JOINER** and **U+200D ZERO WIDTH JOINER** — used legitimately in scripts that need ligature control (Arabic, Persian, Devanagari) and in emoji ZWJ sequences (👨‍👩‍👧). Cause bugs when they leak into Latin text. - **U+FEFF BYTE ORDER MARK** — the BOM. Legitimately marks UTF-16 byte order; illegitimately appears at the start of UTF-8 files where it's just an invisible character that breaks things expecting bytes to start with the actual content. - **U+00AD SOFT HYPHEN** — invisible until line-wrap, then it might appear as a hyphen. Sneaks in from word processors. - **U+200E LEFT-TO-RIGHT MARK** and **U+200F RIGHT-TO-LEFT MARK** — directional control. Legitimate in mixed-script text; bugs in mono-script text. - **U+202E RIGHT-TO-LEFT OVERRIDE** — the "trojan source" character that's been weaponized to make malicious code look benign. Source files with U+202E render text after it in reverse, which can hide the true behavior of a function. - **U+00A0 NO-BREAK SPACE** — looks like a space but doesn't break lines. Comes from rich-text paste. Breaks `/\s+/` if the regex doesn't include it.

When any of these are in the input, the stats row shows a yellow warning with the count, and the highlighted preview pane shows them as inline badges with their codepoint hex. The codepoint table below the preview gives every codepoint a row with name, category, block, JS escape sequence, HTML numeric entity, and UTF-8 byte sequence.

**The secondary job** is teaching the Unicode size model. JavaScript strings count UTF-16 code units, which makes `'😀'.length === 2` even though one emoji is one codepoint. Database VARCHAR(N) usually counts bytes, not codepoints, so a Chinese-character column with VARCHAR(10) fits about 3 Chinese characters in UTF-8. URL paths use percent-encoded UTF-8 bytes. Email headers use a different encoding entirely. The inspector shows codepoints, UTF-16 code units, and UTF-8 bytes simultaneously so you can reason about size limits in whichever layer you're working in.

**Block and category info** comes from a compact inline table covering the ~70 most-common Unicode blocks (Basic Latin, Latin Extended, Cyrillic, CJK, Hangul, Devanagari, the various Symbol blocks, the Math blocks, the various Emoji blocks, etc.). This is not a full Unicode Character Database (UCD) replacement — codepoints outside the table show "Unknown / Unassigned" — but it covers everything you're likely to encounter in real text. For exhaustive Unicode lookup, the Unicode Character Database directly (or unicode.org's online tools) is the canonical source.

**Names follow Unicode conventions**: 'LINE FEED', 'ZERO WIDTH SPACE', 'CJK UNIFIED IDEOGRAPH-4E2D', etc. Control characters get full names ('CHARACTER TABULATION' instead of 'tab'). Most CJK ideographs don't have individual names in the Unicode spec — they get the form 'CJK UNIFIED IDEOGRAPH-XXXX' where XXXX is the hex codepoint.

**JS escape sequences** are output in the form your JavaScript code can paste directly. BMP codepoints (≤ U+FFFF) become `\uXXXX`. Astral codepoints become `\u{XXXXX}` (ES2015 form). HTML entities use the decimal numeric form `&#NNN;` which works in every HTML parser.

**The trojan-source example** demonstrates the U+202E attack pattern. The input `safe‮nimda‬code` looks like `safeadmincode` because U+202E reverses the direction of everything after it. The inspector shows you what's actually there: 's', 'a', 'f', 'e', RLO marker, 'n', 'i', 'm', 'd', 'a', PDF marker, 'c', 'o', 'd', 'e'. This kind of thing has appeared in real attacks on code review (a 2021 paper coined the term "trojan source"). Linting tools have since added detection for it, but the inspector is the manual fallback.

**Privacy.** All analysis runs in your browser. The input you paste, the codepoint table, the highlighted preview — none of it crosses the network. No upload, no third-party lookup. Verify in DevTools — paste anything sensitive (a password, a session token, a private API key with weird characters), and the network panel stays empty. The inspector itself is small (no heavy lib, no font assets); after the page loads it works offline.

**Edge cases handled correctly**: surrogate pairs are joined into single codepoints (not shown as two separate entries); combining marks appear as separate codepoints (so you see them); variation selectors appear with their VS-N name; control characters appear with their CTRL name; the empty string gracefully produces zero rows.