How to identify an invisible Unicode character
When two strings look identical but search, validation, or matching says otherwise, inspect the code points instead of the pixels. This field guide turns an invisible-character mystery into a reproducible check.
Key takeaways
- Compare code points when visible inspection cannot explain a mismatch.
- Record the exact character, source application, and failing destination before changing it.
- Remove invisible marks only when they are accidental; some scripts use joiners intentionally.
Start with a controlled comparison
Copy the failing value and a known-good value into a plain-text editor. Compare their lengths, then move the cursor one position at a time. A cursor stop with no visible glyph is a useful clue, but the decisive evidence is the Unicode code point.
For example, invoice-104 and invoice-104 render almost identically. The second value contains U+200B ZERO WIDTH SPACE between the word and hyphen. An exact match correctly treats them as different strings even though a person may not see the distinction.
- Preserve a copy of the original failing value.
- Compare character counts before and after normalization.
- Test one suspected character at a time so the result stays attributable.
Name the character before choosing a fix
A visible label such as U+200B is more useful than calling something a hidden space. U+200B, U+200C, U+200D, U+2060, U+00A0, and U+202F have different purposes. Naming the code point makes bug reports reproducible and prevents a broad replacement from damaging intentional text.
Source context matters too. A word joiner found inside a copied product code is probably accidental. A joiner inside shaping-sensitive language may be intentional. The same code point can therefore lead to a different decision depending on where the text came from and where it is going.
Confirm the fix in the failing system
After removing or normalizing the character, repeat the operation that originally failed: exact search, form submission, filename lookup, URL comparison, or import. A cleaner preview proves that the string changed; the destination test proves that the change solved the right problem.
Document the before value, code point, chosen replacement, and result. That small record turns a one-off cleanup into a reusable rule for the next PDF export, CMS paste, or data import from the same source.