There is no route that removes SynthID and leaves the image alone. SynthID is not a layer on top of the picture; Google describes it as a watermark embedded directly in the pixels while the content is generated, and designed to stand up to cropping, filters, frame-rate changes and lossy compression. That means the mark and the picture are the same bytes, so every operation that disturbs the mark also disturbs the picture. Our measurement of five routes found exactly that: three of them changed the decoded pixels at a cost of 45.9 to 49.4 dB, and the only one that left the pixels byte-identical was a header strip that never decoded the image at all.
Google DeepMind's page on SynthID says the watermarks are "imperceptible to humans" and that the system "embeds digital watermarks directly into AI-generated images, audio, text or video". On images specifically it says the mark "doesn't change the image or video quality", is added "the moment content is created", and is "designed to stand up to modifications like cropping, adding filters, changing frame rates, or lossy compression".
OpenAI, which embeds Google's SynthID in the pixels of images generated through ChatGPT, Codex and the OpenAI API, says the same thing from the other end. Its provenance documentation describes the two signals it uses, why it uses both, and where each one fails: metadata "may be lost through everyday actions, such as taking a screenshot or converting a file", while a watermark "carries less context, but because they are embedded in the generated content itself, they may survive some transformations that remove metadata".
Those two sentences are the whole answer to the question. The metadata half is removable and the pixel half is not, and the reason is not a limitation of any particular tool - it is what "embedded in the content" means.
This workspace has no OpenAI or Google account, so there is no genuine SynthID-marked file here, and nothing below claims to have removed one. What can be measured without a marked file is the part every removal method has in common: an operation that changes the pixels also changes the image. Five routes were run over one fixture, with one APP11 segment spliced into its header so the metadata route had something real to remove.
| Route | File size | Decoded pixels | PSNR | Reaches the mark? |
|---|---|---|---|---|
| copy the file, change nothing | 84,784 B | md5 6ff108b4bdff unchanged | reference | no |
| strip the header segments only | 84,784 → 80,369 B | md5 6ff108b4bdff unchanged | inf | no — the picture is never decoded |
| re-encode the same pixels at quality 85 | 69,865 B | md5 ca46c6eb2e39 | 49.381 dB | yes, at the cost shown |
| crop 20% off the right, then re-encode | 55,647 B | md5 b55c4aaa658b | 49.420 dB | yes, and you lose a fifth of the frame |
| noise every pixel, then re-encode | 73,841 B | md5 0bcad426933d | 45.857 dB | yes, at the worst cost of the five |
Two rows carry the argument. The header strip is the only route whose decoded pixels come out identical, and it is exactly the route that cannot reach a mark inside the picture: it takes 4,415 bytes out of the header without ever decoding the image. The three routes that do reach the picture all change the decoded sample hash, and the cheapest of them still costs about 49 dB. The noise row is the interesting one, because a small, structured, imperceptible perturbation of every pixel is what "neutralising a signal in the frequency domain" has to amount to — and it is the most damaging route of the five.
To reproduce it: python dev/synthid_edits.py builds the fixture with ffmpeg, splices the APP11 segment in, runs the five routes and prints the table. Nothing is installed; the standard library and ffmpeg are the whole dependency list.
The usual way this is reported is that one side says the watermark survives editing and the other says it does not, which sounds like a contradiction. It is not, because they are describing different ends of the same dial.
| Change | What the vendor says | What it means for you |
|---|---|---|
| light edits, copy and paste, a screenshot | Google: designed to stand up to cropping, filters, frame-rate changes, lossy compression. OpenAI: these are among the changes the watermark is designed to withstand. | the mark usually survives, so a light edit is not a cleaning method |
| heavy cropping, compression, format conversion, substantial edits | OpenAI: "More extensive changes — such as heavy image cropping, file compression, substantial paraphrasing, or translation — can make a watermark undetectable." | the mark degrades, and so does the file; "undetectable" is not "removed" |
| metadata stripped by upload, download, sharing or conversion | OpenAI: Content Credentials "can be lost through everyday actions, such as taking a screenshot or converting a file" | this is the one layer that genuinely comes off, and it is a header operation |
The practical reading is that an edit does not remove the mark, it moves the question. The honest version of "can I strip this" is "how much of the image am I willing to spend, and is what is left still the image".
Two official detectors exist, and they answer a narrower question than people expect.
| Tool | What it takes | What it covers |
|---|---|---|
| openai.com/verify | PNG, JPG, WEBP, MP3, WAV, AAC, FLAC, OGG, OPUS, PCM | provenance signals associated with content generated or exported by OpenAI tools — a SynthID watermark or a trusted C2PA manifest |
| OpenAI Content Provenance API | images and audio, from code | the same check, integrated into a workflow; free under default limits, with a higher-limit programme for qualifying public-interest work |
| synthid.com (SynthID Detector) | images, video, audio; requires sign-in and has a daily quota | Google's own description: content "made with AI from Google or our partners, including OpenAI, NVIDIA, Kakao, and soon, Apple" |
| Gemini, Search and Chrome | an upload inside the product | Google says these built-in checks handle more than a million requests a day |
One detail on the detector's terms of service is worth knowing before you plan anything around it. Google's SynthID Detector page asks users to agree not to "run black-box adversarial attacks or optimize digital transformations designed to break, bypass, or degrade the SynthID watermark detection logic", not to automate or scrape it, and not to evade the daily quota. The privacy notice says uploaded media is deleted once the result is returned and that a signature of the file is kept for 24 hours to enforce the quota. A detector built to answer "was this watermarked" is explicitly not licensed to answer "how do I get past it".
If your file carries a visible mark in the corner instead of an invisible one, the method that works is a crop or a clone, and the cost of that is measured on the logo page and the photo page. If it carries metadata you want gone, that comes out without touching a pixel: strip image metadata without re-encoding.
Not without changing the image. SynthID is embedded in the pixels while the image is being generated, so a mark that is part of the picture can only be disturbed by an operation that also disturbs the picture. Our measurement below shows every pixel-level route changing the decoded samples, with a cost between 45.9 and 49.4 dB of PSNR. The one operation that left the pixels byte-identical was a header strip, which never decodes the image and therefore cannot reach a mark inside it.
It degrades it rather than removing it, and the direction matters. Google says the watermark is designed to stand up to cropping, filters, frame-rate changes and lossy compression, which means light edits usually leave it detectable. OpenAI says the opposite about heavier edits: extensive changes such as heavy cropping, compression or conversion can make a watermark undetectable. So cropping does not clean the file — it just moves the question from "can I remove it" to "is it still detectable", and both answers depend on how far you went.
There are two official ones. OpenAI runs openai.com/verify for images and audio generated or exported by its tools; its Content Provenance API does the same for developers. Google runs the SynthID Detector at synthid.com, which Google DeepMind describes as covering content made with AI from Google or its partners, including OpenAI, NVIDIA and Kakao, with Apple listed as coming soon. Both look for a signal that was embedded at generation; neither is a general AI detector.
It means that tool did not find a supported watermark in that file, and OpenAI lists the reasons a supported file can still come back negative: it was created before the signals existed, it came from an unsupported product or export path, metadata was stripped during upload or sharing, or the watermark was degraded by compression, cropping, noise, edits or format conversion. A negative result is not proof that a person made the file. A positive result is much stronger evidence, because it means a mark that was written at generation is still readable.
They cannot be telling the whole truth. A pixel-level mark can only be disturbed by an operation that also disturbs the pixels, so a promise of removal with no quality loss and a promise of removal itself cannot both hold. Several of the tools also describe a step that is real and a step that is not: they genuinely strip EXIF, XMP and C2PA metadata, which is a header operation, and then attribute that to the pixel mark. Our own survey of what these sites claim, with their wording quoted, is on the SynthID remover page.
Partly. SynthID is Google DeepMind's watermarking technology, and OpenAI embeds it in the pixels of images generated through ChatGPT, Codex and the OpenAI API. That is one of two signals OpenAI puts on an image: the other is a Content Credentials record, which is metadata rather than pixels and does come off with a metadata strip. So when someone asks how to remove the ChatGPT image watermark, the honest answer is that the metadata half is removable and the SynthID half is not — see the ChatGPT image page for the split.
Sources: Google DeepMind, Google SynthID (how SynthID works; the SynthID Detector). OpenAI Help Center, Provenance signals in OpenAI-generated content (updated 2026-10-12). openai.com/verify. SynthID Detector terms of service and privacy notice at synthid.com. The measurement is reproduced by dev/synthid_edits.py in this repository.