We tested this site's tool on a 1024×1024 image — the default output size of the current Nano Banana models — and it failed. It put the watermark box in the wrong place, and the result came out worse than the input. So this page does not claim the tool works on Nano Banana images. It does not, at that size, as of this test.
What follows is the full measurement: what we ran, the numbers it produced, the cause we traced it to, and what the official Google documentation says about Nano Banana output sizes in the first place. If you came here looking for a tool that says yes, this is not that page. If you want to know what actually happens, it is below.
Why 1024×1024 is the size that matters
This is worth stating first, because it is the reason the test was run at that size and not at some arbitrary one. Google's own developer documentation for the current Nano Banana models lists the supported output resolutions, and 1K means 1024×1024 pixels:
- Nano Banana 2 Lite (
gemini-3.1-flash-lite-image) is described as optimized for lower resolutions of 1K (1024x1024px), with supportedimage_sizevalue1024px. The same page notes that 2K and 4K are unsupported on that model. - Nano Banana 2 (
gemini-3.1-flash-image) lists new output resolution options — 0.5K, 2K and 4K — with a default of 1K.
So 1K is not an edge case. On the lite model it is the only resolution; on the standard model it is the default. A tool that cannot handle a square 1K image cannot handle the most common Nano Banana output there is. That is why the test targeted it.
What we actually tested, and the one honest gap in it
One limitation has to be stated up front rather than buried, because it affects how much the result proves.
We did not have a genuine Nano Banana generated file to test with. The machine this site is built on has no route to an image-generation model, by design, so a real model output could not be produced. Nobody should read what follows as "we tested your exact file". We did not.
What we tested instead is the part the tool actually depends on. The removal is a single arithmetic operation:
original = (watermarked − alpha × logo) / (1 − alpha)
That depends on exactly three inputs: where the watermark box sits (its geometry), the alpha template captured from the real mark, and the file's format and bit depth. The model changes what is underneath the watermark; it does not change those three things, and the content underneath differs pixel by pixel in every image anyway. So a composited test image exercises the same three variables a real one would — and has the advantage that the original is known, which lets the result be scored against ground truth instead of eyeballed.
The test image was built at 1024×1024 with a mid-tone scene, because real generated
images are mostly mid-tone, and mid-tone is the hard case: on this image the watermark's contrast against the
background was 53 levels, against 92 on the near-black image used for the
earlier acceptance test. The 96 px alpha template was composited into the bottom-right at
(736, 736, 96) — the large-image geometry.
The result
The tool was run in a real browser through the page's own upload control and its own download button — no test hooks, no modified engine. It reported:
1024×1024 · V2 template · logo 36 px · margin 82/81 px · alignment 0.37
The first signal is that alignment 0.37 figure. The same tool on the 1536×1152 image used
for its acceptance test reports 1.00. An alignment score is a correlation between the template
and the pixels it is sitting over; 0.37 means it is not sitting over the watermark at all.
Scoring the output against the known original confirmed it. Five numbers, in order of how much they say:
- Correlation before removal: 0.3706. The template does not line up — the box is in the wrong place.
- Correlation after removal: −0.2871. Negative. The operation painted a false pattern rather than cancelling the real one.
- Pixels inside the box off by more than one level: 535 of 1296 — 41%. Nearly half of the area it touched is wrong.
- Largest error inside the box: 73 out of 255. Visible, not marginal.
- Largest error outside the box: 56 out of 255. The real watermark was never touched. It is still there, in the area the tool ignored.
Visually, the result is a faint star shape in the bottom-right added by the tool, in a scene that previously showed only a soft, low-contrast mark. That is the part worth repeating plainly: on this image, running the tool made the picture worse than leaving it alone.
Where the error comes from
We traced it rather than guessing. The real watermark was at (736, 736, 96). The tool looked at
(906, 907, 36). Correlating the input against each position separately gives
0.9948 at the true location and 0.3706 at the one the tool chose.
So the alpha template is fine — it matches the real mark almost perfectly. The geometry is what is wrong. The tool selected its small-image branch, which assumes the picture was scaled down from a 2752 px reference, and computed a 36 px logo at a 71 px margin. Square 1024 satisfies neither the "large" condition nor the assumptions baked into the "small" one; it sits in the gap between them.
This is not specific to Nano Banana. Any 1024×1024 image hits the same branch, whatever generated it. And it is a direct consequence of the tool having only ever been verified at one size: the earlier acceptance test used 1536×1152, which takes the other branch. One branch was tested; two exist.
We have not changed the removal engine. The fix touches the geometry logic that the passing 1536×1152 test also depends on, so it needs a full regression across both sizes before it ships, not a quick patch. Until that happens, the honest statement about this site's tool is the one at the top of this page.
What the other pages in this search do not tell you
This is the part we looked at before writing, since it determines what is worth adding. The results for this kind of query are mostly of two kinds: free browser tools with a drop zone, and video or blog walkthroughs. A recurring pattern across them:
- Resolution is assumed, never measured. Several tools state their watermark-size rule in their own FAQ as a dimension threshold — 48 px below some size, 96 px above it. A square 1024 image sits on the boundary of exactly that kind of rule. We could not find one that reports what happens at the boundary, or that publishes a specific dimension at which it works.
- "Pixel-perfect" and "lossless" are asserted without a number attached. A correlation score, a maximum per-channel error, or a comparison against a known original would settle it in one line. None of the pages we read carried one.
- The invisible mark is sometimes folded into the pitch. SynthID is not a second layer a pixel-editing tool can address. Where a product lists it as a feature or a paid tier, the claim is doing work that the technique behind it cannot do — see our separate write-up on why SynthID cannot be removed.
- Nobody distinguishes "the visible mark is gone" from "the file is untraceable". Those are different claims with different evidence. We keep them apart, and the page on what the rules actually target covers the second one.
We are describing a pattern, not naming sites, and we are not claiming anyone is acting in bad faith. The point is narrower and more useful: a page that will not state the resolution it was tested at has not told you whether it was tested at yours.
What you can do with a Nano Banana image instead
These are general suggestions, not routes this site's tool has been verified on. We have not tested the tool against a real Nano Banana file at all, so none of these carries our tool's endorsement.
- Generate without the visible mark, if the setting is available. The Media watermark control is the reliable answer because it acts before the mark is drawn — nothing has to be removed afterwards. The official-route write-up covers where it lives and what it does not cover.
- Crop, if the composition allows it. The visible mark sits in the bottom-right corner, so trimming that corner does remove it. It costs you part of the frame and changes the aspect ratio. For the visible mark this genuinely works; for the invisible one it does not, for reasons set out on the SynthID page.
- Export at a size you have reason to believe works. If a tool publishes the dimensions it was tested at, generate or export at those. If it does not, that is itself the answer to whether you should rely on it.
Why we published a failure
Because the alternative is the thing this search is already full of. A page that says a tool handles Nano Banana images, without a measurement, is a page you cannot check. What we have instead is a test with a stated size, stated numbers, and a stated gap — and a conclusion we would rather you read here than discover after uploading a file.
The visible watermark on a Gemini image is genuinely removable, and this tool does that at the sizes it has been verified on — that is what the tool page and the questions page are about. A square 1024 is not one of those sizes today. When that changes, this page changes with it, and the measurement will be the evidence.
Sources
- Google AI for Developers, Gemini 3.1 Flash Lite image model page — ai.google.dev/gemini-api/docs/models/gemini-3.1-flash-lite-image. Source of "optimized for lower resolutions of 1K (1024x1024px)", the supported
image_sizevalue of 1024px, the note that 2K and 4K are unsupported, and the "SynthID watermarking (Always On) + C2PA" line. - Google AI for Developers, Gemini 3.1 Flash image model page — ai.google.dev/gemini-api/docs/models/gemini-3.1-flash-image. Source of the new 0.5K/2K/4K output options and the 1K default.
- Our own measurements, run on this site: the 1024×1024 test described above (correlation 0.3706 before and −0.2871 after; 535 of 1296 pixels inside the box off by more than one level; maximum errors 73 and 56 out of 255), and the 1536×1152 acceptance test it is compared against (correlation 0.9951).
- Our own tool's behaviour, measured on this site: only the pixels inside the watermark box are rewritten; SynthID and C2PA metadata are left untouched.