How I Removed AI Watermarks From Everything I Publish

Anthropic recently announced it will start watermarking AI-generated content, and every other major model provider is already doing the same thing, quietly, in ways nobody outside those companies fully understands. I spent weeks digging into how AI watermarking actually works and built a free, open cleaner for it: WMC Cleaner. Here is what building it taught me about certainty, adversarial review, and why the honest limit of a claim matters more than the claim itself.

Why this matters

If you publish anything written with AI help, from a blog post to a client deliverable, you are shipping content that carries traces you did not choose to leave. Invisible Unicode characters, a statistical lean toward certain words, metadata baked into every image. Regulation in Europe and China is already pushing providers toward mandatory watermarking, so this is not a niche concern, it is becoming the default state of AI-assisted publishing. The founders and builders I coach are used to shipping fast with AI. What most of them have not thought through is what that content is quietly carrying, and what it actually takes to fix that honestly instead of just papering over it.

#1: You cannot promise 100% watermark removal, so say that up front

Nobody outside the model providers knows exactly how their watermarking works. Anthropic's announcement described a statistical lean, a quiet pull toward certain words in a sentence like "the results were really ___", plus invisible Unicode and hidden formatting characters layered on top. As long as the underlying method stays undisclosed, no tool, including the one I built, can certify that it caught everything.

So WMC Cleaner is built around four separated layers, each with an honest guarantee instead of one blanket promise. Characters and typography are deterministic and verifiable. Image and document metadata is stripped losslessly, provable with a byte diff. AI phrasing gets flagged for a human to rewrite, never auto-rewritten mid-sentence. The statistical writing pattern, the hardest layer, gets an optional DeepL back-translation step with a plainly stated limit: it changes wording, which is what degrades the pattern, but it cannot certify that any vendor's detector will fail afterward.

Layer	What it does	Guarantee
Characters and typography	Strips invisible Unicode and formatting marks	Deterministic, verifiable
Image and document metadata	Removes embedded metadata losslessly	Byte-diff provable
AI phrasing	Flags cliché phrases and sentence shapes	Human review, never auto-rewritten
Statistical writing pattern	Optional DeepL back-translation	No certification possible, stated plainly

The pattern I see in the founders I coach is a discomfort with saying "I don't fully know" about their own product. It reads like a weakness. It is actually the opposite: stating the honest limit of a feature in the same breath as the feature is what makes every other claim you make about that product trustworthy. The portable rule: certainty is the tell of someone who has not thought hard enough about the problem.

#2: Don't fight a fingerprint with another fingerprint

Most existing watermark cleaners rewrite AI text with another large language model. That is the obvious fix, and it is also the trap. The rewriting model has its own statistical lean, its own fingerprint, so you end up trading one watermark for a different one, or worse, layering several on top of each other.

The reasoning that shaped the decision: two things must go, the invisible Unicode and the statistical pattern. A translation model doing back-translation is structurally different from a model doing generation. DeepL translates, it does not try to write like anything in particular, so pushing text through it and back disturbs the pattern without stamping in a new one. Before stating that as fact anywhere public, it needed real verification, not an assumption. Research confirmed it held up for plain text; the one caveat found, a visible attribution label on translated documents, applies to a completely different, document-only API and does not touch how the tool uses DeepL.

I see the same instinct show up outside code constantly: when something is broken, reach for a version of the same tool that broke it. A founder whose messaging sounds generic hires another generic-sounding copywriter. The fix has to be structurally different from the thing that caused the problem, not just a better version of it. The portable rule: before reaching for a fix, ask whether it leaves a trace of the same kind as the problem. If it does, it is a swap, not a fix.

#3: A first version always has bugs a second, adversarial read catches

I built WMC Cleaner solo, then asked for the most critical review I could get before anything went public. That single pass surfaced three bugs I had not seen from using the tool normally: image cleaning was silently recompressing JPEGs and losing GIF frames on every run, a character required by Persian and other scripts was being stripped as if it were a watermark, and an auto-delete step for AI phrases could cut a sentence mid-word and leave a broken fragment behind. None of these were visible from the outside. They only showed up when someone read the code asking "what happens to a user who does not check the diff."

If I am honest about what I would do differently, it is commit more often. Mid-build, an unrelated Claude Code session running in the same folder made an ordinary commit that discarded a whole afternoon of uncommitted fixes across roughly 25 files. Nothing was lost only because the work could be reconstructed from memory, and that is luck, not a plan. Commit early, even before you are ready to push, because "I will commit once it is clean" is exactly the belief that turns an afternoon of work into something you have to rebuild from memory.

The portable rule: a tool only looks finished from the inside. The bugs that matter are the ones a second, adversarial read finds by asking what breaks for the person who trusts it by default.

#4: Two AI reviewers beat one, but only if you argue with both

After the first critical pass, I ran a second, independent review with a different model, Gemini, and treated its feedback the same way: not as an instruction to execute, but as a claim to interrogate. Every point got the same two questions. Is it real, and what actually breaks for a user if it is ignored.

Some of it needed sharpening, not accepting as-is. Gemini's fix for a code-block bug was to skip every rule inside code entirely, but that would have also disabled the invisible-character check inside code, which is the exact Trojan Source attack the tool exists to catch. The refined version split the rule engine by layer: typography and voice rules skip code and frontmatter, the character layer keeps running everywhere, always. When a second round of feedback arrived with actual code attached instead of just a description, both patches got run through the existing test suite and the parity check before being accepted, never merged on the reviewer's authority alone. Two proposed banned phrases got read aloud in an ordinary sentence before either got added to the rulebook: one was normal English with no real tell, so it was dropped entirely; the other had a genuine AI-cliché flavor, so it was kept, downgraded from a hard block to a warning.

The pattern I see in teams that treat AI code review as a rubber stamp: the review happens, gets logged as "reviewed," and nothing about the decision-making actually changed. The value was never in getting a second opinion. It was in checking every point against the real code and against a concrete, human consequence before it was allowed to change anything. The portable rule: an AI review is a second claim to test, not a verdict to execute.

#5: Positioning is the actual distribution channel, not a footnote

Partway through hardening the tool, I compared it honestly against a competing project. The comparison surfaced something the code review never would have: a narrower, less-featured watermark remover had hit 3.851 stars in two days, purely by shipping as an installable Claude Code Skill instead of a terminal-only CLI.

That reframed what "finished" meant for this project. I built a matching Skill: an inspect-first workflow where an agent runs a check, shows the findings grouped by layer, and only fixes anything after a human confirms. The safety of that workflow was not the point I set out to build, it fell out of asking "how should an agent be allowed to use this," and it turned into the same distribution move the competitor had already made.

I ask founders I coach to name a real, comparable competitor before evaluating their own positioning, not an abstract "industry standard." A generic "how could we be better" question invites a generic answer. Naming an actual rival forces a specific, checkable one, and the specific one is usually where the real gap is hiding. The portable rule: benchmark against something real, because a hypothetical competitor never tells you the thing that is actually costing you distribution.

What is next

WMC Cleaner is live and free, the Python and Node CLIs, the pre-commit hook, and the Claude Code Skill are all in the repository linked from the video for this episode. If you want to see the full breakdown of the watermarking mechanism, layer by layer, walk through the interactive build. This episode pairs naturally with the human voice rulebook I built earlier, since sounding human and not carrying a fingerprint are two sides of the same publishing problem, and both matter for how AI-assisted content gets positioned once it is out in the world. If you are shipping AI-assisted content at any real volume and want a second, critical read on how you are doing it, that is the kind of question I dig into in product coaching.