Watermark detector

GPTCleanup Pro's watermark detector scans any block of text for the zero-width and non-printing Unicode characters that can sit inside it invisibly, without changing how the text looks on screen. It's built for the question people type into search: does this text have a watermark. The answer here is a specific list of findings, not a vague yes or no.

It's a local, browser-based tool. Scanning runs entirely on your device, nothing is uploaded, no account is required, and there's no limit on how many times you can run it.

This page treats a finding as evidence to be read carefully, not proof of anything. A great deal of what circulates online about text watermarking overstates what a character scan can actually establish, and this tool is built to correct that rather than trade on the ambiguity.

The scan runs entirely client-side. No round trip, no server, nothing transmitted.

Step 1

Paste the sample. If it's from a chat interface, a document or a webpage, use the source's own copy option rather than retyping it.

Step 2

Run the scan. It executes locally in your browser and lists every hidden character found, along with its location.

Step 3

Review the findings before drawing a conclusion. A hidden character indicates something about formatting, not about who or what produced the words.

Each of these is an ordinary Unicode codepoint with a legitimate technical purpose, and each can also appear as an incidental leftover from copying, converting or formatting text:

U+200B zero-width space

Occupies a character slot and renders nothing, the most common invisible character found in copied text.

U+200C / U+200D joiners

Zero-width non-joiner and joiner, meaningful in some scripts and emoji, often a stray leftover elsewhere.

U+2060 word joiner

An invisible joiner preventing a line break at that point, frequently left behind by rich-text conversion.

U+FEFF byte-order mark

Meant to sit at the start of a file, occasionally left stranded mid-document by an export tool.

U+00AD soft hyphen

Invisible until a line wraps there, then a hyphen appears in a word that never had one.

U+00A0 / U+202F non-breaking spaces

Visually identical to a normal space, distinct in code, slugs and search indexing.

Bidi controls (U+202A to U+202E)

Directional embedding and override characters that can quietly reorder how text displays.

Despite widespread claims online about hidden watermarks, most of what a scan like this surfaces is incidental. Rich-text-to-plain-text conversion, how a chat interface's editor tracks cursor position internally, how a word processor exports a document, and how a mobile keyboard autocorrects a space are the usual sources. None of that requires anyone to have deliberately hidden anything.

Copy text out of a Word document, a Google Doc, a PDF, a translated page or a chat interface, and some of these characters can travel along regardless of who wrote the underlying words. A finding indicates something happened during formatting. It does not, by itself, indicate the text was watermarked on purpose, or produced by any particular source.

Yes, in two specific senses, and it's worth being precise about which applies here. Deliberately encoding a hidden signal in text with invisible characters is a real, documented technique, occasionally used in research or leak-tracing tools to mark a particular copy of a document. That's a genuine use of characters like these, though not one that happens by default every time a chat interface generates a reply.

Separately, there is statistical, token-level watermarking: tuning a language model to bias its word-choice probabilities slightly, in a pattern detectable with the right statistical test applied across a whole passage. That's a legitimate area of research some AI labs have pursued. It inserts no characters at all, and no character-level scan, including this one, can observe it. A claim that an AI watermark was detected by scanning for zero-width characters is, in most cases, describing an ordinary formatting artefact rather than either of these actual techniques.

No. A hidden character found by this scan is a formatting artefact far more often than a deliberate marker of any kind. The same characters appear in human-typed documents exported from Word, in translated text and in anything copied through a rich-text editor, with no AI involved anywhere in the chain.

Treat a finding as a lead about formatting worth investigating if it's causing a practical problem, not as evidence about authorship. This detector reports what it finds and stops there.

Several categories of everyday, entirely human workflow produce these same characters, and a serious tool should name them rather than let a finding imply more than it supports.

Word processor exports

Word, Google Docs and comparable tools insert non-breaking spaces and soft hyphens as part of standard formatting.

Translation tools

Machine and professional translation software frequently leaves directional or joining characters behind.

PDF extraction

Pulling text from a PDF commonly introduces stray characters the source document never displayed.

Mobile keyboards

Autocorrect and predictive text can insert a non-breaking space where a regular space was intended.

CMS and rich-text editors

Toggling between rich-text and plain-text views is a routine source of leftover formatting characters.

Independent of origin, these characters cause concrete problems once text moves somewhere that parses it strictly. A zero-width space inside a heading splits a keyword, a byte-order mark stranded inside JSON breaks the parser, and non-breaking spaces confuse diffing tools and find-and-replace.

Editors, developers, publishers and anyone shipping text they didn't type by hand run this scan to catch those problems before they surface downstream. Because it runs locally with no server involved, there's no limit on how many times it can be used.