What AI watermarking actually is, in plain words

People ask this tool one question more than any other: does cleaning up invisible characters make AI-written text undetectable? No. This post explains why, because the reason matters more than the answer.

Two different things people call "watermarking"

The word "watermarking" covers at least two unrelated ideas, and mixing them up is where most confusion starts.

The first is a marking attached to a file: a photo's EXIF data recording the camera and software that produced it, or a C2PA content credential embedded in an image or video that states its provenance. These live in file metadata or in the pixels themselves, sit outside the visible content, and can in principle be inspected, stripped, or forged depending on the format and how carefully the marking was implemented. This tool does not touch any of that. It has no code path that reads or writes EXIF, XMP, or C2PA data, on purpose, because that is a file-provenance question and this is a plain-text tool that never sees a file's metadata at all.

The second is what people usually mean when they talk about AI text watermarking, and it works completely differently.

How a text watermark actually gets embedded

A large language model does not write one word at a time in the way a person does. At each step it produces a probability distribution over its entire vocabulary, meaning a ranked list of every token it could plausibly say next, and then samples one. One well-documented approach to watermarking intervenes at exactly that step: before sampling, it splits the vocabulary into a "green list" and a larger "red list" using a key derived from what came before, and nudges sampling to prefer green-list tokens slightly more often than pure chance would. Do that consistently across a whole document and the finished text carries a statistical skew that would be vanishingly unlikely to occur if the words had been chosen without that nudge.

The important part for this discussion: that skew lives in which words the model chose, at the moment it chose them. It is not a character sitting in the text. There is no U+200B hiding between two words that a watermark detector reads back out. By the time you have the finished text in front of you, the "watermark" is the whole sequence of word choices, not an addition to it, which is a fundamentally different kind of thing from an invisible Unicode character that a cleaner can locate and remove.

We are describing one documented approach here, not asserting how any specific deployed system works today, because that detail is usually not published and we have not verified it for any named product. If you are relying on a claim about a specific detector's method, get it from that detector's own documentation, not from us.

Why cleaning invisible characters cannot touch this

This tool's whole job is normalizing typography: turning curly quotes into straight ones, resolving stray em dashes, and stripping zero-width characters that were never supposed to be visible in the first place. Every one of those operations changes characters, never which words were chosen. A statistical watermark embedded in word choice survives every one of those operations completely intact, because none of them touch word choice at all. Removing a zero-width space does not undo a word-selection bias that was never expressed as a character to begin with. There is nothing in this tool's rule table that could remove it even if we wanted it to, since removing it would require rewriting the prose itself, which this tool deliberately does not do.

This is also why we do not build a "make this undetectable" mode behind a flag, however it might be requested. Paraphrasing text specifically to defeat a detector, or iterating rewrites against a detector's output until it stops flagging something, is a different kind of project with a different purpose, and it is not the purpose stated on this page. Normalizing punctuation that a chat interface left behind is copyediting. Deliberately reshaping wording to evade a detection system is not the same category of activity, regardless of how similar the input and output might look side by side.

What a detector result actually tells you

A detector score is a statement about writing style and statistical patterns in word choice, not about invisible characters, not about file metadata, and not something this tool has any influence over in either direction. We are not in a position to say how accurate any particular detector is, because detector accuracy depends on the model being checked against, the detector's own tuning, and the text's length, none of which we control or have tested. What we can say plainly: this tool does not change wording, so it does not move that score, and anyone telling you a Unicode cleaner will beat a watermark detector is describing a different tool than this one.

Where that leaves this tool

The honest scope of a typography cleaner is: invisible characters that break search and diffs, spacing that breaks how a document wraps, and curly punctuation swapped for the plain kind, if you ask for it. None of that touches whether a detector flags a document, and none of it touches provenance metadata attached to a file. That is a narrower claim than "make your AI writing undetectable," and it is the only claim we are willing to stand behind.