Stable Diffusion watermark remover, examined

The term covers two mechanisms with no relationship to each other. One is an overlay drawn onto the visible image by a hosted platform at export. The other is a signal written into the image's frequency coefficients by the reference implementation itself, invisible by construction and unaffected by anything done to the visible picture.

A commercial page read closely for this term addresses the first exclusively and does not mention the second anywhere on it. That is not a small omission. A reader worried about provenance signals and a reader annoyed by a corner logo are asking different questions, and a page that answers only one of them silently misleads the other.

The reference code calls the invisible-watermark library. The encoder is constructed, the payload is set as UTF-8 bytes, and a put_watermark call applies it during generation in txt2image.py. The payload in the CompVis reference implementation is the literal string StableDiffusionV1.

The library's documented methods are dwtDct, described as a DWT and DCT transform embedding a watermark bit into the maximum non-trivial coefficient of each block's DCT coefficients, dwtDctSvd, which adds an SVD decomposition of each block, and RivaGAN, a deep learning model the project describes as trained from the Hollywood2 movie clips dataset. Its worked examples use 32-bit and 64-bit payloads. None of this is proprietary or obscure, which makes its absence from the commercial pages a choice rather than an oversight.

dwtDct

Frequency-domain embedding into block DCT coefficients after a wavelet transform. The cheapest of the three and the default shape of the technique.

dwtDctSvd

The same transform with a singular value decomposition per block. Behaves similarly under the library's published robustness tests.

RivaGAN

A learned watermarking model. Notably, the only one of the three that survives a small crop in the project's own results table.

The edit runs in our media workflow, from the panel above.

Step 1

Classify the mark. Visible overlay, invisible payload, or a learned signature artefact from a custom checkpoint. Only the first and third are image edits.

Step 2

Upload one file. Detection and the edit run together and the output is a re-rendering of the image, not the original with reconstructed pixels laid over the corner.

Step 3

Compare at full resolution across the covered region. Regeneration error concentrates in structured content: text, hands, faces, repeated geometry.

The library publishes its robustness position directly: the methods are not robust to resize or aspect-ratio-changed crop, but are robust to noise, colour filter, brightness and JPEG compression. That ordering surprises most people, because the operations that feel destructive are the ones the mark tolerates.

Its results table records JPEG compression passing for both frequency methods, a 50% resize failing for both, rotation failing for both, and a 7 by 5 crop failing for the frequency methods while RivaGAN passes it. The project also states a known defect: all algorithms perform poorly on web page screenshots and on posters with a homogeneous background colour, which is to say the technique depends on there being image content to hide in.

Our workflow regenerates the file. It re-renders the image rather than lifting a marker off the original, so the artefact you download is a new rendering of your picture. That is the mechanism and it is also the selling point, because reconstruction of a covered region is a generative operation whichever way it is described, and describing it as erasure would misrepresent what comes back.

The boundary follows from the mechanism. No guaranteed clean result on any given file. No statement about what any decoder will report about the output, ours or a third party's, including Google's. A page that promises a specific verdict from someone else's detector is asserting something about a system it does not control and cannot observe.

Where generation happened on your own machine, no hosted platform applied an overlay, and the invisible step in the reference script is two function calls that can be commented out. Public forks exist for exactly that purpose, and the CompVis issue thread shows the change being made.

One honesty note that the issue itself forces. The person who filed it asked whether anything else in the codebase marks the output, and the thread contains no definitive answer. We are not going to supply one on their behalf, and a page that answered that question confidently would be inventing the answer.

No competing page fetched for this route carries a legal caveat of any kind. Removing a watermark confers no right to use an image, and modification is prohibited outright under many licences. Where a mark exists to enforce terms, deleting it alters the file and leaves the terms exactly where they were.

The intended case here is your own generated output on a platform whose export mark you may remove. Everything else is a different activity, and this page is not written to support it.

Where the problem is compositional. A corner logo that cannot sit inside a layout, a free-tier export mark on an image you generated yourself, a phantom signature a custom checkpoint keeps drawing because its training data was full of signed work. In each case the target is visible, the ownership is yours, and reconstruction of a small region is a reasonable ask.

Where it is the wrong instrument: any question about provenance signalling. That question is about the invisible layer, it is not answered by editing the picture, and the useful material on it is the library's own documentation rather than a tool page.