Guide

We removed a watermark from a PDF. Here is what it left behind.

Thousands of people a month search for how to remove a watermark from a PDF. Far fewer ask the question that matters afterwards: what does the removal leave behind? We ran the experiment — one watermarked document, three removal methods, every version through our forensic API — and published exactly what survived. If you rely on documents other people send you, this is what a missing watermark looks like from the other side.

By Stipple Research12 min readUpdated 23 August 2026
Key takeaways
  • Removing a watermark the way most people do it — editing the PDF and saving — leaves a structural trail: multiple file revisions, objects redefined across revisions, and post-creation modification metadata.
  • Stipple’s document inspection surfaced that trail as quotable evidence on our test file: the report records the revision history and the modification provenance, which is exactly the question to ask of a document whose watermark is missing.
  • One method leaves no trail in the file itself: a careful full rewrite. Structural forensics cannot promise to catch it — which is why provenance metadata alone is never verification.
  • Watermarks fail as security the moment they are treated as proof: they mark the honest copy, not the dishonest one. Treat a watermark as a label, and its absence as a question.
  • The experiment is reproducible: generate, remove, inspect. We describe every step so you can run it on your own documents.
Evidence path
  1. 01

    Watermark a document

    Start with the material.

  2. 02

    Remove it three ways

    Add one more signal.

  3. 03

    Inspect every version

    Add one more signal.

  4. 04

    Read what survived

    Add one more signal.

  5. 05

    Draw the honest line

    Make a careful call.

01

The question nobody asks after removing a watermark

Short answer

Whether the removal can be seen. In the most common removal path — open the PDF, delete the watermark, save — the answer in our experiment was yes: the file keeps a structural record of having been edited, and forensic inspection surfaces it. In the careful path — a full clean rewrite — the file-level answer is no, which is exactly why document verification can never rest on metadata alone.

Search interest in removing watermarks is enormous and mostly mundane — draft stamps on your own documents, template markings, tool branding on output you paid for. This article is not about whether you can remove a watermark. You can; dozens of tools will do it. It is about the question that matters to everyone downstream: when a document arrives without the watermark it should have, or with a history it does not admit to, what does the file itself still say?

We could not find a published experiment that answers this concretely for PDFs, so we ran one: create a watermarked document, remove the watermark by the methods people actually use, and put every version through forensic inspection. What follows is the full setup and the actual findings, so the result is checkable rather than asserted.

Why we care is not hidden: we build the inspection tooling, and a determination published by Australia’s financial ombudsman this June — the companion piece to this article — turned on exactly this class of artifact. The complainant’s documents carried the generating tool’s own marks; the ombudsman spotted them and declined to rely on the documents. The obvious next question was: what happens when the marks are removed?

02

The experiment: one document, three removals

The test document mimics the AFCA case’s shape: a one-page call-transcript PDF carrying a tool watermark in three places — a diagonal “TRANSCRIBED BY AI MINUTES” overlay, a “Notes created … by AI Minutes” attribution line, and per-utterance confidence percentages in the body.

We then removed the watermark three ways, in increasing order of care:

  • Edit-and-save (the common path): open the PDF, redact the watermark text, save. Desktop editors typically save this way — appending the change as a new revision while the original bytes remain in the file’s history chain.
  • Clean rewrite (the careful path): rebuild the document into a fresh file containing only the final content. No prior revisions exist, because the file is genuinely new.
  • Re-render (the launderer’s path): rasterise the page to an image and wrap it in a new PDF. Everything textual about the original — including its text layer — is gone.
03

What the inspection actually found

Short answer

On the edit-and-save version, the inspection report captured the removal trail: the PDF records multiple revisions, objects redefined across revisions, and post-creation modification provenance — the structural fingerprint of a file that has been changed since it was made. On the clean rewrite, no file-level trail exists to find. On the re-render, the inspection correctly saw a picture of a document rather than a document.

The edit-and-save result is the finding that matters, because it is the path most removals take. Quoting the inspection evidence on our test file: the report recorded that the “PDF was saved across multiple revisions (incremental updates)”, with “objects redefined across revisions” — supported by the file’s own %%EOF revision markers and cross-reference chain — alongside provenance noting the document “carries post-creation modification” with its producing software and dates. A reviewer reading that report knows, from the file alone, that this document is not in its original state. Paired with a watermark that should be there and is not, that is precisely the discrepancy worth escalating.

Two honest notes on the same result. First, the trail says edited, not why: incremental saves are also how ordinary, legitimate edits land, so the inspection surfaces the history as evidence for a reviewer rather than branding the file fraudulent — a design choice, because a modification record is a fact and fraud is a judgement. Second, on our synthetic file the overall risk band stayed low: a one-page fabricated transcript gives the content and arithmetic checks little to work with, so the structural history was the evidence, and the evidence is what a reviewer quotes.

The clean rewrite is the boundary, and we are stating it rather than burying it: a fresh file has no revision history, and nothing inside the file proves a watermark ever existed. What remains in that case sits outside the file — the mismatch between the document’s claimed origin and its actual producing software, the absence of marks its claimed source always applies, cross-checks against the counterparty’s copy — checks that need context a single file cannot supply.

The re-render is almost self-defeating: stripping a PDF to an image discards the text layer that makes a document machine-readable, and an all-image “statement” or “transcript” is itself the anomaly. Inspection treats it as a scan and says so.

04

What a watermark actually proves — and what its absence asks

The deeper lesson generalises well beyond our one-page test file. A watermark is a label, not a lock. It marks the copies made by honest tools and honest workflows; the one document it cannot mark is the one someone chose to clean. This is the same asymmetry provenance systems face everywhere: presence of a mark is meaningful evidence of origin, absence of a mark proves almost nothing on its own.

That asymmetry is why the practical question flips for anyone receiving documents. Do not ask “does this carry a watermark?” — ask “is this document’s history consistent with what it claims to be?” A bank statement claiming to come from a bank’s system but produced by a desktop editor; a “scan” with no capture metadata; a transcript whose file was revised after its stated creation date — each is the removal question in a form a file can actually answer.

The AFCA case shows the human version of this working: three artifacts the tool left in, spotted by an attentive ombudsman. The gap this experiment measures is what happens when the next submitter is less considerate — and the answer is that the common removal path still tells on itself structurally, while the careful path moves the contest to context, where single-file forensics honestly ends.

05

Run the experiment yourself

Nothing here requires our word for it. Take a PDF of your own, note a visible watermark or stamp, remove it with whatever editor you normally use, and inspect the result — with our tool or any forensic reader that shows revision structure and modification metadata. If your editor saved incrementally, you will find the trail exactly as we did.

For the receiving side, the workflow is one upload: the inspection reads structure, provenance, arithmetic and content together, and returns its findings as named evidence you can quote in a review note — which, as the AFCA determination shows, is the form a refusal ultimately has to stand on.

Questions

Frequently asked questions

Can removing a watermark from a PDF be detected?

Often, yes — in our experiment, the common removal path (edit the PDF, save) left a structural trail the inspection surfaced: multiple file revisions, objects redefined across revisions, and post-creation modification metadata. A careful full rewrite leaves no trail inside the file, which is why absence of evidence is never proof of an untouched document.

Does Stipple detect watermark removal?

Stipple surfaces the traces removal leaves: the revision history, the redefined objects, and the modification provenance, reported as quotable evidence on the inspected file. On the careful clean-rewrite path there is no in-file trail for any tool to find — we say so plainly — and the check shifts to consistency between the document’s claimed origin and its actual production history.

Is it illegal to remove a watermark?

It depends entirely on context and jurisdiction — removing a draft stamp from your own document is ordinary; removing marks to misrepresent a document’s origin or status can be fraud, and in some contexts removing rights-management information carries specific legal consequences. This article is about detection, not legal advice; if the stakes are real, ask a lawyer.

Why did the risk score stay low if the file was edited?

Because an edit record is a fact and fraud is a judgement. Incremental saves are also how legitimate edits land, so the inspection reports the modification history as evidence rather than treating every edited file as suspect. On our synthetic one-pager, the structural history was the meaningful output — a reviewer pairing “modified after creation” with “the watermark that should be here is missing” has exactly the discrepancy that warrants escalation.

What about watermarks in AI-generated text rather than documents?

Different mechanism, same asymmetry. Statistical text watermarks are embedded in generated words and survive copy-paste to varying degrees, but their absence proves nothing — most AI text carries no watermark at all. Our AI text watermark guide covers that side in depth.

Can I reproduce this experiment?

Yes. Generate a watermarked PDF, remove the watermark with a normal editor (which typically saves incrementally), and inspect the file — with our verifier or any tool that reads PDF revision structure. The trail described here is a property of how PDF saving works, not of our test file.

Sources

Sources and further reading

  1. 01AFCA determination 12-25-282452 — the real-world companion case (tool artifacts spotted by the ombudsman)
  2. 02PDF 2.0 specification (ISO 32000-2) — incremental updates and file structure
  3. 03C2PA — content provenance and authenticity specification
  4. 04Stipple — document inspection (the tool used in the experiment)

Educational guidance, not a forensic certification. Detection technologies and standards change; review material decisions against current evidence.

See what a document’s history says

Upload a PDF and the inspection reads its structure, provenance and arithmetic together — revisions, modification metadata, and the discrepancies worth escalating, as evidence you can quote. Free credits weekly, no card.

Inspect a document