What's actually in your text

A block of text on screen is not the same thing as the block of text in the file. Characters with no width, spaces that are not spaces, and letters that are not the letters they look like all survive a copy and paste. This is the full list, what each one does to you, and how to check without uploading anything.

Why you cannot answer this by looking

Every one of the characters below either renders as nothing at all or renders as something it is not. Your eyes are not the instrument for this: the display is doing exactly what the file asks, and the file is the problem. Find-and-replace does not help either, because you cannot type most of these into a search box.

What does work is listing the code points. Every character has a number, and a checker that prints those numbers turns an invisible problem into an ordinary one.

The things that turn up

Characters with no width

These occupy a position in the string, count towards its length, and draw nothing.

Spaces that are not the space key

These are visible — they just do not behave like the space you typed. A non-breaking space stops a line wrapping there, a narrow space is a different width, and none of them match a search for an ordinary space.

U+00A0 non-breaking, U+2007 figure space, U+202F narrow no-break, U+2009 thin space, and the whole U+2000–U+200A range of typographic spaces. Word processors and PDFs produce them constantly.

Letters that are not the letters

Cyrillic а and Latin a are different characters that look identical in most fonts. Same for е, о, с, р, х and a dozen more, plus several Greek letters. This is what makes a fake domain or an altered invoice line pass a glance — see homoglyphs.

Direction marks

U+200E and U+200F set the reading direction, and the U+202A–U+202E range can override it outright. They draw nothing and they can make a string display in an order it is not stored in.

Typography

Curly quotes, em and en dashes, and the single-character ellipsis. All perfectly legitimate, all frequently unwanted in code, CSVs, config files and anywhere a plain ASCII quote is expected. Denser than usual, they are also one of the more visible signatures of generated text — the em dash page goes into that.

Layout damage

Not characters but structure: lines broken mid-sentence at the width of the original column, words split across a line break by a hyphen, page numbers and running headers stranded in the middle of a paragraph. Copying out of a PDF produces all three, every time — see text copied out of a PDF.

What each one costs you

• Search stops finding things. A word with a zero-width space in the middle of it does not match itself.
• Comparisons fail. Two identical-looking strings are not equal. In a spreadsheet lookup or a config file this is a genuinely hard bug to see.
• Counts are wrong. Character limits, word counts and truncation all include characters nobody can see.
• Diffs go noisy. A commit that changed one sentence shows as a whole paragraph rewritten.
• Data can be hidden. Several zero-width characters exist, so a run of them encodes bits, and bits encode text. A paragraph can carry a message with no visible trace at all.

How to check

Paste the text into a checker that lists what it finds rather than silently stripping it. You want three things from the answer: which character, where it is, and what it is for — because some of them are deliberate. The zero-width joiner holding an emoji together is not damage, and a cleaner that removes it has broken something rather than fixed it.

humanaze does exactly this. Reveal marks every position in place so you can see where they sit in the sentence, the report lists them by code point with an explanation of each, and Clean removes them when you ask. All of it runs in your browser — the text is not uploaded, and there is no account to make.

Common questions