How Can an Invisible Watermark Live Inside AI-Generated Text?

Anthropic says supported Claude models will embed machine-readable watermarks directly into generated text.

That sounds odd. Text has no pixels to hide a pattern in, and this is not just metadata attached to a file. If the text is copied into an email, document, Reddit post, or website, the watermark may still travel with it.

The useful mental model is simple:

The watermark can live in the choices the model makes while generating words.

Anthropic has not published Claude's exact text-watermarking algorithm yet. The techniques below explain how the main research approaches work, not necessarily Claude's implementation.

1. Normal LLM Generation

An LLM generates one token at a time.

Suppose it has written:

The team decided to ___ the product launch.

The next-token probabilities might be:

delay        24%
postpone     22%
move         18%
reschedule   16%
cancel        8%
...

A watermarking system can make tiny changes to these probabilities before the next token is sampled.

It does not need to force strange words. It only needs to prefer some normal choices slightly more often. Repeat that across hundreds of tokens and a detector can look for the statistical pattern.

2. Token-level watermarking

2.1 KGW: How the green and red token lists are created

One of the best-known approaches is the watermark from Kirchenbauer, Geiping, Wen and colleagues, usually called KGW.

The important detail is that there is not one permanent green list and one permanent red list.

The lists can change for every generated token.

Let's walk through one generation step.

Suppose the model has already generated:

The team decided to

Step 1: The LLM calculates normal next-token probabilities

Before watermarking, the model may produce something like:

delay        24%
postpone     22%
move         18%
reschedule   16%
cancel        8%
defer         5%
...

At this point, nothing about watermarking has happened yet.

These are simply the probabilities from the language model.

Step 2: Take the previous context

The watermarking system looks at the tokens that came before the next token.

Conceptually:

The team decided to

A real implementation does not necessarily need to use the entire document. A watermark can use a limited amount of recent token history.

The important idea is that the current context becomes one of the inputs used to create the watermark pattern.

Step 3: Combine the context with a secret key

The watermarking system also has a secret key known to the generator and detector.

Conceptually:

previous tokens
      +
secret key

For example:

"The team decided to" + SECRET_KEY

The secret key is important because someone reading the output should not be able to easily predict which tokens the system prefers.

Step 4: Generate a pseudorandom value from that input

The context and secret information are used to seed or derive a pseudorandom token partition.

A simplified mental model is:

hash("The team decided to" + SECRET_KEY)

Imagine this produces:

72845193...

The number itself is not the watermark.

It is used to reproducibly create a pseudorandom rule for the next token.

If the detector later sees the same preceding context and has the same secret key, it can reproduce the same result.

Step 5: Split the vocabulary into GREEN and RED sets

Using that pseudorandom result, the system divides possible tokens into groups.

For illustration:

GREEN                 RED

postpone              delay
reschedule            move
defer                 cancel
continue              announce
...

This split looks random to someone who does not know the key.

Also, postpone is not permanently green.

For a different preceding context, it might be red.

Step 6: Slightly boost GREEN-token probabilities

Now the watermark modifies the model's normal next-token scores.

Before watermarking:

delay        24%
postpone     22%
move         18%
reschedule   16%
cancel        8%
defer         5%

After the green tokens receive a small boost, the distribution might look conceptually like:

delay        20%
postpone     27%   <- GREEN, boosted
move         15%
reschedule   21%   <- GREEN, boosted
cancel        7%
defer         7%   <- GREEN, boosted

These numbers are only an example.

The system is not forcing the model to choose a green token.

A red token can still win.

It is only making green tokens somewhat more likely.

Step 7: Sample the next token

The model samples from the adjusted distribution.

Suppose it chooses:

postpone

The generated text is now:

The team decided to postpone

To a reader, there is nothing unusual about the word postpone.

It was already a perfectly reasonable next token.

The watermark exists only in the fact that choices like this are biased in a secret, statistically detectable direction across many generation steps.

Step 8: Repeat everything for the next token

Now the context has changed:

The team decided to postpone

So the watermark calculates a new pseudorandom partition:

hash("The team decided to postpone" + SECRET_KEY)

That produces a new green/red split for the following token.

For example:

GREEN                 RED

the                   our
until                 its
next                  this
...

The model generates another token, the context changes again, and the process repeats.

So generation looks like this:

The key point is:

context + secret key
        ↓
pseudorandom token partition
        ↓
slightly prefer one group
        ↓
sample normally
        ↓
repeat for every token

After one token, the difference is meaningless.

After hundreds of tokens, the repeated bias can become statistically detectable.

2.2 How KGW detection works

A detector that knows the secret key walks through the finished text token by token.

For each token it reconstructs the green/red set that should have existed at that point and checks where the actual token landed.

For 500 tokens, ordinary text might look roughly like:

Green: 247
Red:   253

while watermarked text might look like:

Green: 318
Red:   182

The exact numbers depend on the scheme. The important point is that no single word proves anything.

The detector is looking for a statistical bias across many choices.

2.3 Why paraphrasing creates a problem

Suppose the original is:

Heavy rain forced the organizers to postpone the concert.

Someone rewrites it as:

The outdoor show was delayed because of the downpour.

The meaning is similar, but the tokens are different.

A hash based on the exact previous tokens can now produce completely different green/red sets.

That is why basic token watermarks can weaken under paraphrasing.

This led to approaches that try to tie the watermark to meaning rather than exact wording.

3. Making watermarks more robust

3.1 SIR: Use meaning instead of exact wording

SIR stands for Semantic Invariant Robust Watermark.

Instead of relying only on exact preceding tokens, SIR creates a semantic embedding of the preceding text and uses that representation to produce watermark logits.

Conceptually:

"Heavy rain forced the organizers..."
                |
                v
         embedding model
                |
                v
       semantic representation
                |
                v
         watermark bias

Now take:

The outdoor show was delayed because of the downpour.

The words changed, but an embedding model may still place it near the original sentence because the meaning is similar.

So the idea becomes:

A small synonym change is therefore less likely to completely reset the watermark.

SIR is not paraphrase-proof. Heavy rewriting can still weaken the signal. It is simply designed to be more robust than a watermark that depends closely on exact token history.

3.2 Adaptive Watermark: Only watermark when there is room

There is another problem. Sometimes the model has many valid next-token choices. Sometimes it has almost none.

Consider:

The square root of 81 is

The next token should be 9.

The model cannot choose 8 just because it happens to be preferred by the watermark.

This is a low-entropy position: the probability distribution is concentrated on one or a few choices.

Now consider:

The movie was surprisingly

Possible continuations might include:

good
funny
moving
engaging
thoughtful
entertaining

This is a higher-entropy position. There is more freedom.

Adaptive Text Watermark uses this distinction:

It also uses semantic information from preceding text when adjusting logits.

So SIR and Adaptive Watermark are related but different:

• SIR: make the watermark more dependent on meaning.
• Adaptive: also decide when watermarking is safe/useful based on entropy.

4. Low-entropy text: Math and code

4.1 Why math is difficult

Math makes the entropy problem obvious.

15 * 4 =

There is one correct answer:

60

The watermark cannot safely push the model toward another token.

The same problem appears with exact facts, URLs, JSON structure, quotations, and other constrained outputs.

Watermarking has more room in ordinary prose because there may be many reasonable ways to express the same idea.

4.2 Why code is difficult

Code contains many highly constrained tokens.

for i in range(10):
    print(i)

The model cannot freely replace for, in, parentheses, the colon, or indentation. A bad choice may break the program.

Other positions have more freedom:

user_count
customer_count
total_users
count

Comments can also be phrased in several ways.

The important point is not that watermarking must rename variables. It is that some code positions have much more entropy than others.

4.3 SWEET: Selective watermarking for code

SWEET, Selective WatErmarking via Entropy Thresholding, was designed for code generation.

It avoids watermarking low-entropy positions and focuses on positions where the model has more choice:

That reduces the chance of damaging code just to preserve a watermark.

4.4 EWD: Give useful tokens more weight during detection

EWD, Entropy-based Text Watermarking Detection, works mainly on the detection side.

Instead of treating every token as equally useful evidence, it gives more weight to high-entropy tokens.

A token chosen from ten plausible alternatives tells the detector more than a token that was almost forced by syntax.

4.5 Invisible Entropy: Estimate token flexibility cheaply

Entropy-aware methods can create another problem: calculating exact entropy may require access to the original model and its full probability distribution.

Invisible Entropy proposes a lightweight entropy tagger that predicts whether a position is high or low entropy.

The goal is to get the benefit of entropy-aware watermarking without running the full frontier model again just for detection.

5. Other watermarking approaches

5.1 DiPmark: Preserve the original distribution

If watermarking keeps changing token probabilities, another question appears: does it subtly change the model's writing distribution?

DiPmark explores a distribution-preserving approach.

It still uses randomized token reweighting, but is designed so that, averaged over the watermark randomness, the original token distribution is preserved.

The broader goal is:

Google's published SynthID-Text also tackles production text watermarking, but it is not simply KGW. It uses a technique called Tournament sampling and can operate in a non-distortionary configuration.

Why sentence-level methods can survive more editing

Token-level methods fit normal LLM generation well because models already generate token by token.

But researchers have also tried watermarking larger semantic units.

5.2 SemStamp: Watermark at sentence level

SemStamp works at the sentence level.

Candidate sentences are converted to semantic embeddings, and the system favours sentences that fall into selected regions of semantic space.

That can make the watermark more resistant to word-level paraphrasing because the signal is connected to the sentence's semantic representation rather than individual token choices.

The downside is generation complexity. A streaming chatbot wants:

A sentence-level method may need to generate and evaluate a candidate sentence before sending it.

That is harder to combine with low-latency streaming.

5.3 PostMark: Add the watermark after generation

PostMark goes further. It is a post-hoc watermark.

The model first generates the text, then PostMark uses semantic information to insert an input-dependent set of words.

It does not need access to the model's logits, which is useful.

But the text must exist before the watermark is applied, again making the deployment model different from token-by-token streaming.

6. Can watermarks be defeated?

6.1 Paraphrasing and rewriting

Watermarks are not indestructible fingerprints.

A useful way to think about robustness is:

Semantic approaches such as SIR and SemStamp try to improve this, but enough rewriting eventually changes the sequence or semantic structure the detector expects.

6.2 Secret-key leakage

For keyed schemes, the secret key helps determine the hidden pattern.

If that key leaks, an attacker may be able to predict the watermark and intentionally avoid or forge it. A real deployment therefore needs key rotation and access controls, not just a clever algorithm.

6.3 The public-detector problem

A public detector creates another trade-off.

Someone could repeatedly test:

That feedback becomes an oracle for learning which edits weaken detection.

Keeping the detector private makes that harder, but also makes independent verification harder.

7. So what is actually inside the text?

Usually, nothing visibly special.

No logo.

No required metadata.

No hidden phrase saying "AI generated."

The signal can simply be spread across ordinary token choices:

That is why copying and pasting the text can preserve the watermark.

The hard part is balancing several things at once: detection, text quality, robustness to editing, security of the key, low false-positive rates, and the latency requirements of a model that is streaming tokens in real time.

That is the engineering problem hiding behind the phrase "invisible watermark in text."