Paste a paragraph from a chat tool into a code editor and something occasionally looks wrong that nobody can quite point to. The words are right. The spacing looks right. Then a search comes back empty for a phrase that is plainly sitting right there on the screen.
The likely culprit is a family of invisible Unicode characters that have been turning up in output from several large language models since 2025, characters with no visual form at all but a real, physical presence in the text data itself.
A Character You Can’t See, But Can Definitely Break Something
Researchers and developers cataloguing the pattern have identified a recurring handful of characters riding along in AI-generated text:
- Zero-width space (U+200B), which inserts an invisible break inside what looks like a single word.
- Narrow no-break space (U+202F), a spacing character normally used before certain punctuation in French-style typography.
- Word joiner (U+2060), meant to prevent a line break at a specific point, with no visible width of its own.
- Byte order mark (U+FEFF), a leftover marker from how a file declares its text encoding.
None of these characters render as anything on screen. A reader scanning the text sees nothing unusual. A program comparing two strings, or a search function looking for an exact match, sees a difference a human eye never could. Two sentences that look completely identical on screen can differ in actual byte length by a noticeable margin once a handful of these characters are woven through the words, a gap that only shows up the moment something tries to measure or match the text rather than simply display it.
Training Artifact, Not a Secret Signature
When these characters were first noticed, the working theory online was that a model provider had quietly started marking its output for tracking purposes. Closer analysis has pointed the other way. The leading explanation is that the models were trained on large volumes of professionally typeset text, academic papers, published books, and multilingual documents among them, that use these characters legitimately for spacing and line control. The model appears to have picked up the habit of reproducing them as an emergent side effect of that training data, not as a deliberate marker placed there on purpose. OpenAI has said as much directly about characters appearing in its own models’ output.
How the Story Started
The pattern first drew wide attention in 2025, when a research group studying AI-generated writing patterns published findings that newer reasoning models were consistently leaving these characters in longer responses, while older models from the same provider were not. The report spread quickly, with plenty of people reading it as proof of a hidden tracking system. The provider’s own response, published shortly after, was more measured: the characters were acknowledged, but described as a byproduct of training rather than an intentional signal, and no claim was made that they could reliably identify AI-generated text on their own. That distinction, a real technical curiosity versus a deliberate identification system, is easy to lose once a claim has already spread as the more dramatic version.
Where This Actually Bites: Code, Search-and-Replace, CMS Fields
The practical damage rarely announces itself. A developer pastes an AI-suggested code snippet and a variable name that looks identical to one elsewhere in the file quietly fails to match, because one copy carries an invisible joiner and the other doesn’t. A writer tries to find-and-replace a phrase across a long document and the tool reports zero matches for text that is visibly right there. A byte order mark sitting at the start of a file can break how some systems parse it entirely, especially older scripts and command-line tools that don’t expect one.
Word and character counts drift too, in ways that matter more than they might seem to. A freelancer billing by the word, or a platform enforcing a strict character limit on a title or a meta description, can end up with a count that’s technically accurate but visually confusing, since every invisible character counts toward the total even though nobody can see it sitting there. A caption that looks like it fits comfortably under a hard limit can quietly fail validation for reasons that have nothing to do with the visible words.
A Quick Way to Check If Your Text Has Them
Pasting a suspect passage into a plain text editor that displays hidden characters, or running it through a tool built to flag them, is usually enough to confirm the problem. The count of actual characters in a sentence will run noticeably higher than what a person would count by eye, sometimes by several characters per paragraph.
The Problem Isn’t Limited to One Chat Tool
Most of the early reporting on this focused on a specific family of models, since that’s where independent researchers first went looking. That doesn’t mean the underlying cause is specific to one company. Any model trained on a similar mix of richly formatted, multilingual source text has the same statistical incentive to reproduce the spacing conventions it learned from, which is a reasonable basis for treating this as a general property of how these models are trained rather than a quirk tied to one provider’s product decisions.
It’s Not Only About Unicode: Rich-Text Leftovers Do Similar Damage
A related but separate issue shows up when text is copied out of a chat interface as rich text rather than plain text. Some AI chat tools render their output with hidden HTML attributes attached to individual words or phrases, invisible in a browser but pasted along with the visible text into anything that accepts rich formatting, a Google Doc or a Notion page, for instance. The visible symptom looks similar to the Unicode problem: unexplained spacing, inconsistent styling that appears after pasting, or a document that looks fine until it’s exported and something has shifted. The underlying cause is different, formatting metadata rather than invisible characters in the text itself, but the practical fix is the same: strip it out before the document goes anywhere that matters.
Cleaning It Up Without Breaking the Meaning
Removing these characters does not touch the meaning of a sentence in any way, since they carry no semantic content to begin with, which is part of why a general-purpose watermark remover built specifically to strip invisible Unicode and normalize spacing is a cleaner fix than trying to hunt down individual characters by hand.
This is a straightforward technical cleanup, not a workaround for anything. A sentence with the invisible characters stripped out reads exactly the same as one that never had them, and behaves correctly again in the tools that choked on it before, search functions, code diffs, and CMS fields included.
None of this requires treating every AI-assisted document with suspicion. It just means copy-paste from a chat interface deserves the same basic scrutiny as copy-paste from any other source with its own formatting conventions, a PDF or a foreign-language document, for instance, where a quick cleanup step before the text goes anywhere important has always been ordinary practice.
Most of what gets loosely called an AI watermark in casual conversation isn’t a watermark at all, it’s a training artifact that happens to leave a real, fixable trace. Treating it as a technical formatting issue, rather than a mystery to work around, is usually the fastest way through it.
