Watermark detector
What the watermark detector does
This 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 answers the question people type into a search bar, does this text have a watermark, with a specific list of what it found rather than a vague yes or no.
This is a local, browser-based tool. Scanning runs entirely on your device, nothing is uploaded, there's no account, and there's no limit on how many times you can run it.
What comes back is a list of findings, not proof of anything. This page is upfront about what a hidden character actually means, because a lot of what circulates online about text watermarking overstates what a character scan can actually tell you.
How it works
How to check text for a watermark in three steps
It takes seconds, runs right in the page, and nothing you paste ever leaves your browser.
- Step 1
- Paste the text you want checked. 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
- Press Scan text. The scan runs locally, right in your browser, and lists every hidden character it finds along with where it sits.
- Step 3
- Read the findings before drawing a conclusion. A hidden character on its own tells you about formatting, not about who or what wrote the words.
The characters
The characters a watermark detector actually looks for
These are ordinary Unicode codepoints, each with a legitimate technical purpose, that can also turn up as accidental leftovers 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 that prevents a line break at that point, frequently left behind by rich-text conversion.
- U+FEFF byte-order mark
- Meant to sit at the very start of a file, sometimes 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
- Look identical to a normal space, behave differently in code, slugs and search.
- Bidi controls (U+202A to U+202E)
- Directional embedding and override characters that can quietly reorder how text displays.
Where they come from
Why these characters actually end up in text
Despite a lot of online talk about hidden watermarks, most of what a scan like this finds is incidental. Rich-text-to-plain-text conversion, how a chat interface's editor tracks cursor position, how a word processor exports a document, and how a phone 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 tells you something happened during formatting. It doesn't, by itself, tell you the text was watermarked on purpose, or written by any particular source.
What real watermarking looks like
Is there such a thing as a real text watermark?
Yes, in a couple of specific senses, and it's worth being precise about which one applies here. Encoding a hidden signal in text using invisible characters is a real, documented technique, sometimes used deliberately in research or leak-tracing tools to mark a specific copy of a document. That's a genuine use of characters like these, just not one that happens by default every time a chat interface generates a reply.
Separately, there's statistical, token-level watermarking: tuning a language model to slightly bias its word-choice probabilities in a pattern that's detectable with the right statistical test, applied across a whole passage. That's a real area some AI labs have researched. It doesn't insert any characters at all, and no character-level scan, including this one, can see it. If someone tells you they detected an AI watermark by scanning for zero-width characters, they're most likely describing an ordinary formatting artefact, not either of these real techniques.
What a finding actually means
Does finding a hidden character prove the text is AI-written?
No. A hidden character found by this scan is a formatting artefact far more often than it's 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 tool reports what it finds and stops there.
Why you might see a flag
Why perfectly ordinary text can trigger this scan
Plenty of everyday, entirely human workflows produce these same characters.
- Word processor exports
- Word, Google Docs and similar tools insert non-breaking spaces and soft hyphens as part of normal formatting.
- Translation tools
- Machine and professional translation software frequently leaves directional or joining characters behind.
- PDF copy-paste
- Extracting text from a PDF often introduces stray characters the original document never displayed.
- Mobile keyboards
- Autocorrect and predictive text on phones can insert a non-breaking space where a regular space was intended.
- CMS and rich-text editors
- Switching between rich text and plain text views is a common source of leftover formatting characters.
Why it matters anyway
What these characters actually break, and who runs this check
Regardless of where they came from, these characters cause real problems once text moves somewhere that parses it strictly. A zero-width space inside a heading splits a keyword, a byte-order mark inside JSON breaks the parser, and non-breaking spaces confuse diffing tools and find-and-replace.
Writers, editors, developers and anyone publishing text they didn't type by hand run this to catch those problems before they surface downstream. Because it runs locally with no server involved, there's no limit on how many times you can use it, and no reason not to check text as a routine step before it ships anywhere.