How do you strip AI metadata from a file?
Remove the specific container blocks that carry it: APP1 (EXIF and XMP) and APP11 (C2PA/JUMBF) in JPEG, the tEXt, iTXt, eXIf and caBX chunks in PNG, and the EXIF and XMP chunks in WebP. Deleting whole blocks is a container operation, so the compressed pixel data never has to be decoded or rewritten.
There are three practical routes, and they differ mainly in whether your file leaves your machine.
- A browser tool that runs locally. Everything happens in the page, so nothing is uploaded. This is the right default for unreleased work, client files, or anything with GPS in it.
- A command-line utility.
exiftool -all= photo.jpgremoves metadata in place and is the standard answer for scripted or bulk work. ExifTool is the most complete metadata tool in existence and worth learning if you do this often. - An upload-based web service. Fastest to reach and the worst choice for anything sensitive, because you have handed the original file, metadata included, to a third party in order to remove the metadata. If a tool requires an upload, it has already seen what you were trying to delete.
Editing a C2PA manifest is not removing it
C2PA manifests are cryptographically signed. Altering fields inside one leaves a broken signature, which is a louder signal than the manifest was. The block has to be deleted whole.
Which file types can actually have AI metadata stripped?
JPEG, PNG and WebP can be cleaned completely and losslessly, because their containers let you delete whole blocks without touching the compressed pixel data. AVIF, HEIC, PDF, Office documents and video are all more complicated, and most browser tools including this one do not support them.
Being specific about this matters, because the generic advice to "strip the metadata" quietly assumes a format where that is straightforward.
| Format | Can AI metadata be stripped? | Notes |
|---|---|---|
| JPEG | Yes, losslessly | Remove APP1 (EXIF, XMP), APP11 (C2PA/JUMBF), APP13 (IPTC). Scan data untouched. |
| PNG | Yes, losslessly | Delete tEXt, zTXt, iTXt, eXIf and caBX chunks. IDAT is copied through as is. |
| WebP | Yes, losslessly | Remove EXIF and XMP RIFF chunks, then correct the RIFF size field and VP8X flags or decoders reject the file. |
| AVIF / HEIC | In principle, not here | Metadata lives in ISOBMFF boxes. This tool does not support them yet, so we do not pretend otherwise. |
| Partly, with care | Document metadata and XMP can be removed, but PDF editing behaves differently from image containers. Verify the output rather than assuming. | |
| DOCX / XLSX | Yes, outside this tool | These are ZIP archives. Author and revision data sits in docProps. Office has its own Document Inspector. |
| MP4 / MOV | Partly, outside this tool | Container atoms can carry provenance. Video is a different problem and no image tool solves it. |
Why we will not add a page for formats we cannot parse
Building a "HEIC metadata remover" page before building a HEIC parser would rank for a query and then fail the person who clicked it. The parser comes first. Until then the honest answer is that this tool handles JPEG, PNG and WebP.
How do you strip AI metadata without re-encoding the file?
Use a tool that performs container surgery rather than decoding and re-saving the image. If a tool decodes your JPEG and writes a new one, it re-compresses the pixels, which permanently degrades the image even when the file looks identical on screen.
This is the single most consequential difference between metadata tools, and it is almost never disclosed. Decoding a JPEG and re-encoding it runs lossy compression a second time. The damage is cumulative: every pass through such a tool costs quality you cannot get back.
We measured this on the market incumbent before building anything. On a single metadata strip it altered 52.3% of pixels, at a PSNR of 39.78 dB, and its PNG outputs came back 15.8% larger than the inputs. Its page advertised "same pixels" while doing it.
If an image gets larger after you remove data from it, the tool did not remove data. It rebuilt the file.
The test is easy to run yourself and does not require trusting anyone. Two checks catch almost every re-encoder:
- Compare file sizes. Removing metadata can only make a file smaller. An output larger than the input means the pixel data was rewritten.
- Compare decoded pixel hashes. Decode both files to raw pixels and hash them. Identical hashes mean genuinely lossless. "Visually identical" and "high PSNR" are not the same claim, and a tool that offers a PSNR figure is telling you it changed something.
Colour profiles are not junk metadata
ICC profiles describe how colours should be rendered. Strip one and the image shifts, often subtly enough that you notice only when printing or next to the original. Good tools keep ICC by default and make removal an explicit choice.
How do you verify the AI metadata is actually gone?
Re-scan the output with a parser that reads every container, not just C2PA, and confirm it returns zero fields. A success message from the tool that did the stripping is not verification, because it is the same code reporting on its own work.
This is the step the entire category skips, and skipping it is how people end up confidently uploading a file that still carries their GPS coordinates. During our audit, a control file carrying GPS and an EXIF Software field reading "Adobe Photoshop 25.0 (Generative Fill)" was reported by the leading tool as 0% metadata and "clean for upload". The detection layer only parsed C2PA, so everything else was invisible to it and reported as None.
- Re-open the cleaned file in a reader, not the remover. Use a different tool than the one that did the work. Our checker is read-only and exists for exactly this.
- Check that the reader parses more than C2PA. If it reports plain EXIF and XMP as "None" on a file you know has them, it cannot verify anything.
- Confirm file size went down, not up. See the previous section.
- Strip a second time. On a correct implementation the second pass is a no-op and finds nothing. If it finds more to remove, the first pass was incomplete.
Every operation on this site is re-scanned after stripping and reports what remains before it tells you it succeeded. That is a deliberate response to what the audit found, and it is also why the tool will sometimes tell you a field could not be removed instead of quietly claiming success.
What AI metadata cannot be stripped from a file?
Invisible pixel watermarks such as Google SynthID cannot be removed by any metadata tool, because they are embedded in the image data rather than in a metadata block. Labels already attached to a published post, and disclosure obligations, are also unaffected by anything you do to the file.
Stripping metadata is a narrow operation with a clear boundary. Being precise about where that boundary sits is more useful than a confident promise.
- Pixel watermarks. SynthID survives cropping, resizing, compression and metadata removal. Any tool claiming to remove it is describing something it cannot do.
- A label on a live post. Platforms store the label against the post record, not the file. Replacing the image does not clear it; deleting and reposting the cleaned file usually does.
- Your own declaration. If you ticked the AI disclosure box when posting, that label came from you.
- How the content looks. A human or a classifier judging the image itself is unaffected by metadata.
- Disclosure duties. Platform policy, marketplace rules and EU AI Act Article 50 transparency obligations attach to how the work was made. Removing a field does not discharge them, and this is not legal advice.
Screenshots are not a clean workaround
Taking a screenshot does discard the original metadata, but it re-encodes the image, loses resolution, and leaves any pixel watermark intact. It also adds your device metadata to the new file. It trades a known problem for several quieter ones.