What Metadata Survives WebP Conversion? A Controlled Test

The original fixture contained separate EXIF, XMP and ICC chunks. We compared segment-level privacy cleaning with browser conversion so the result would not mix two very different operations.

Use cleaning when you want to keep the existing compressed image payload. Use conversion when you need a new format or dimensions and accept re-encoding.

A WebP file can reach the same extension through two very different paths. Metadata-only cleaning edits selected RIFF chunks around the existing VP8, VP8L or animation payload. Conversion decodes an input and asks the browser to encode a new WebP.

That difference determines what “survives” means. In cleaning, encoded image chunks can remain byte-preserved. In conversion, ordinary source metadata is usually not copied, but the visible image receives a new encoding and may have different compressed bytes.

The controlled WebP contained separate EXIF, XMP and ICCP chunks around a deterministic image payload. We inventoried the chunks, ran the privacy cleaner, then compared that output with a browser-created WebP from the same visible source.

The cleaner output was reparsed to confirm EXIF and XMP were gone, ICC remained under the color-preserving policy and the image payload was unchanged. The conversion path was accepted only when the browser returned a real WebP MIME type and the new file parsed successfully.

EXIF and XMP may contain location, owner, serial or workflow details. ICC normally describes how numeric colors should be interpreted. Removing a profile can change appearance without improving privacy, so the default cleaner keeps it.

A browser conversion may not copy the embedded profile through a canvas path. That can be acceptable for an ordinary sRGB web derivative, but color-critical work should use a managed export and verify the resulting profile with the color checker.

Use the WebP analyzer first to check animation, alpha, EXIF, XMP and ICC. If the dimensions and format are already correct, clean a separate copy. If you need resizing or compression, convert and compare the visible result at the intended display size.

Keep the original in either case. Recheck the output and state the conclusion narrowly: which chunks were detected or removed, whether the payload was preserved or re-encoded, and which characteristics were outside the test.

Three deterministic states are enough to verify the designed code path, not to benchmark every encoder or WebP variant. Animated files, unusual extended headers, malformed sizes and browser codec changes can behave differently.

The tool applies bounds and rejects contradictory containers rather than promising repair. When another application produces the output, inspect that exact file because metadata-preservation policy belongs to the workflow, not to the WebP extension itself.

Create a non-sensitive fixture or copy an ordinary test image, add clearly synthetic EXIF and XMP values, and keep an ICC profile only when color behavior is part of the question. Record the input hash and chunk inventory before processing.

Run cleaning and conversion as separate branches. For the cleaner, compare the encoded image chunk bytes. For conversion, verify MIME, signature, dimensions and the new metadata inventory. This produces evidence another person can audit without needing your personal photo.