Claude has begun embedding a text watermark into the text it generates (rolling out starting with models released on or after August 2, 2026). There is no visible difference for readers, and no additional cost. It was introduced in step with other major AI providers as a response to the EU AI Act. This article organizes the content of the official announcement while inserting supplementary technical reasoning at key points.

What changes and what doesn't

Overview (impact on users)

Impact on output quality/creativity/readability: None

Visible difference: Indistinguishable to readers

Personally identifying information: Not included (cannot identify the user, organization, or chat)

Scope: Not Claude-specific — major AI companies that signed the Code of Practice are responding similarly

Opt-out not possible: Since there is no technical means to restrict by region, it is currently applied globally, including outside the EU

Details on which models are supported and the future outlook are covered below in "Background of the rollout" and "Rollout status and roadmap."

Internal processing / technical mechanism

No characters or hidden characters are added at all: The watermark isn't new characters added to the text — it's embedded in the pattern of "choices that are already essentially tied between candidates," which already exist
No impact on speed or cost: Since no additional tokens are generated, billing and latency don't change. In the measured values from the Nature paper, even the 30-layer tournament method increased latency by only 0.57% (compared to 0.26% for Gumbel sampling and 0.28% for Soft Red List)
Persists through copy & paste: Since the watermark is embedded in the word choices of the text itself, it carries over when pasted elsewhere. It generally survives light editing, but can be lost with full rewrites or heavy paraphrasing (this differs in resilience from metadata-based approaches like C2PA)

Background of the rollout

The method adopted is based on SynthID-Text, announced by Google DeepMind in Nature in 2024, whose roots trace back to Scott Aaronson's 2022 proposal. The watermark itself is by no means a new idea — EU regulation is what pushed its implementation forward.

Rollout status and roadmap

It hasn't been deployed to every model at once — support status differs by model release timing. As of August 17, 2026, here's what is known.

Already in place: Models released on or after August 2, 2026 have supported watermarking since release, across all delivery channels — Claude itself, the API, Claude Code, Claude Cowork, Claude Tag, and via AWS/Google Cloud/Microsoft Foundry
Not yet in place: Models released before August 2 (older models) are planned to be rolled out within the transition period, but no specific timeline has been announced
Opt-out not possible: Since there is no technical means to restrict by region yet, it is applied globally uniformly, including outside the EU
Watermark detection tools and technical documentation also remain "to be provided later," with no details yet

How the watermark works

The © dekinai.net mark that appears under the figures on this blog is, in a sense, a "visible watermark." Claude's watermark is something else entirely — let's first put the two side by side to get a feel for the difference.

Anyone looking at © dekinai.net can tell "ah, that's a watermark." Claude's watermark, on the other hand, shows no trace of anything watermark-like no matter how closely you look, including in the body text of this very article. Being invisible is the whole point — the idea that only someone holding the key can verify it statistically after the fact is the foundation for everything that follows.

LLMs generate one word at a time, choosing the next word from among multiple candidates. In many cases the candidates are "equally natural either way," and the choice is inherently arbitrary (e.g., in "The weather today was cold and...," the continuation works equally well whether it's "overcast" or "grey").

Watermarking technology exploits this low-risk choice. Where a random number generator would normally decide, it substitutes a pseudo-random number computed from a key and the preceding sequence of words. The word chosen still looks random, but only someone with the key can later verify whether it matches "the kind of choice Claude tends to make."

Importantly, the watermark doesn't always force selection of one particular word (e.g., "overcast"). Depending on context, "grey" might get chosen instead. Nor does it force selection of a word Claude would rarely use otherwise (in the article's example, an obscure synonym like "nubilous").

A look inside: tokens and vectors

The official announcement uses the term "word" for a general audience, but internally, LLMs actually operate at the token level. Building on the official announcement, this section adds a more technically granular supplement on the internal processing of SynthID-Text-style watermarking (the following is technical reasoning based on generally known LLM sampling mechanisms, and does not guarantee the details of Anthropic's actual internal implementation).

The prototype for the idea of selecting a single token using "reproducible randomness tied to a specific key" via a pseudo-random number lies in the Gumbel-Max trick.

Normally, sampling one item from a categorical distribution (a probability vector) requires randomness
In the Gumbel-Max trick, independent Gumbel noise is added once to each candidate's logit (log-probability), and simply taking the candidate with the maximum value reproduces sampling faithful to the original probability distribution
Since this Gumbel noise can be constructed from a uniform random variable $u$ via the transform $-\log(-\log(u))$, deterministically generating $u$ from "a hash of the key + preceding token sequence" makes the choice look random while actually being reproducible and verifiable with the key
The scheme Scott Aaronson proposed in 2022 (exponential-minimum sampling) is said to have been a minimal watermark construction with mathematical properties close to this idea

However, what SynthID-Text actually adopts is the more elaborate tournament sampling, rather than a single-shot Gumbel-Max. The two aren't independent methods — they belong to a family of techniques sharing the common property of "distribution-preserving sampling using key-derived pseudo-randomness," related as single-layer versus multi-layer variants. Here's how the lineage breaks down.

Where a single-shot Gumbel-Max "settles the matter with one round of noise," the tournament method is a generalization that repeats a knockout round m times (m=30 in the paper) within the same arena (distribution-preserving). It's a recursive structure where, with each added layer, the adoption probability of a consistently winning candidate rises exponentially. The Nature paper's comparative experiments also report that SynthID-Text has an advantage in detection accuracy over non-distortionary Gumbel sampling. The other lineage, "distortionary (Soft Red List)," raises detection power at the cost of quality — and the fact that SynthID-Text chooses the distribution-preserving path is the technical backing for the official claim of "no impact on quality."

Getting a feel for it: a simple implementation

Rather than explaining in words, it's faster to look at working code. Below is a toy implementation that extracts only the core of the Gumbel-Max trick — it is not SynthID-Text itself (multi-layer tournament, real model logits), but it lets you experience firsthand the principle of "generating deterministic randomness from a key" (the code below has actually been run and its behavior confirmed).

import hashlib
import math
import random

# Example where candidate probabilities are closely tied (a case where the watermark tends to work well)
vocab_probs = {
    "overcast": 0.26,
    "grey":     0.25,
    "cloudy":   0.25,
    "windy":    0.23,
    "sugary":   0.01,  # Contextually unnatural candidate (low probability)
}

WATERMARK_KEY = "anthropic-secret-key-2026"  # In practice this would be a private key

def seeded_uniform(key: str, context: str, token: str) -> float:
    """Deterministically generate a pseudo-random number in [0, 1) from key+context+candidate token"""
    h = hashlib.sha256(f"{key}|{context}|{token}".encode()).hexdigest()
    return int(h, 16) / (16 ** len(h))

def gumbel_noise(u: float) -> float:
    """Convert a uniform random number into Gumbel noise (the core of the Gumbel-Max trick)"""
    return -math.log(-math.log(u))

def generate_next_token(context: str, probs: dict, key: str | None = None) -> str:
    """key=None yields ordinary random generation. Passing a key yields watermarked generation"""
    scores = {}
    for token, p in probs.items():
        u = seeded_uniform(key, context, token) if key else random.random()
        scores[token] = math.log(p) + gumbel_noise(u)  # logit + Gumbel noise
    return max(scores, key=scores.get)  # Select the token with the highest score

def detect_watermark(context: str, chosen_token: str, probs: dict, key: str) -> bool:
    """Use the key to verify whether the same token is reproduced"""
    return generate_next_token(context, probs, key=key) == chosen_token


# --- Example run ---
context = "The weather today was cold and"

print("Normal generation       :", generate_next_token(context, vocab_probs))
watermarked = generate_next_token(context, vocab_probs, key=WATERMARK_KEY)
print("Watermarked generation  :", watermarked)
print("Detect w/ correct key   :", detect_watermark(context, watermarked, vocab_probs, WATERMARK_KEY))
print("Detect w/ wrong key     :", detect_watermark(context, watermarked, vocab_probs, "another-key"))

Actual output from running it (with the same WATERMARK_KEY and context, the watermarked-generation result is reproduced every time):

Normal generation       : windy         ← can vary from run to run
Watermarked generation  : windy         ← always this result for the same key/context
Detect w/ correct key   : True
Detect w/ wrong key     : False

Three things you can feel here.

Just changing the key changes the result: Change WATERMARK_KEY to a different string and the chosen token changes too. This is the minimal illustration of why "a third party who doesn't know the key can't detect it"
Low-probability candidates are less likely to be chosen: Since sugary has a low probability (0.01), it tends to lose out to other candidates even with Gumbel noise added
Detection is just redoing the same computation as generation: detect_watermark isn't analyzing anything new — it's simply calling generate_next_token again with the same key and checking whether it matches. That's the real nature of "anyone with the key can verify it"

Bonus: with skewed probabilities, even the "wrong key" can match

If you swap the vocab_probs in the code above for a vocabulary with skewed probabilities (like the earlier example, where one candidate — e.g. overcast: 0.35 — dominates) and run the same experiment, something interesting happens: even the wrong key can sometimes be judged a "match."

This isn't a bug in the implementation — rather, it lets you directly feel the property this article has repeatedly explained: "in low-entropy (high-confidence) situations, the watermark's influence weakens." When probability is strongly skewed toward one candidate, Gumbel noise alone can't overturn that dominance no matter which key is used, and the result is a state where "any key arrives at the same answer" — statistically indistinguishable. The reason real SynthID-Text is designed to accumulate confidence over an entire long passage is precisely to address this problem, where a single token can't be distinguished from a coincidental match.

Real SynthID-Text does this not for a single token but for an entire passage (hundreds to thousands of tokens), and further improves detection accuracy by scoring via an m-layer tournament rather than a single-shot Gumbel-Max. But the basic skeleton — "key → deterministic pseudo-randomness → higher-probability candidates are more likely to be chosen" — is unchanged from this toy implementation.

The role of token sequences and vectors

Logits vector: A real-valued vector sized to the vocabulary, output every time the model runs one step of inference. Higher values indicate greater "likelihood of being the next token"
Probability distribution after softmax: The logits normalized into a probability distribution summing to 1. This distribution's entropy (spread) directly represents how much room there is for the watermark to intervene
High entropy = low-risk choice: A state where candidate tokens' probabilities are closely tied. Combining key-derived pseudo-randomness here doesn't significantly harm the model's "plausibility"
Low entropy = high-risk choice: A state where one token accounts for most of the probability (e.g., continuing a proper noun, the answer to a math expression). Here, mixing in pseudo-randomness still results in the highest-likelihood token being chosen, so the watermark effectively doesn't land

Where the key and hashing fit in

It's natural to think of the watermark key itself not as a single fixed value, but as functioning as a seed for hashing the sequence of the preceding few tokens (part of the context window). With this design, even the same key produces different pseudo-random outcomes as the context changes (consistent with the official explanation that it isn't fixedly biased toward a particular word). How the detection side uses this seed is covered below, in "How detection works."

Note also that Claude/GPT-family tokenizers often split English into 1 to a few tokens per word, while for languages like Japanese a single character can be split into multiple tokens. Since the watermark's "freedom of choice among candidates" arises at the token level rather than the word level, the density of the watermark can vary depending on the language and tokenizer granularity — a technical detail that's probably not negligible.

How detection works

Detection is the after-the-fact process of using the key to check "whether the generated sequence of words matches the pattern predicted by the key."

The official announcement uses a Monopoly analogy. If you use a sequence of digits from pi instead of dice to decide how far to move, it looks like ordinary random movement to the player. But if you know the "values of pi" afterward, you can verify whether the game really used pi. The watermark works on the same principle — it doesn't change the experience of generation itself, but makes after-the-fact verification possible.

Why detection accuracy drops for short passages

Given the key, detection is the process of recomputing, for any passage, "at each token position, how well the pseudo-random score computed from the key and the context up to that point matches the probability rank of the actually chosen token." Accumulating this degree of match across the whole passage yields a statistical test statistic, which is what backs the behavior of "confidence rises the longer the passage is."

This is easier to understand with an information-theoretic explanation. The watermark only works on "words (tokens) where there is freedom of choice," and short passages have fewer such choices (i.e., less evidence in bits). With only one or two token choices, it's statistically hard to distinguish whether it's a coincidental match to the key's pattern or genuinely Claude-generated. As the passage grows longer, weak token-level evidence accumulates, and confidence rises exponentially — an understanding consistent with the official explanation.

Strength of the watermark: where it works well and where it doesn't

Since the watermark only functions in situations where "either choice is equally correct," it naturally weakens in passages with little room for choice.

The same logic applies to code. Parts where "the correct answer is uniquely determined for the code to work" (syntax, places constrained by variable names, etc.) have little room for the watermark, while free-form parts like comments have room for it to apply. As a result, code as a whole ends up with a weaker watermark than other forms of text.

Application to files and images (C2PA)

As a separate mechanism from the text watermark, images and files that Claude generates or processes are given C2PA-standard metadata.

The distinction is clear: C2PA metadata is a "label" added to the file, not something hidden and embedded within the content itself the way the watermark is.

Differences between LSB steganography, EXIF, and C2PA

When you hear about "invisible information embedded" in an image, many people think of classic LSB (least significant bit) steganography. C2PA takes a completely different approach, and comparing the two clarifies where it stands.

Method	Where embedded	Resilience	Tamper detection
LSB steganography	Data embedded directly into the least significant bit of each pixel value	Easily destroyed by recompression, resizing, or screenshotting	Only shows whether embedded info is present or not; no tamper-detection mechanism
EXIF	Metadata region of formats like JPEG (capture date/time, device model, GPS, etc.)	Easily erased just by deleting the metadata	No signature; anyone can freely rewrite it
C2PA	Also a metadata region, but stored as a cryptographically signed manifest (provenance chain)	Lost if the metadata is deleted entirely, same as EXIF	Signature lets you verify whether tampering occurred (deletion can't be prevented, but tampering can be detected)

LSB is "steganography" that modifies the pixel data itself — in principle an idea close to text watermarking — but it has the weakness of being easily destroyed by lossy compression (e.g., converting to JPEG) or simple resizing
EXIF is just a conventional metadata standard for recording shooting/generation conditions, with no cryptographic guarantee whatsoever
C2PA follows the same "write to metadata" approach as EXIF, but by attaching a chain of digital signatures (Content Credentials), it makes the provenance of "who processed it, when, and how" cryptographically verifiable

In other words, C2PA is best understood not as "resilient embedding into pixels" like LSB, but as the EXIF idea reinforced with cryptographic signatures. So, as the official announcement notes, if the metadata is deleted entirely, the proof is lost along with it. This is a clear asymmetry in resilience compared to the text watermark (which survives copy-paste since it remains in the text itself) — and as a mechanism for guaranteeing the authenticity of images and files, it's relatively weaker.

FAQ

Question	Answer
Does it affect speed or cost?	No. Same speed, same price, since no additional tokens are used
Can it identify me or my organization?	No. It contains no personal information whatsoever
Can editing remove the watermark?	Light editing is unlikely to remove it, but a full rewrite will (in which case it's questionable whether it can still be called AI-generated)
What does the watermark prove?	Only the possibility that Claude was "involved." It can't distinguish whether Claude "wrote" it or "heavily edited" it
Does it apply to translation too?	Yes (since Claude chooses every word)
Does it apply to older models too?	Models released before August 2, 2026 have a transition period, and support is planned to roll out progressively over the coming months
How does it differ from existing AI detection tools like Pangram?	Detection tools don't have the key, so they infer based on the statistical "likelihood" of phrasing. This is fundamentally different from watermark detection
Does it change ownership or legal liability?	No. The watermark only indicates possible involvement and has no effect on copyright or rights under the terms of use

Summary

The following is not the official announcement itself, but supplementary reflection based on its content.

The technical design of the watermark itself is solid — the claims that "quality is unaffected" and "cost doesn't change" are technically sound, given that the mechanism only intervenes where there's freedom of choice. On the other hand, as the official announcement itself acknowledges, this mechanism has structural limitations.

Detection power is weak for short passages, factual text, and code. In contexts where misuse is a concern, there's an asymmetry: exactly the "short, inflammatory text that's easy to misuse" is the hardest to detect
The watermark can only show "whether Claude was involved," not "who wrote it." It can't distinguish between a case where a human drafted something and Claude lightly touched it up, versus a case where Claude wrote it from scratch
Since there's still no way to restrict by region, it's applied globally (without opt-out), including outside the EU. This stems more from technical constraints than from Anthropic's intent

While this is a reasonable move for regulatory compliance, its practical effect will likely remain limited until the existence of the watermark itself becomes widely known. The fact that major companies beyond just the EU are rolling out similar measures around the same time is a notable move toward building cross-industry transparency infrastructure.

Sources

How Claude's text watermark works (Anthropic, August 14, 2026)

Decoding Claude's Text Watermarking Feature - WaterMark