Where the Gemini watermark sits at each resolution
The mark is placed by rule. Two numbers decide everything: how large the logo is drawn, and how far it is inset from the bottom right corner. Both follow from the resolution tier, with a handful of documented exceptions that are worth knowing about.
The placement rule
The mark is always anchored to the bottom right corner. Given a logo size and a margin, the top left corner of the mark sits at:
x = width − marginRight − logoSize
y = height − marginBottom − logoSize
The logo is square, so one size covers both dimensions, and in every layout published so far the right and bottom margins are equal. That reduces the whole question to two numbers per tier.
Work an example. A 2k generation at 3:2 is 2528 by 1696 pixels, drawn with a 96 pixel
logo at a 64 pixel margin. So the mark occupies the square from
x = 2528 − 64 − 96 = 2368 to 2464, and from
y = 1696 − 64 − 96 = 1536 to 1632. That is the entire search
region, out of more than four million pixels.
Layouts by tier
For Gemini 3.x Image, the current layouts are:
| Tier | Logo size | Margin | Notes |
|---|---|---|---|
| 0.5k | 48 px | 32 px | Small canvas, small mark |
| 1k | 48 px | 32 px | Current layout. Earlier output used 96 and 64 |
| 2k | 96 px | 64 px | |
| 4k | 96 px | 64 px | Same absolute size as 2k, so relatively smaller |
Notice that the mark does not scale with the image. A 96 pixel logo on a 4096 pixel wide canvas is proportionally a quarter of what the same logo is on a 1024 pixel one. The absolute size is what stays fixed, which is why the tier matters more than the aspect ratio.
Gemini 2.5 Flash Image output at its 1k tier uses the 96 pixel logo at a 64 pixel margin rather than the smaller current 3.x layout.
The variants
Four departures from the table above turn up in real files. Each exists because Google changed something at some point and older output did not retroactively change with it.
The legacy 1k layout
Gemini 3.x at 1k used to draw a 96 pixel logo at a 64 pixel margin, and now draws a 48 pixel logo at a 32 pixel margin. Both are in circulation, because files generated before the change still exist. A 1024 by 1024 image from last year and one from this week carry marks of different sizes in different places. Detection tries the current layout first and falls back to the legacy one.
The large margin layouts
Some sizes are drawn with a deeper inset than their tier implies. At 1k the large margin variant keeps the 48 pixel logo but pushes it to a 96 pixel margin. At 2k, the square 2048 by 2048 and the 4:3 2400 by 1792 are the sizes known to use the deeper inset.
The 2816 by 1536 layout
This 16:9 size at the 2k tier is drawn with a 96 pixel logo at a 192 pixel margin, three times the standard 2k inset, and it uses an alpha map introduced in May 2026 rather than the original artwork. It is different enough that it is treated as its own entry rather than as a variant of the tier.
The small v2 mark
A further variant draws the logo at just 36 pixels with a 96 pixel margin, against a second-generation alpha map. It is the smallest mark in circulation, and because the recovery divides by the alpha at each pixel, a smaller mark means fewer pixels to correct and a cleaner result.
1408 by 768
One size gets its own fixed entry: 1408 by 768 carries a 46 pixel logo at a 32 pixel margin. Two pixels smaller than the 48 used by everything else at that tier. There is no rule that derives it, so it is simply recorded.
Two pixels sounds like nothing. It is not. The removal subtracts a known alpha map from known coordinates, so a mark that is 46 pixels wide being treated as 48 misaligns every row and column of the subtraction, and the corner comes back looking worse than it went in. This is why the tool verifies before it commits.
How a position is confirmed
The tier lookup produces a prediction, not a conclusion. Three things happen before any pixel is changed.
- Candidates are generated. Every layout consistent with the file's dimensions goes into a pool: the tier default, any legacy layout, any large margin variant, and any fixed entry for that exact size.
- Each is refined. The logo has internal structure, and searching for that structure near the predicted position recovers small offsets introduced by a crop or a resize.
- Each is scored. The removal is performed and the result judged against the pixels around it. A correct removal leaves a corner that blends with its surroundings; a wrong one leaves a seam, a ghost or a bright patch.
The highest scoring candidate wins, provided it clears a threshold. If none does, the file is returned unchanged. The reasoning behind that choice is in why a file sometimes comes back unchanged.
What moves the mark
Anything that changes the pixel dimensions changes where the mark sits relative to the corner, and the catalogue prediction stops being useful.
- Cropping the bottom or right edge changes the margin directly. Crop 40 pixels off the bottom and the mark is now 24 pixels from the edge instead of 64.
- Cropping the top or left edge leaves the margin intact but changes the dimensions, so the file no longer matches the catalogue and the tier cannot be looked up.
- Resizing scales the logo along with everything else, to a size that matches no known variant. A 1024 pixel image scaled to 800 carries a mark of roughly 37 pixels, which is close to the 36 pixel v2 variant and not the same thing.
- Screenshots combine resizing with re-compression and usually with display scaling as well.
The anchor search absorbs offsets of a few pixels, which covers small trims and minor re-exports. It cannot recover a layout that no longer resembles any catalogue entry. Use the original download whenever you still have it.