Does Claude Code leave a watermark?

Coverage follows the model and surface

The current policy names Claude Code among the covered products when it uses a supported model. Earlier models are in transition, and some platforms or features may not support every marking type.

There is also a structural reason to expect code to behave differently from prose. A statistical text watermark works by steering word choice among many acceptable alternatives. Code has far less of that freedom: syntax is rigid, identifiers are constrained by the surrounding codebase, and a large share of any file is boilerplate that could hardly be written another way. Whatever coverage policy says, the medium itself offers less room for a signal to live in.

Code can contain legitimate invisible controls

Bidirectional controls, zero-width joiners, byte-order marks, and other code points can be security-sensitive or semantically required. The inspector therefore preselects only lower-risk items and leaves ambiguous controls unchecked for manual review.

Where invisible characters legitimately appear

• String literals with real content. User-facing strings in Arabic or Hebrew may need bidirectional marks to render correctly. Removing them corrupts the UI.
• Emoji sequences. Zero-width joiners are structural in composite emoji. Strip them and one glyph becomes several.
• Byte-order marks. Some toolchains write a BOM at the head of a file. Some parsers require it; others choke on it. Either way it is a deliberate artifact, not contamination.
• Test fixtures. Code that tests Unicode handling contains awkward code points on purpose. That is the whole point of the fixture.

Where they are a genuine problem

The security case worth knowing is bidirectional override abuse, sometimes called a Trojan Source attack: control characters reorder how a line displays without changing how the compiler reads it, so reviewed code and compiled code differ. Unicode Tag characters are similarly worth flagging, since they are invisible and can carry arbitrary data.

These are exactly the categories the checker highlights — not because they prove an AI wrote the code, but because they are worth a human look regardless of origin.

Review before changing source code

Removing an invisible code point can change identifiers, rendering, string values, or text direction. Compare the cleaned preview, run your formatter and tests, and treat the output as a proposed edit—not a guarantee that Anthropic's model-level watermark has been removed. That mark is statistical rather than character-based, and Anthropic notes it applies far less to code in the first place: where an exact token is required, there is no free choice for the watermark to ride on, so it lands mainly in comments and other prose.

A workable review sequence:

• Paste the snippet into the checker and read every finding with its surrounding context before ticking anything.
• Leave anything inside a string literal unchecked until you have confirmed it is not load-bearing.
• Apply the cleaned version to a working copy, never straight to a shared branch.
• Run the formatter and the test suite. Unicode problems in code usually surface fast once tests execute.
• Read the diff. A character-level change that produces a suspiciously large diff means something else moved too.

For teams, the durable fix is upstream: a CI check that rejects unexpected control characters in source files. That catches the security-relevant cases continuously, whoever or whatever wrote the code, instead of relying on someone remembering to paste snippets into a web tool.

What a clean result means for code

Exactly what it means for prose: the specific characters this tool inspects were not found. It does not establish that the code was written by a person, that no AI touched it, or that no model-level mark exists. If your policy requires knowing whether AI assistance was used, ask — the answer is not recoverable from the characters.

The characters worth knowing by name

If you review code, these are the code points that actually matter. Recognising them by name is more useful than any detector score.

• U+200B zero width space. Renders as nothing. Inside an identifier it produces two names that look identical. Inside a string it silently changes the value.
• U+200D zero width joiner. Structural in emoji sequences. Removing it splits one glyph into several.
• U+2060 word joiner. Prevents a line break without adding width. Harmless in prose, meaningless in most code.
• U+202E right-to-left override. The one with real security weight. It reverses display order without changing what the compiler reads, so a reviewer and a compiler can see different logic.
• U+FEFF byte order mark. At the head of a file it is a deliberate encoding signal. Anywhere else it is usually a concatenation accident.
• U+E0000–U+E007F Unicode Tags. Invisible and able to carry arbitrary payloads. Almost never legitimate in source.

Every finding the checker reports names the character this way and shows its position, so you are judging a specific code point in context rather than accepting a verdict.

Why this matters more for code than for prose

In an essay, an unexpected zero-width space is cosmetic. In code it can be a defect or a vulnerability.

An invisible character inside an identifier creates two symbols that are visually identical and functionally distinct — a bug that survives code review precisely because reviewing is visual. Inside a string literal it changes a value that comparisons depend on, so a test that looks correct fails for reasons nobody can see. In configuration files, a stray BOM can make a parser reject a file that appears perfectly well formed.

None of these problems are AI-specific. They predate language models by decades and arrive just as often from copying a snippet out of a blog post or a PDF. That is the practical reason to run this check on pasted code in general, not only on code you suspect came from a model.

For pasted code and prose from other assistants, the AI text watermark remover applies the same inspection and the same review-before-removal defaults, which matter more in a source file than anywhere else.

Related guides