Remove EXIF data from a JPG

What we remove from a JPEG

We walk the file's marker structure and drop the segments that carry metadata, copying everything else byte for byte.

• APP1 — the EXIF block, holding GPS, device, timestamps and serials, plus any XMP packet.
• APP13 — Photoshop and IPTC resources: captions, credits, keywords, editing paths.
• COM — free-text comments.
• Any other unrecognised APPn segment — default-deny, not a fixed list. See below.
• Trailing bytes — anything appended after the end-of-image marker, which is non-standard and a known hiding place.

What we deliberately keep

• The ICC colour profile, so your colours still render correctly. You can drop it if you want.
• The Adobe APP14 marker, which carries the colour transform flag. Strippers that remove it silently wreck the colour of CMYK JPEGs.
• Every byte of compressed image data, which is why the before and after hashes match.

Why we don't keep a list of "bad" segments

JPEG's APPn range runs from APP0 to APP15, and different camera and software vendors have used slots in it for their own private data over the format's history — enumerating every vendor format that has ever existed is a losing game, so we don't try. Any APPn segment we don't specifically recognise as safe gets removed by default, the same way an unlisted PNG chunk does. A segment identified as FPXR — FlashPix, an older embedded-thumbnail format some cameras still write — is a real example of the kind of thing this catches without needing to be named explicitly in advance.

The exceptions are narrow and named for a reason: the ICC colour profile, the Adobe APP14 colour-transform flag, and the JFIF density header a handful of older decoders still expect. Everything else is guilty until proven necessary to decode the image.

None of that touches the scan data itself, even for a progressive JPEG with several separate scan passes rather than one. The marker walk follows byte stuffing and restart markers through every scan run so each one is identified and copied whole — the same segment-by-segment copy a baseline JPEG gets, just with more segments to track.

What a real dump looks like

A JPEG straight off a phone usually nests three separate metadata systems inside its APP1 segment. A camera sub-directory holds BodySerialNumber and LensSerialNumber — identifiers that persist across every photo that body or lens has ever taken, survive a factory reset, and don't change when you switch SIM cards or accounts. A GPS sub-directory holds coordinates accurate to a few metres, plus a separate altitude tag that can narrow a location down to a floor of a building. And an XMP packet, written in a completely different syntax (RDF/XML rather than TIFF tags), often duplicates the same author and copyright fields — which is why a tool that only reads the EXIF block and stops still leaks your name.

Every tag ID, its data type, and what it means is defined in CIPA DC-X008 (Exif Version 2.32), the standard every camera and phone manufacturer implements against. It's a free PDF, and the GPS IFD section is the fastest way to see exactly how precise "GPS to a few metres" really is. For the short version — what EXIF is and how its five sub-directories break down — see what is EXIF data?

What survives common editors

Cropping or rotating a JPEG in Preview, Windows Photos, or most phone gallery apps doesn't touch its EXIF block — pixel data and metadata live in separate parts of the file, so an editor that only touches pixels leaves the rest alone. Photoshop and Lightroom keep it by default and add their own Software and edit-history tags on top of whatever the camera wrote. Messaging apps are inconsistent: iMessage and WhatsApp typically strip location on send, but the same photo attached to an email usually keeps everything. Social platforms strip metadata on upload, but only after their server has already read it — the strip happens too late to matter for privacy, only for what ends up published.

Worried that removing all this costs you anything visible? It doesn't — the compressed image data above is copied byte for byte, which is exactly what the matching hashes on your result prove.

Cleaning something else?

A PNG screenshot from the same machine carries its own timestamp and, from some editors, the canvas geometry you cropped away. A WebP export needs its container header rewritten correctly once the metadata is gone, not just the data deleted. Cleaning a whole camera roll instead of one photo? The batch cleaner has no file limit.