Remove EXIF Data From JPEG Photos
01 Why JPEG is the format most "EXIF remover" tools were built around
JPEG is old (1992) and still the default output of most cameras and older phones. Its metadata lives in numbered "APP" marker segments inside the file - APP1 usually carries EXIF (camera model, GPS, timestamps) and sometimes XMP as well, APP2 often carries an embedded ICC color profile, and a plain COM segment can hold arbitrary free-text comments. All of it sits before the actual image data and is trivial to read with the right tool - which is exactly why JPEG metadata stripping is the most mature, most competitive corner of this whole space.
Go deeper: quantization tables, thumbnails, and what "quality" actually changes
JPEG's DQT (quantization table) markers control how aggressively each 8x8 block of the image is compressed - read directly, not estimated, this tool shows the actual table values rather than guessing at a "quality score" the way some forensic tools do. EXIF also frequently carries a second, smaller embedded thumbnail image, generated once and often left stale after later edits - if that thumbnail shows something the main image doesn't, that's a genuine, checkable sign of after-the-fact editing, covered in more depth on the metadata page.
A real, separate risk worth knowing about: JPEG's end-of-image marker (0xFFD9) is well defined, but plenty of malformed or deliberately booby-trapped files append extra data after it - a classic "polyglot" trick where a second file (a script, an archive) rides along inside what looks like an ordinary photo. Full pixel reconstruction, which is what actually happens here regardless of preset, discards anything after that marker as a structural guarantee, not a special check.
A real history worth knowing about
Image-decoding libraries have a documented history of serious security flaws - not a hypothetical risk. "ImageTragick" (CVE-2016-3714), a 2016 vulnerability in a widely used image library, let a specially crafted image file run commands on the server that processed it, and was found being exploited in the real world. That's the kind of thing full pixel reconstruction is actually built to defend against: nothing about the original file's bytes reaches anything capable of running them, regardless of what a decoder bug elsewhere might have let through.
Choosing a compression preset for JPEG specifically
Unlike PNG or GIF, JPEG quality is a real, meaningful tradeoff - Lossless mode here targets very high quality (and can occasionally end up larger than a heavily-compressed original, since it prioritizes fidelity over size), Balanced targets a sensible middle ground, and Super Compressed cuts real weight when file size matters more than pixel-perfect quality. All three strip every byte of metadata identically - the preset only changes the pixel compression, never what gets removed.