remove‑exif
← All image formats

Remove metadata from a WebP

WebP carries EXIF and XMP in its own container chunks, and the header advertises which ones exist. Removing the data without correcting that header leaves a file some decoders reject.

Don't take our word for it — verify we can't upload your file.

What we remove from a WebP

  • EXIF — GPS, device, timestamps and serials.
  • XMP — editing history and rights metadata.
  • Trailing bytes — anything past the end of the RIFF payload.

The part that's easy to get wrong

WebP's VP8X header carries flag bits announcing which optional chunks the file contains. Delete the EXIF chunk without clearing its flag and the file claims metadata it no longer has — strict decoders and validators reject that. We clear the flags we invalidate and rewrite the RIFF size to match, so the result is a valid file rather than one that merely opens in a forgiving viewer.

What we deliberately keep

  • The ICCP colour profile, if the file has one, so colours still render correctly.
  • ALPH transparency and ANIM/ANMF animation chunks — remove these and a transparent or animated WebP breaks.
  • Every byte of image data, copied through unchanged.

What a real dump looks like

Because WebP is a RIFF container, its structure is simple to read in a hex editor: four-byte chunk tags followed by a four-byte little-endian size, repeated until the file ends. An EXIF chunk holds the same tag layout a JPEG uses internally, and an XMP chunk (the trailing space is part of the FourCC) holds an RDF/XML packet — WebP borrowed both metadata formats wholesale rather than inventing its own, convenient for tooling but inheriting every privacy problem EXIF and XMP already have.

The container layout, chunk ordering rules, and the VP8X feature-flag bits are defined in Google's WebP Container Specification. The flag bits matter more than they sound: they're what a strict decoder checks before trusting that a chunk exists at all, which is why clearing metadata without clearing the matching flag produces a file some viewers reject outright.

The flags, byte for byte

The VP8X flags live in a single byte, one bit per optional feature: 0x20 for an ICC profile, 0x10 for alpha transparency, 0x08 for EXIF, 0x04 for XMP, 0x02 for animation. Clearing a bit is one AND operation against the inverse of that flag — trivial once you know which bit maps to which chunk, and the reason a WebP cleaner has to actually parse the VP8X byte rather than just deleting chunks and hoping. Chunk payloads are also padded to an even number of bytes regardless of what the size field says, a RIFF convention inherited wholesale rather than something WebP invented — miss the padding byte when removing a chunk and every offset after it is wrong by one.

What survives common editors

Because WebP is younger than JPEG or PNG, fewer desktop editors round-trip it losslessly — many convert to PNG or JPEG internally on open and re-export as WebP on save, which strips metadata as a side effect of the conversion rather than by design. Browsers that let you "Save image as WebP" from a right-click menu generally save only the pixels, with no metadata at all. Where WebP metadata actually accumulates is content pipelines that convert from JPEG for web delivery using tools that copy EXIF across by default to preserve orientation and colour — which also copies GPS and serials across, silently.

Cleaning something else?

Converting from another format? PNG and JPG are the two most common sources of a WebP re-export, and both carry their own metadata worth checking before you convert. Want to change a value instead of removing it? Try the EXIF editor.

How this works

  1. Your file is read in your browser. Nothing is uploaded, because nothing can be — the code that touches it runs in a frame the browser blocks from making network requests.
  2. We show you everything we find before changing anything, ranked by what it actually reveals about you.
  3. We remove the metadata, not the picture. The compressed image data is copied byte for byte, and we show you the matching hashes to prove it.