An invisible character detector found something. Now what?

Paste a paragraph into an invisible character detector and it may well light up. The interesting question is not whether hidden characters are in there. It is which ones, and what put them there — because almost every hit belongs to a short list with dull explanations.

What an invisible scan usually finds

• U+200B, zero-width space. Inserted by content management systems and web editors so long strings can wrap, and picked up routinely when text is pasted between rich-text fields.
• U+200C and U+200D, zero-width non-joiner and joiner. Not artefacts at all. Persian, Arabic, Hindi and other scripts need them to render correctly, and every multi-part emoji — the family sequences, the profession sequences — is built out of joiners. Strip them and you break the text.
• U+00A0 and U+202F, non-breaking and narrow no-break space. Ordinary typography: French punctuation spacing, or keeping 10 kg from splitting across a line. Word, InDesign, LaTeX and most CMSs emit them without being asked.
• U+FEFF, the byte order mark. An encoding marker that leaks into content when a text file or CSV is exported from a Windows tool and pasted somewhere else.
• U+00AD, soft hyphen. A hyphenation hint from a word processor or a PDF export, invisible until the line happens to wrap there.

Notice what all of those have in common. Each points to a piece of software, not to an author. That is the ceiling on what any invisible detector can tell you, and no amount of scanning raises it.

Why ChatGPT gets the blame

The phrase "chatgpt unicode detector" exists because of one specific episode. In April 2025 the education startup Rumi reported that OpenAI's then-new o3 and o4-mini models were leaving narrow no-break spaces in longer responses. It looked like a deliberate fingerprint, and a wave of detectors appeared to hunt for it.

Two parts of that story are usually dropped. OpenAI's answer — that the characters were not a watermark but a quirk of large-scale reinforcement learning — reached the public through Rumi relaying it, not through anything OpenAI published itself. And within days Rumi's own follow-up said the characters had stopped showing up in its testing.

What happened after that is genuinely unclear. There are scattered anecdotal reports of newer models inserting zero-width or unusual spaces, but nobody publishes a per-model, per-version rate, and the behaviour plainly changes between releases. Anyone telling you what today's models do here is guessing at a number that has not been measured in public. That is the current state of it: unpublished.

Set all of it aside anyway, because a stray space could not be a watermark even if it were perfectly reliable. A watermark carries a key and survives handling. This survives nothing — one find-and-replace removes it. That fragility is close to the reason OpenAI's real text watermarking work was built and then left on the shelf, which is a separate story.

The one result worth acting on

There is a category that behaves differently. Unicode tag characters, the block from U+E0000 to U+E007F, mirror ASCII invisibly: a whole paragraph of instructions can ride inside an apparently ordinary sentence. The technique is called ASCII smuggling, and it is used to plant instructions in emails, calendar invitations and documents that somebody's AI assistant will later read and act on.

In September 2025 the security firm FireTail tested a range of assistants against it and found the results split: ChatGPT, Copilot and Claude stripped the tag characters, while Gemini, Grok and DeepSeek acted on the hidden text. Google declined to fix its case, treating it as social engineering rather than a vulnerability. That testing is now a year old and vendor behaviour moves, so read it as a reason to check text before pasting it into an assistant, not as a current scoreboard.

The mundane reasons hold up just as well. Invisible characters break CMS imports, corrupt e-book formatting, confuse screen readers, and quietly stop a search from matching a word that looks correct on screen. Cleaning them is worth doing on its own terms.

What a result actually licenses you to conclude

1. Characters found. The text passed through software that inserts them — a model, a word processor, a CMS, a translation tool, a PDF export, a browser copy. Which one, the character alone cannot tell you.
2. Nothing found. Then nothing. Most writing contains no invisible characters at all, so an empty result is not evidence a person wrote it. Text from a model, pasted through one clean-up step, looks exactly the same.
3. Either way. This is not authorship evidence, in either direction. Failing a student or a contractor on it means acting on a clue about tooling as though it were proof about a person.

An invisible detector that reports "AI watermark found" is misnaming a copy-paste artefact. The characters are real; the label attached to them is not.

To see the exact codepoints in your own text — and copy it back out clean — use the hidden character checker. It names each character it finds and leaves the conclusion to you, which is the only honest way to run this scan.