# Nano Banana watermark: what it is and what PassReal removes Source: https://passreal.com/generators/nano-banana Images from Google's Nano Banana model carry two provenance layers: a C2PA manifest in the file metadata, and SynthID, a watermark embedded in the pixels themselves. The metadata layer is removed outright by stripping. The pixel watermark is designed to survive ordinary edits, and no honest claim can be made that a resampling pipeline reliably removes it. ## Two layers that get confused constantly Provenance for images generated in Google's stack arrives in two forms, and conflating them leads to confident statements that are wrong. The first is C2PA: a manifest, cryptographically signed, stating what produced the file and what happened to it since. It lives in the file container, next to EXIF. Because it is metadata, it can be removed, and removal is complete - the manifest is gone rather than corrupted. A verifier then reports no provenance data, which is the same thing it reports for the overwhelming majority of images on the internet. The second is SynthID: a pattern embedded into the pixel values themselves, intended to be imperceptible to a viewer and detectable by a paired model. It was built specifically to survive the operations that destroy metadata - screenshots, re-encoding, cropping, resizing, colour grading. ## The claim this page will not make A pipeline that resamples and re-encodes an image degrades a pixel watermark somewhat, because every lossy operation does. Whether it degrades it past the point of detection is a question about a detector nobody outside Google can run, against a watermark whose strength is not published. There is no measurement here that would support a claim either way, so none is made. Pages that promise watermark removal with a percentage attached are quoting a number they did not measure. What is measurable, and what the sheet above shows, is the fidelity cost: SSIM and PSNR computed on this image, against its source. ## What processing does address The C2PA manifest is removed with the rest of the metadata. So are the absences that follow generated images around: no camera make, no exposure triple, no lens description, no capture timestamp. The sensor stage then supplies what the image never had. Grain at intensity 0.018 gives it a noise floor. Lateral chromatic aberration reaches 1.25 px of channel separation at the corners and none at the centre, matching how refraction actually varies across a real lens. The frequency stage attenuates periodic upsampling residue at 0.88 of Nyquist. The file is then written as a JPEG with coherent EXIF and the quantization table belonging to the camera make it declares, so the compression and the claimed origin do not contradict each other. ## Checking what a file of yours carries Before deciding what to do about provenance, find out what is actually in the file. The answer differs by tool, by export path and by month. - `exiftool -a -G1 file.png` lists every tag with its group. A C2PA manifest shows up as a large JUMBF block, and its absence is as informative as its presence. - The Content Credentials verification page reads a file and reports what the manifest claims and whether the signature validates. - Screenshotting a generated image drops the manifest, because a screenshot is a new file made by a different program. It does not drop a pixel watermark. - Downloading through a third-party client sometimes strips manifests already, so two people with the same image can hold files that verify differently. The last point causes a lot of confusion. Someone concludes that provenance data is trivially removed, or impossible to remove, based on one path through one client, and generalises from it. ## Why the distinction is worth caring about A reviewer running exiftool and a platform running a watermark detector are doing different jobs, and a tool that helps with one may do nothing for the other. Knowing which check you are facing decides whether processing is worth anything to you at all. If the concern is a manifest that says "generated by" in plain text, stripping resolves it completely. If the concern is a Google property checking its own watermark with its own key, no third-party pipeline can promise a result, and anyone who does is guessing on your behalf. ## Questions ### What is SynthID? A watermarking system from Google DeepMind that embeds an imperceptible pattern into generated pixels. It is designed to survive cropping, compression, colour adjustment and resizing, and it is detected by a paired model rather than by reading a metadata field. ### Does stripping metadata remove SynthID? No. Metadata stripping removes the C2PA manifest, which is a separate layer stored in the file container. SynthID lives in the pixel values. Removing a manifest and removing a pixel watermark are different operations, and only the first is deterministic. ### So what does processing actually accomplish here? It removes the C2PA manifest and the absent-camera signals, applies a sensor model, and writes coherent EXIF. That addresses metadata inspection and generic statistical checks. It does not claim to defeat a watermark detector holding the matching key. ### Who can check SynthID? Google exposes detection through its own tooling, and the checking model is not publicly distributed. In practice that means platform-side verification by Google properties, rather than a check any reviewer can run on a laptop. ### Is C2PA the same thing? No. C2PA is a signed metadata manifest describing how a file was made, stored in the container alongside EXIF. It is verifiable and tamper-evident, but it is also removable - deleting it destroys the claim rather than falsifying it, which verifiers report as missing rather than invalid. Try it: https://passreal.com/app (three images free)