Formats

Removing metadata from WebP files

Published September 18, 2026 · Updated September 21, 2026 · MetaPurify

WebP is not a single image blob with a header on the front. It is a RIFF container holding a sequence of labelled chunks, and metadata lives in chunks of its own. That structure makes clean removal possible — and it introduces one failure that produces a file which is technically broken while looking perfectly fine.

How WebP stores an image

Every WebP begins with the ASCII tag RIFF, a four-byte little-endian size, and the tag WEBP. After that comes a run of chunks, each one a four-character type, a little-endian length, and a payload padded to an even number of bytes.

The image itself arrives in one of three forms, defined in the WebP container specification:

• VP8 — a lossy frame. Note the trailing space; chunk types are always four characters.
• VP8L — a lossless frame.
• VP8X — the extended header. It does not contain pixels. It declares the canvas size and a flags byte saying which optional features the file uses, and it must be the first chunk when present.

A minimal WebP is just VP8 or VP8L. Anything with transparency, animation, a colour profile or metadata is an extended file and carries VP8X first.

Where the metadata lives

In an extended file, metadata sits in its own top-level chunks alongside the image data:

• EXIF — an EXIF block, structurally the same TIFF-based payload a JPEG carries in its APP1 segment.
• XMP — an XMP packet, again with a trailing space in the type.
• ICCP — the colour profile.

This is cleaner than JPEG's arrangement, where metadata is interleaved among marker segments that also carry decoding parameters. In WebP, a metadata chunk is a discrete, length-prefixed span you can drop without touching a single byte of image data. Rebuild the chunk list without it, recompute the RIFF size in the header, and the file is complete.

That is why removing metadata from a WebP does not degrade the picture: the VP8 or VP8L payload is copied through untouched. Nothing is re-encoded.

Why animated WebP is different

An animated WebP replaces the single frame with an ANIM chunk holding global animation parameters — background colour and loop count — followed by one ANMF chunk per frame. Each ANMF carries its own offset, size, duration, blending and disposal method, and its own embedded image payload.

The naive way to strip metadata is to find the picture and rewrite the file around it. Applied to an animated WebP, that produces a single still frame, or a file whose frame sequence has lost its timing. Correct handling requires treating ANIM and ANMF as image payload — as many chunks as the file has — and preserving their order.

MetaPurify treats VP8 , VP8L, ALPH, ANIM and ANMF as payload chunks and copies each one through byte for byte, so an animated file comes back animated with its frame timing intact.

The VP8X flags byte

This is the failure worth knowing about, because it is silent.

The VP8X chunk's first payload byte is a bitfield declaring which optional features the file contains. Three bits matter here:

| Bit | Meaning | |---|---| | 0x20 | An ICC profile is present | | 0x08 | An EXIF chunk is present | | 0x04 | An XMP chunk is present |

Drop the EXIF chunk and leave the flags byte alone, and the file now states in its header that it contains EXIF metadata which is not there. It is a container that contradicts itself.

Most viewers tolerate this — they look for the chunk, do not find it, and move on. Stricter parsers and validators do not, and the inconsistency is exactly the kind of thing that makes a file fail somewhere down the line for reasons nobody can trace back to a metadata tool.

MetaPurify rebuilds the chunk list first, then checks which of EXIF, XMP and ICCP actually survived, and clears the corresponding bits in the copied output's VP8X chunk to match. The flags always describe the file you get. The source bytes are never modified in place.

What MetaPurify does with a WebP

To summarise the behaviour for a WebP specifically:

• Removes EXIF and XMP chunks in still and animated files, and C2PA chunks when Content Credentials removal is selected. VP8X has no presence flag for C2PA, so dropping that chunk needs no flag repair.
• Rewrites rather than drops EXIF when you keep orientation, leaving a minimal EXIF container holding the rotation tag so the image still displays the right way up.
• Keeps ICCP by default, so colours render as intended. Turning colour-profile preservation off removes it and clears the 0x20 flag.
• Preserves every image payload chunk unchanged, and recomputes the RIFF size for the new file.
• Verifies by reparsing the output and confirming the chunks backing each selected category are gone — see how to verify metadata was actually removed.

One current limit, stated plainly: WebP files are handled up to 25 MB and 50 megapixels. AVIF — despite often being discussed alongside WebP — is a different container entirely: the browser can decode it for conversion, but its metadata is not inspected or removed.