Documents

Invisible Text in Documents

Hidden characters in documents — where they come from, what they break, and how to find them in each editor. Covers 3 tools.

Why hidden characters in documents matter

They break exact matching, and almost everything downstream depends on it. Every invisible character document editor and blank character word processor issue traces back to the same thing: a codepoint the application counts and the reader cannot see. Two strings that look identical stop being equal, and every comparison built on that inherits the failure.

The characters arrive through the clipboard rather than the keyboard. A PDF export substitutes U+00A0 for spaces to hold its layout. A web page carries U+200B for line-break control. Newer AI models emit U+202F in place of ordinary spaces. None is deliberate, and all of them travel with the text.

Why trimming does not fix it

Trimming removes only the characters whose Unicode propertyWhite_Space is Yes. That covers the 17 space separators and none of the zero-width characters.

Every Cf character — U+200B, U+200C, U+200D, U+2060, U+FEFF — hasWhite_Space=No, so trim(), TRIM() and the regex class\s all leave them in place. This is why the obvious fix appears to do nothing.

Match the category instead. Full property data for all 29 characters is on the Unicode invisible characters table.

Where they come from in a document

Four sources account for nearly every invisible character in a document, and none of them is the keyboard.

PDF exports. A PDF stores fixed positions rather than flowing text, so extraction substitutes U+00A0 for spaces to hold the layout. This is the single most common source, and it is why text pasted from a PDF breaks justification.

Web pages. Copying from a browser carries U+00A0 from  entities and U+200B from line-break control. Paste without formatting — Ctrl+Shift+V — avoids most of it.

Spreadsheet exports. CSV and XLSX files from finance and reporting systems commonly use U+00A0 as a thousands separator, which is correct typography and breaks every numeric import.

AI assistants. Newer models emit U+202F Narrow No-Break Space in place of ordinary spaces. See the AI text remover for the full character set.

How to tell before you go looking

Four symptoms give it away without any tooling.

  • A column of numbers sums to zero, or the total ignores some rows
  • Find-and-replace fails on a word that is plainly visible on screen
  • Justified text shows uneven gaps that resist every alignment setting
  • The cursor needs two arrow presses to cross what looks like one space

Each is the same underlying fault: the string contains a character that the application counts and the reader cannot see.

Choose your tool

Each guide covers one application: how to see the characters there, how to remove them, and what they break in that context.

Frequently asked questions

01

Where do invisible characters in Documents come from?

They arrive through the clipboard, not the keyboard. Text copied from a PDF, a web page, a spreadsheet or an AI assistant carries U+00A0 and U+200B from the source formatting, and neither is inserted deliberately.

02

How do I find them?

Match by Unicode category rather than by codepoint. The classes \p{Cf} and \p{Zs} cover almost every invisible character and keep working across Unicode releases, where a codepoint list goes stale.

03

Why does TRIM or trim() not remove them?

Because trimming only removes characters whose Unicode property White_Space is Yes. Every Cf character — the zero-width ones — has White_Space=No and survives untouched.

04

What breaks when they are present?

Exact matching, and everything built on it. Search fails, lookups return nothing, identifiers do not resolve, numeric columns parse as text, and version control shows phantom whitespace diffs.

Written by , developer and writer.

Last reviewed