Why a file sometimes comes back unchanged
The tool would rather hand your file back untouched than alter a corner it cannot identify. That is a deliberate choice, not a shortfall, and each way of reaching it has a specific cause and usually a specific fix.
The choice behind it
A watermark remover can be built two ways when it is unsure.
It can produce something regardless. Blur the corner, patch it, ask a model to invent something plausible. This always returns a file, which feels like success, and it occasionally returns a file with a smeared or ghosted corner that you do not notice until the image is already somewhere public.
Or it can decline. You get your file back and a message explaining what happened, and you are never handed damage described as a result.
This tool declines, and the reason is that the method makes declining possible. Because the removal is an inverse of a known operation, its output can be checked: a correct removal leaves a corner statistically indistinguishable from its surroundings, and a wrong one leaves a seam. A generative approach has no equivalent test, because there is no correct answer to check against.
The gates a file has to pass
Detection produces candidate positions, and each is scored before anything is committed. Two independent things have to be true.
The shape has to match. The region has to correlate with the known mark. This is what rules out a corner that happens to be bright, or busy, or roughly the right size.
Something has to actually be there. Correlation alone is not enough, because a search that tries thousands of placements and keeps the best one scores respectably even on footage containing no mark at all. On an unmarked clip the best placement typically scores between 0.19 and 0.23, which is enough to fool a naive threshold. So a second measure, how strongly the region is actually darkened or lightened, has to clear its own floor.
For calibration: a clip that genuinely carries the mark scores around 0.87 at the right position, and a clip whose mark has already been removed peaks around 0.3 everywhere. The gap between those is what a confident decision is made from.
The common causes
It is a screenshot
This is the most frequent cause by a wide margin. A screenshot is a photograph of a rendering: the image has been scaled to fit a window, resampled at whatever ratio the display was using, and re-compressed on the way to disk. The mark's edges are softened and its size matches no catalogue entry.
The fix is to use the original download rather than a capture of it.
It has been cropped or resized
Both break the relationship between the file's dimensions and the mark's position. A crop of the bottom or right edge changes the inset directly. A resize scales the mark to a size no variant uses. The anchor search absorbs offsets of a few pixels, which covers a small trim, but it works from a prediction and the prediction comes from the dimensions.
Clean first, then crop. The order matters and it is free to get right.
It has been re-compressed
Saving through another application, uploading to a platform, or receiving a file through a
messaging app all re-compress it. The removal divides by 1 − α,
which approaches zero near the solid centre of the mark, so error introduced by
re-compression gets amplified there. Enough of it and the verification step correctly
concludes the result is not clean.
The mark sits over a difficult background
Two backgrounds are genuinely hard. Where the underlying pixels were already bright, the mixture of bright original and bright logo can exceed what a colour channel can store and get clipped, which destroys information that no arithmetic recovers. And for the opaque NotebookLM wordmark over a dark photo, the mark becomes a faint lightening rather than a darkening and the detector does not see it at all.
It is not a mark this tool knows
The method needs the artwork and the alpha map. It has them for the Gemini sparkle, the Veo mark and the NotebookLM wordmark. Given a watermark from another product, there is nothing to invert, and the tool stops rather than falling back on a generic patch.
There is no mark left
A file that has already been cleaned has nothing to find. So does a generated image that never carried a visible mark in the first place, which some generation paths produce. The page says no watermark was found, which in this case is simply true, and re-encoding a video to report success would cost a generation of quality for nothing.
Working out which one you have
- Check the dimensions. If they appear in the catalogue of official Gemini output sizes, the file is unmodified and the cause is elsewhere. If they do not, it has been cropped, resized or captured.
- Check the format. A file that arrives as JPEG when Gemini would have produced PNG has been through something.
- Look at the corner. If you cannot clearly see the mark yourself, the detector is unlikely to do better.
- Find the original. Almost every cause above is solved by the original download, and none of them is solved by trying the same derived file again.
If the original download itself is refused, and its dimensions are in the catalogue, that is worth reporting. It usually means a new layout or alpha variant has appeared, which is the kind of thing that gets added.
The residue case
Slightly different from an outright refusal: the file comes back changed, but something is still faintly visible where the mark was.
This normally means the position was right and the strength estimate was not quite, or the input carried enough compression noise that the division amplified it. For video it can also mean the clip fades, so the mark's strength varies frame to frame and one frame in the fade was estimated slightly off.
The remedy is the same as everywhere else on this page: start from the original, at the highest quality you have, before any other tool has touched it.