Llama watermark detector

This tool scans text copied from Llama 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 Llama 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.

Llama is open-weight, which makes it structurally different from every other model on this site: there is no single official chat surface. Meta AI's own apps are one path; dozens of unrelated third-party hosts, developer playgrounds and API-based clients running the same weights are others, each with its own Markdown rendering and copy-to-clipboard behavior.

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, and how often they appear depends on which host rendered the output.

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 more likely from one host's export path than another purely due to implementation differences.

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

Step 1

Copy the reply using whichever interface's own copy control 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 the interface, not about who produced the words.

A zero-width space inside a heading pasted from Llama splits the keyword, so the slug or anchor stops matching the visible title. A non-breaking space carried over from whichever interface rendered the reply 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 flattening rich text, wherever that formatting happened.

This is the one genuinely distinguishing fact about Llama: because the weights are openly published, dozens of unrelated applications serve the same model, from Meta's own consumer products to self-hosted deployments and third-party API wrappers, and each converts formatted output to plain text on its own terms.

The practical consequence is that a hidden-character finding in Llama text says almost everything about which specific interface produced the copy, and very little about the model generating the words underneath it. Two people quoting an identical Llama answer through two different hosts can see meaningfully different invisible residue.

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 Llama, another model, or a person. A clean result is not proof of human authorship, and a flagged character is not proof of Llama's involvement, less so here than for almost any other model given how many interfaces it runs through.

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, and this is the clearest case on the site for why not. Llama has no single interface, so the same characters that turn up in text copied from Word, Google Docs and countless unrelated tools also turn up depending entirely on which Llama host produced the copy. A finding here is a formatting lead, 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 Llama output is copied somewhere that parses text strictly, publishes it, or feeds it into another system.

Developers

Checking output from a self-hosted deployment or API integration before it's stored or displayed.

Researchers

Comparing Llama output across hosting providers and needing to know whether a difference is the interface or the model.

Data and ops teams

Verifying a Llama 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.