Lossless EXIF removal vs re-encoding: why the mop matters
There are two ways to get metadata out of a photo. One decodes the image, throws away everything but the pixels and saves a brand-new file; the other opens the container, removes the blocks that hold metadata and copies the compressed image data exactly as it was. Both produce a file without EXIF. Only the second one produces the same picture. This guide explains where metadata lives in JPEG, PNG and WebP, what re-encoding costs, and the orientation trap that catches even careful tools.
Anatomy of a JPEG
A JPEG file is a sequence of segments, each introduced by a two-byte marker. It opens with SOI (FF D8) and closes with EOI (FF D9). Between them come the application segments: APP0 holds the JFIF header, APP1 holds EXIF (a small TIFF structure with the IFD0, Exif and GPS directories, plus an embedded thumbnail) and, in a second APP1, XMP; APP2 carries the ICC colour profile; APP13 carries Photoshop and IPTC data; COM segments hold free-text comments. Then follow the tables and frame header — DQT, DHT, SOF — and finally SOS, after which the compressed image data runs to EOI.
Every metadata block sits before the image data and is self-delimited by its length field. That makes lossless removal a matter of copying: keep SOI, skip the APP1/APP13/COM segments, keep the tables and the scan, stop at EOI. Anything after EOI — Samsung motion-photo videos, HDR gain-map images referenced by an MPF index — is a trailer that a privacy tool should drop as well, because it can contain a second copy of the picture with its own metadata.
What re-encoding costs
A tool that “removes metadata” by drawing the image onto a canvas and exporting it again is running the JPEG codec twice more: decode the DCT coefficients to pixels, then quantise and entropy-code them again. Even at a high quality setting this is a second lossy generation. Quantisation errors accumulate, fine texture softens and 8×8 block edges become slightly more visible, and the file often grows because the new encoder cannot reproduce the original quantisation tables.
Colour is the less obvious loss. Modern phones shoot in Display P3 and embed an ICC profile; a canvas export converts to sRGB and drops the profile, so saturated reds and greens flatten. Wide-gamut and HDR information is gone for good. With PNG the pixels survive, but a re-export can change bit depth or palette and inflate a 200 KB screenshot to a megabyte; with WebP a lossless file is typically re-saved as lossy, and any animation becomes a single frame.
The orientation trap
Phones rarely rotate pixels. The sensor is read out in one fixed direction and the camera records how the phone was held in the EXIF Orientation tag (0x0112, values 1 to 8). Viewers apply the rotation on display. Strip EXIF completely and the tag goes with it: browsers and most modern apps still show the image sideways, because there is nothing left to tell them otherwise. This is the most common complaint about metadata removers, and it is not a bug in the viewer.
There are two honest fixes. Rotating the pixels losslessly is possible for JPEG because 90-degree rotations can be done on the DCT blocks (this is what jpegtran does), but it only stays perfectly lossless when the image dimensions are multiples of the block size, and it needs a dedicated implementation. The simpler fix is to keep the tag: write back a minimal EXIF block containing only Orientation and nothing else. That is what ExifMop does by default when a photo relies on the tag, and it is why the cleaned file may still show a 60-byte EXIF block in the inspector.
PNG chunks
PNG is built from chunks: a length, a four-letter type, the data and a CRC. The picture itself lives in IDAT chunks; IHDR describes it; iCCP, sRGB, gAMA and cHRM describe colour. Metadata arrives as tEXt, zTXt and iTXt chunks — keyword/value pairs such as Software, Comment, Author or the XMP packet under the keyword XML:com.adobe.xmp — as tIME, the last-modification timestamp, and since 2017 as eXIf, a chunk that carries an entire EXIF/TIFF block, GPS directory included, exactly as a JPEG would.
Because every chunk is self-contained and CRC-checked, removing the text, time and eXIf chunks leaves IDAT untouched and the file valid. Colour chunks are not identifying and are worth keeping; ExifMop keeps iCCP unless you ask otherwise and always keeps sRGB, gAMA and cHRM.
WebP chunks
WebP uses the RIFF container: a header with the total size, then chunks with a four-character code and a little-endian length. A simple file has a single VP8 (lossy) or VP8L (lossless) chunk and cannot hold metadata at all. The extended format starts with a VP8X chunk whose flag byte announces what follows: ICC profile, alpha, EXIF, XMP, animation. EXIF and XMP then appear as chunks of their own, the EXIF one containing a TIFF block just like the PNG eXIf chunk.
Lossless removal means dropping the EXIF and XMP chunks, clearing their bits in the VP8X flags and rewriting the RIFF size. The VP8 or VP8L bitstream is copied unchanged, so a lossless WebP stays lossless and a lossy one is not re-quantised. A canvas-based tool would instead decode and re-encode, with the same generation loss and profile stripping as for JPEG.
How to tell the two apart
You do not have to take a tool's word for it. Compare file sizes: after a lossless strip the file shrinks by exactly the size of the removed blocks — a few kilobytes for EXIF, more with XMP, an ICC profile or a trailer — and never grows. A re-encoder produces a size that has no relation to the original. Open both versions side by side at 300 % on a detailed area; lossless output is identical, re-encoded output is not. And read the cleaned file back: ExifMop lists the blocks found before and after cleaning so that the result is verified rather than assumed.
The takeaway
Metadata lives in separate segments and chunks, so a good remover cuts them out and copies the compressed pixels untouched. Re-encoding recompresses the picture, drops the colour profile and loses the orientation tag. Prefer lossless removal, keep the ICC profile, and keep a minimal Orientation tag when the photo needs it.
More guides
What the GPS data in your photos reveals (and how precise it really is)
The GPS block in a photo is more than a pin on a map: altitude, heading, satellite time and a trail of routine. Here is what the tags hold, how accurate they are, and who reads them.
Which apps and platforms strip EXIF — and which don't
Social networks mostly strip metadata from what they publish, messengers depend on how you send, and email and cloud drives keep everything. What is known as of 2026, and how to check for yourself.