How to Find Invisible Characters in Text

Two lines look completely identical on screen but a comparison, lookup, or piece of code insists they aren't the same. Nine times out of ten the cause is a character that isn't rendering as anything visible at all - a non-breaking space instead of a regular one, a zero-width space sitting between two letters, or a byte order mark at the start of a file. None of these show up by eye. All of them count as a real character to any exact comparison.

What counts as invisible

• Non-breaking space (NBSP) - looks exactly like a regular space but prevents a line break at that point.
• Zero-width space/joiner/non-joiner - take up no visible width but sit between characters as real, distinct code points.
• Byte order mark (BOM) - a marker some tools add at the very start of a text file to signal its encoding.
• Word joiner - similar to a zero-width space, used to prevent an unwanted line break without adding visible space.
• Tabs and carriage returns - render as whitespace or nothing depending on the editor, but are distinct characters from a plain space or line feed.

Where they come from

Copying text out of Word documents or web pages is the most common source - both use non-breaking spaces to control how names, dates, or short phrases wrap, and that character travels with the text wherever it's pasted. PDFs often leave stray characters behind from how the original layout was encoded. Zero-width characters are increasingly used deliberately as an invisible watermark in AI-generated text, embedded between words in a pattern that's undetectable to the eye but can be extracted programmatically. And exporting from Windows versus Unix-based tools produces different line-ending conventions - carriage return plus line feed on Windows, just line feed on Unix - which is invisible in most editors but very much present in the underlying bytes.

The symptoms that point here

A list comparison tool reporting that two visually identical lines don't match is the single most common tell. A VLOOKUP or similar lookup failing to find a value that's clearly present in the data is another - the lookup key has a trailing NBSP the visible value doesn't appear to have. In code, a pasted snippet that produces a baffling syntax error on a line that looks completely normal is frequently a zero-width character sitting inside an identifier or string literal. In all three cases, the fix isn't retyping the text - it's finding and removing the specific invisible character causing the mismatch.

How the detector annotates your text

Paste text into the tool and each invisible character is swapped for a visible, color-coded badge inline exactly where it occurs - [NBSP], [ZWS], [TAB], and so on - so you can see precisely which line and which position is affected, rather than a vague "something doesn't match" result. A summary at the top counts how many of each character type were found across the whole input. A cleaned version of the text with all invisible characters stripped is generated alongside it, ready to copy back into whatever needed the fix.