Gemini Watermark Sizes and Positions Catalog

The short answer

Gemini's visible watermark is 48×48 pixels with a 32px right/bottom margin on 0.5K and 1K outputs, and 96×96 pixels with a 64px margin on 2K and 4K outputs. One confirmed size, 2816×1536, breaks that pattern with a 192px margin instead. Every number below comes from src/core/geminiSizeCatalog.js in the open-source engine, regenerated for this page rather than typed by hand.

Why a catalog beats a rule of thumb

Gemini image generation does not emit arbitrary dimensions. Each model family and resolution tier renders to one of a small, fixed set of official pixel sizes, so a lookup table is a better watermark prior than an if/else chain built on ratios and guesses. The source file backing this page carries 68 catalog entries covering 67 unique pixel dimensions across six model-family and resolution-tier combinations. The gap between those two numbers is not rounding error: 1024×1024 is the only pixel size two different tiers both render at, gemini-3.x-image's 1k tier and gemini-2.5-flash-image's 1k tier, and the catalog keeps a single authoritative entry for it rather than two conflicting ones. That single collision is the entire difference between 68 and 67, and it is why 67 verified size profiles is the honest number to quote, not 68.

A rounded rule such as "small images get a small mark, large images get a large one" is easier to remember, and it is also exactly the kind of approximation that breaks the moment a size does not follow it. A broken assumption in watermark detection rarely fails loudly. It either misses a mark that is really there, or it treats the wrong region as the mark and edits pixels that should have been left untouched. Measuring every entry once, in code, and re-checking it here on every rebuild is the alternative to trusting that a general pattern happens to hold for the specific file in front of you.

The geometry, in three numbers

The full catalog

Every table below is generated from the same source file and lists the aspect ratio, the exact pixel size, the resolved watermark size, its right/bottom margin, and the computed top-left watermark position (x, y) for that size. Positions are measured from the image's top-left corner, so x and y are always width − marginRight − logoSize and height − marginBottom − logoSize.

gemini-3.x-image · 0.5K (14 sizes)

gemini-3.x-image · 1K, current (15 sizes)

1376×768 and 1408×768 are both confirmed 16:9 entries at this tier; the second is a distinct catalog record, not a typo, which is exactly the kind of near-duplicate a hand-maintained list would be tempted to collapse into one.

gemini-3.x-image · 2K (14 sizes)

gemini-3.x-image · 2K exception (1 size)

gemini-3.x-image · 4K (14 sizes)

gemini-2.5-flash-image · 1K (10 sizes)

The 1024×1024 row above is where the one dimension collision lives: on its own, gemini-2.5-flash-image's 1K tier would put a 96×96 mark at a 64px margin there, matching its other nine sizes. But the catalog resolves any 1024×1024 file against the first entry that claims that pixel size, which is gemini-3.x-image's 1K tier, so the resolved watermark is actually 48×48 at a 32px margin. This only matters if you are cross-referencing a 1024×1024 file against the "wrong" table above; the removal engine itself does not need you to know which model produced a file, because it searches the catalog by pixel size, not by declared model.

Where the catalog stops and search begins

A file matching one of the 67 sizes above gets an exact catalog lookup. A file that is close but not exact, for example a re-export scaled by a consistent factor, does not get treated as unsupported by default. The engine projects the nearest official entry's watermark position onto the new dimensions when the aspect ratio is close enough and the horizontal and vertical scale factors agree closely enough with each other, then validates that projected candidate against the actual pixel data before trusting it. That is a search seed, not a guarantee: what a supported match still cannot save you from is any file where the mark itself has been cropped, resized non-uniformly, or recompressed past the point the calibrated edge profile survives.

Using this table

If you are validating your own pipeline against Gemini output, start from the exact pixel dimensions your generator reports, look up the matching tier above, and check both the watermark size and the margin before assuming a corner region. The supported sizes and formats guide covers the adjacent question of which file formats and workflows the tool accepts; this page is the geometry reference that guide points back to. If a result still looks wrong on a file whose dimensions are in this catalog, the troubleshooting guide walks through the most common reasons a specific file gets skipped. For automated, repeatable checks against many files at once, the batch workflow covers running the identical detection and removal engine outside the browser over a whole folder in one pass. Anyone who wants to verify any of the numbers on this page against the actual running code, rather than take this table on faith, can read the full open-source repository directly.