Batch Gemini Watermark Remover (CLI Guide)

The short answer

There is no batch button in the browser workspace, and there should not be one. Real bulk work belongs in the command-line tool and npm package, which run the same detection and removal engine as a scriptable, repeatable step instead of a one-file-at-a-time review.

When a browser tab is the wrong tool

The browser workspace is right for one file at a time, reviewed by a person before it goes anywhere. It is the wrong tool for a folder of hundreds of exports that need the same treatment applied consistently and logged along the way — a browser tab has no memory between drops, no exit code a script can check, and no way to tell a CI job whether ninety-eight files succeeded or two silently failed. That job belongs to the CLI, published as @pilio/gemini-watermark-remover, which exposes the identical catalog-aware pipeline behind a terminal interface built for exactly this.

A concrete workflow

The remove command accepts either a single file or a directory. Point it at a folder with --out-dir and it processes every file in that folder — not subfolders — in filename order, writing each result under the same name into the output directory:

# one file
pnpm dlx @pilio/gemini-watermark-remover remove ./input.png --output ./clean.png

# a whole folder, with structured per-file results
pnpm dlx @pilio/gemini-watermark-remover remove ./exports --out-dir ./clean --json

--json prints an array of structured results, one entry per file, each reporting what the detector found and what it did about it. --overwrite lets a rerun replace existing output instead of failing on a name collision. Nothing here uploads a file anywhere: the CLI runs the same local, catalog-aware detection as the browser tool, just on your own machine's Node process instead of a page.

What batch processing actually needs

Automating removal is not just "run the same edit on more files." It needs the same fail-closed behavior as the interactive tool, because a batch job that silently forces a change onto every file — whether or not a supported mark was actually confirmed — will eventually damage content it should have left alone. The structured per-file metadata exists specifically so a pipeline can branch on a genuine skip instead of assuming every input succeeded. Log it, do not discard it: a skipped file with a specific reason is a different failure mode than one that errored outright, and a production pipeline should treat them differently.

It also needs to be pinned and tested, the same as any other dependency a production pipeline relies on. A batch process that quietly picks up new default behavior on every release is a liability, not a convenience. The troubleshooting guide is a reasonable fixture set — a documented list of sizes, formats, and known failure modes — to validate a pinned version against before trusting it in production, and the size and position catalog is the underlying reference both the browser tool and the CLI consult when deciding what counts as a supported input.

Why the same obligations apply at scale

Nothing about running removal through a script instead of a browser tab changes the underlying obligations covered in the responsible-use guide: confirm rights to the file, keep the untouched source, and preserve any disclosure requirement the content carries. A batch pipeline arguably needs those checks written into the process itself more than a manual workflow does, since there is no person reviewing each file individually before it moves downstream. Keep the original inputs alongside the processed outputs — the CLI never deletes or overwrites a source file unless the output path happens to match it — and treat the structured detection metadata as an input to a review step, not a replacement for one.

Where this fits next to the other tools

The open-source repository is where the CLI, the browser workspace, and the npm SDK all share one engine, so a batch job built against the CLI today will behave the same way a manual spot-check in the browser does on the same file. If a specific image size or format is behaving unexpectedly in a batch run, the size catalog and the nano banana watermark guide are the right places to check whether that input was ever a supported case in the first place, rather than assuming the batch tooling itself is broken.