TL;DR: A WebP file is a RIFF container — a twelve-byte RIFF/WEBP header followed by chunks. A simple WebP holds just one bitstream chunk, VP8 (lossy) or VP8L (lossless), and carries no metadata at all. The moment a file needs metadata, it switches to the extended format gated by a VP8X chunk, whose flag byte signals which optional chunks follow: ICCP (color profile), EXIF (Exif metadata), XMP (XMP, with a trailing space), plus alpha and animation. AI tools and editors also embed a C2PA Content Credentials manifest as its own RIFF chunk. Because WebP files are small, that manifest can be a large fraction of the file. Removing WebP metadata means walking the chunk chain, keeping what renders the image, and dropping the rest. Metadata Cleaner does it in your browser, byte-for-byte on the pixels.
What's actually inside a WebP file?
WebP is the image format you are almost certainly already shipping without thinking about it. Your phone exports it, your CMS converts to it, your AI tool downloads it — and almost nobody opens one up to see what is inside. It is worth doing, because the answer is "more than a JPEG, structured like a WAV."
WebP is built on RIFF, Microsoft and IBM's Resource Interchange File Format — the same container family that backs WAV audio. Every WebP file begins with a twelve-byte header: the four ASCII bytes RIFF, a four-byte little-endian file size, and the four ASCII bytes WEBP. After that header comes a sequence of chunks, and every chunk has the same shape: a four-character code (a FourCC), a four-byte little-endian size, and that many bytes of payload, padded to an even length. The structure is laid out in Google's WebP Container Specification and standardised by the IETF as RFC 9649.
There are two layouts. A simple WebP contains exactly one bitstream chunk after the header — VP8 for lossy encoding (the trailing space is part of the FourCC) or VP8L for lossless. That is the whole file. A simple WebP has nowhere to put EXIF, XMP, a color profile, or a provenance manifest, because the format gives it no chunk to store them in. This is the detail that makes WebP unusual: in its basic form it is structurally incapable of carrying metadata. The metadata only appears once the file upgrades to the extended format.
The VP8X chunk: how WebP turns metadata on
The extended format is announced by a VP8X chunk placed right after the file header. VP8X is a feature table. Its first byte is a set of flags, and each flag declares which optional chunk is present in the file. The specification names them precisely: an ICC profile flag (set when an ICCP chunk is present), an alpha flag, an Exif metadata flag (set when an EXIF chunk is present), an XMP metadata flag (set when an XMP chunk is present), and an animation flag. The rest of the VP8X chunk records the canvas width and height.
This matters for two reasons. First, the flag byte is a table of contents for everything sensitive in the file — a reader can tell at a glance whether the WebP carries EXIF or XMP before parsing a single metadata byte. Second, it means metadata in WebP is opt-in at the structural level. A converter that writes a bare VP8L bitstream produces a file with no metadata surface. A converter that writes VP8X plus EXIF plus XMP produces one that leaks. Two visually identical WebP files can therefore differ completely in what they disclose, and you cannot tell which is which by looking at the picture.
Photo by Pixabay on Pexels.
The reconstruction chunks — VP8X, ICCP, ANIM, ANMF, ALPH, VP8 , and VP8L — must appear in a defined order, and a reader is allowed to fail if they are out of order. Metadata chunks are looser: EXIF and XMP may appear out of order, and the spec lets unknown chunks sit at the end of the file. That flexibility is exactly what a provenance manifest exploits, as the C2PA section below shows.
ICCP, EXIF, and XMP: the metadata a WebP carries
Once a WebP is in the extended format, it can carry the same three descriptive layers a JPEG can, each in its own chunk.
The ICCP chunk holds an ICC color profile, the same kind described by the International Color Consortium. This one is not a privacy concern — it describes how to interpret the file's colors, and dropping it can shift how the image renders on a wide-gamut display. We keep it when we strip, which is a deliberate choice we come back to.
The EXIF chunk is where the leak usually lives. Exif is the camera-and-capture metadata standard, and when a WebP is converted from a JPEG that a phone or camera produced, the conversion often carries the Exif block straight across into an EXIF chunk. That block can include the camera make and model, the lens, exposure settings, the original capture timestamp, the software that processed the file, and — the field that matters most — GPS coordinates. A WebP exported from a geotagged original can pin the location where the shot was taken to within a few meters. We walked through that specific risk for photos in our piece on removing GPS data from photos, and the broader pattern in EXIF data privacy risks. The format changed from JPEG to WebP; the exposure did not.
Photo by Max Andrey on Pexels.
The XMP chunk (the trailing space is part of the FourCC) holds Adobe's Extensible Metadata Platform — UTF-8 XML that can carry editing history, rights and copyright fields, author names, keywords, and, increasingly, Content Credentials assertions. If you have run a WebP through Photoshop, Lightroom, or any Adobe export, you likely have an XMP chunk in the file. The IPTC photo metadata fields that ride inside XMP are defined in the IPTC standards, and they are designed to follow the image everywhere it goes. That is useful for a stock agency tracking licensing. It is a disclosure for a creator who would rather not ship their name and editing trail with every upload.
C2PA in WebP: Content Credentials in the RIFF chain
The newest layer is provenance. C2PA — the Coalition for Content Provenance and Authenticity standard behind Content Credentials — embeds a signed manifest into the file, and WebP is one of its supported formats. In a WebP the manifest lives in its own RIFF chunk in the chain, the same role it plays as a caBX chunk in PNG or an APP11 marker in JPEG. Inside that chunk sits a JUMBF box holding a CBOR-encoded assertion store, a COSE signature, and a certificate chain — a cryptographically signed record of what tool made the file and when.
This is where WebP's small size becomes a quirk worth knowing. A C2PA manifest is a fixed-ish number of bytes regardless of the host image. On a large PNG that is a few percent of the file. On a WebP — which exists precisely because it compresses smaller than PNG or JPEG — the same manifest can run to roughly a third of the total file size. We flagged that overhead in our walkthrough of ChatGPT image metadata, where OpenAI's images download as PNG or WebP and the C2PA payload shows up as about 3% of a PNG but up to 30% of a WebP. The bytes did not grow; the file around them shrank.
Photo by Gnist Design on Pexels.
For a creator, the practical effect is that a WebP from an AI image tool is both marked and heavier than it needs to be. Platforms that read C2PA at upload — and the number that do is growing — use the manifest to drive their AI-content labels. Strip the manifest and the file is back to being structurally indistinguishable from any other WebP at the C2PA layer, and a noticeable fraction lighter. For the full background on what the standard is and why every commercial AI image tool now ships it, see our explainer on what C2PA metadata is.
How to remove WebP metadata online without uploading
You can do this in the browser without sending the file anywhere. Metadata Cleaner opens the WebP, walks the RIFF chunk chain, keeps the chunks that render the image, drops the rest, and re-serialises the file. The pixel bitstream inside VP8 or VP8L is copied through unchanged, so the cleaned image is visually identical to the source. The steps take about forty seconds end to end — the exact sequence is in the HowTo block at the top of this post.
Two decisions are worth calling out. First, we keep the ICCP color profile. It is not identifying metadata; it tells the display how to render the file's colors, and dropping it can visibly shift them on a wide-gamut screen. If you specifically want a profile-free file, that is a different operation. Second, we drop the whole EXIF and XMP chunks rather than editing individual fields — removal, not selective scrubbing. If you need to keep, say, copyright but lose GPS, you would edit the file in a dedicated tool first and then strip the rest.
To confirm the strip worked, run exiftool -G1 -a cleaned.webp and read the output. You should see the dimensions and the color-profile fields and nothing else — no ExifIFD, no XMP, no GPS, no JUMBF. ExifTool reads the JUMBF group that C2PA writes; per its documentation it surfaces those tags, and their absence after a strip is the confirmation that the manifest is gone. The same chunk-walking pattern is what we use on other formats — we covered the identical RIFF approach for WAV audio files, and the C2PA-specific version for AI image exports.
What stripping a WebP doesn't reach
Removing the metadata chunks is a clean intervention, but it is not the whole story, and we try to be straight about the edges — the same way we were in our piece on metadata versus watermarks.
Stripping the file does not touch anything embedded in the pixels themselves. If a WebP came out of an AI generator that also applies a pixel-level watermark — the SynthID-style perturbation pattern that ships alongside C2PA in some pipelines — that signal lives in the decoded image, not in a chunk, and it survives the strip. Removing it would mean altering the pixels enough to disrupt the pattern, which means visibly degrading the picture. A metadata tool does not do that, and most creators would not want it to.
Stripping also does not change anything the platform already knows. If your account has previously uploaded labelled or signed content, the platform's own records are unaffected by what a single new file carries. And a platform that re-encodes WebP on upload — many do, to normalise formats — will rebuild the file on its side regardless of how clean yours was. What stripping reliably does is stop the file itself from announcing its camera, its location, its editing history, and its provenance to anyone who opens it or any pipeline that reads it on ingest. That is a real change for privacy and for upload classifiers. It is not a magic switch that makes an image untraceable.
FAQ
Does removing WebP metadata change the image quality? No. The compressed bitstream inside the VP8 or VP8L chunk is copied through byte-for-byte, so the cleaned file decodes to the same pixels. Only the metadata chunks around it are removed.
Why is my WebP smaller after stripping than the math suggests? Because WebP files are small to begin with, the metadata you removed — especially a C2PA manifest — can be a large fraction of the original. A manifest that is 3% of a PNG can be closer to 30% of the same image as a WebP, so the drop is more noticeable.
Can I just convert the WebP to JPEG to strip it? Sometimes. Re-encoding through a tool that does not carry the chunks forward will drop EXIF, XMP, and the C2PA manifest — but it also re-compresses the pixels, which loses quality, and many encoders happily copy EXIF across anyway. A chunk-level strip on the original WebP is cleaner and lossless.
Does a simple WebP have any metadata? No. A simple WebP is just a header and one VP8 or VP8L bitstream chunk. Metadata only exists in the extended format, which is gated by a VP8X chunk. If there is no VP8X, there is no EXIF, XMP, or C2PA to remove.
Does Metadata Cleaner upload my WebP anywhere? No. The file is processed inside your browser tab as an ArrayBuffer. Nothing leaves the device, and the cleaned file is written back as a download.
WebP is the format that quietly replaced JPEG across the web, and most people have never looked inside one. If you ship WebP images — from a camera, a CMS, or an AI tool — assume the file may carry more than the picture. Try Metadata Cleaner free and check what comes out the other side.