Grok watermark detector

This tool scans text copied from Grok for the zero-width and non-printing Unicode characters a chat interface can leave behind, without altering how the text displays. It's built for a specific, searched question, does Grok put a hidden watermark in its output, and it answers with a list of findings rather than a verdict.

The scan is local and client-side. Nothing is uploaded, no account is required, and there's no limit on how many times you can run it.

Grok exists in two distinct interfaces: embedded inside X's app and website, where an answer is generated and copied through the same text pipeline that handles posts and replies, and as a separate standalone app with its own ordinary chat layout. The two do not process a copy to clipboard identically.

Zero-width space and joiners

Occupy a character slot and render nothing. The most frequent invisible residue in copied text.

Non-breaking spaces

Identical to a normal space on screen, sometimes picked up passing through X's own composer field.

Soft hyphens and word joiners

Invisible until a line wraps or a search fails to match text that looks identical on screen.

Byte-order marks and bidi controls

Rarer, but capable of confusing a parser or reordering how text displays when they end up mid-document.

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

Step 1

Copy the reply using Grok's own copy control, whichever of its two interfaces produced it.

Step 2

Paste the sample and run the scan. It executes locally and lists every hidden character found, with its position.

Step 3

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

A zero-width space inside a heading pasted from Grok splits the keyword, so the slug or anchor stops matching the visible title. A non-breaking space picked up on the way through X's composer breaks YAML, a shell command or a CSV column, usually without any visible sign of the cause.

The same characters produce EPUB validation failures and CMS fields that silently refuse to save. None of it requires anything unusual; it's the ordinary cost of moving text through a platform built for posts rather than documents.

The mechanism is structural, not deliberate. Grok's answer inside X passes through the same composer used for posts, replies and quote-tweets, a text field built around character limits and link handling rather than documents. The standalone app renders in a plainer chat layout closer to other assistants, with a separate copy path.

Two people quoting the same underlying answer, one from inside X and one from the standalone app, can end up with different invisible residue purely because of which interface handled the copy.

This is a character scan, nothing more. It does not analyse sentence structure, vocabulary or writing rhythm, and it makes no attempt to determine whether a passage was written by Grok, another model, or a person. A clean result is not proof of human authorship, and a flagged character is not proof of Grok's involvement.

It also cannot detect statistical or token-level watermarking, a research technique that biases a model's word-choice probabilities rather than inserting any character at all. No character-level scan, including this one, can see that kind of signal.

No. The same characters turn up in text copied from Word, ordinary X posts and chat interfaces entirely unrelated to Grok. A finding here is a formatting lead, worth acting on if it's causing a practical problem, not evidence of source.

It says nothing about whether the text would pass a third-party AI detector either. Those tools weigh statistical properties of the prose itself; this scan only reports what characters are present in the bytes.

Any workflow where Grok output is copied somewhere that parses text strictly, publishes it, or feeds it into another system.

Writers and editors

Pulling a Grok answer out of X without carrying a split slug or heading into an article.

Developers

Checking a Grok-drafted snippet or config file before it's committed.

Data and ops teams

Verifying a Grok answer pasted into JSON, CSV or a database field will actually parse.

Anyone exporting to PDF or EPUB

Catching invisible characters before a layout engine trips on them.