Initializing, please wait a moment

EXIF Metadata and Image Compression: What Gets Stripped

Last reviewed 2026-05-06. Targeted at the moment you compress an image and wonder whether the camera details, GPS coordinates, or timestamp are still in the file. Routes the actual compression step to Compress Image (in-browser, no upload).

30-second answer. Most image compressors that re-encode a JPEG strip EXIF metadata by default - that includes camera make and model, lens, exposure settings, the original capture timestamp, and (for phone photos) GPS coordinates. This happens because re-encoding rebuilds the JPEG from decoded pixel data, and the encoder has to be told explicitly to copy the metadata block back in. If you want the metadata gone (privacy, sharing photos publicly), the default behaviour is what you want. If you want the metadata kept (archival, copyright, photography portfolio), pick a tool or library setting that preserves EXIF, or recompress with an explicit "preserve metadata" flag.

What is EXIF metadata, in concrete terms?

EXIF stands for Exchangeable Image File Format, defined by the JEITA CP-3451C standard (Exif 2.3 is the version most cameras and phones write today). EXIF is not the image pixels - it is a separate block of metadata stored alongside the pixels inside the same image file. The block is structured as a series of tagged fields, each with a numeric tag ID and a value. The container format that holds the block is TIFF (Tag-Image File Format, Adobe TIFF 6.0); EXIF inherits TIFF's image file directory (IFD) structure, so an EXIF block is essentially a small TIFF file embedded inside a JPEG, HEIC, or similar image.

An EXIF block is organised into a small number of named directories, each holding a different category of fields:

IFD0 (the primary image directory) - basic image properties: width, height, orientation flag, resolution, software name, date and time of last modification.
Exif IFD - camera-specific capture data: camera make and model, lens model, exposure time, F-number, ISO, focal length, white balance, flash status, the original capture timestamp, the digitised timestamp, and a colour-space tag.
GPS IFD - location data: latitude, longitude, altitude, GPS timestamp, direction of capture. Phones write this by default unless location services are denied to the camera app.
IFD1 (the thumbnail directory) - a small embedded thumbnail of the image, used by file managers for quick previews. Typically 160 x 120 pixels and a few kilobytes.
Interoperability IFD - flags that mark the file as conforming to the EXIF specification.

Inside a JPEG file, this whole metadata block is wrapped in a single marker segment called APP1. JPEG files (per ITU-T T.81 / ISO/IEC 10918-1) have a small set of application-marker segments numbered APP0 through APP15; APP1 is the segment EXIF lives in (it starts with the bytes FF E1 followed by the segment length and the literal string Exif\0\0). A second common segment, APP2, holds the ICC colour profile (per the ICC.1:2010-12 specification). The pixel data itself sits in the SOS (Start of Scan) segments after the application markers.

Why compression usually strips EXIF (the technical reason)

When a typical image-compression tool makes a JPEG smaller, it does not shave bytes off an existing JPEG in place - it re-encodes the image. The pipeline is: (1) decode the input JPEG back into a 2D array of RGB pixels in memory, (2) re-encode those pixels as a new JPEG at the requested quality level. The re-encoder rebuilds the file from scratch: it writes a new SOI (Start of Image) marker, a new set of quantization tables, new Huffman tables, and the new compressed pixel data. The application-marker segments (APP0 through APP15) are not part of the pixel data; they are separate top-level structures, and the encoder only writes them if the calling code explicitly hands them in.

The default encoder behaviour in most popular libraries is to not copy the application markers across:

libjpeg-turbo (the most-used JPEG codec on Linux, macOS, and Android) and mozjpeg (the Mozilla fork tuned for web compression) both write only the markers the encoder itself produces - quantization tables, Huffman tables, frame headers - and drop everything else. The cjpeg command-line tool follows the same default; preserving EXIF requires the -copy all flag or its equivalent.
Pillow (PIL) in Python - Image.save("out.jpg", quality=80) drops EXIF by default. To keep it: img.save("out.jpg", quality=80, exif=img.info.get("exif")). The metadata is not implicit; you have to pass it in explicitly.
Sharp (Node.js, libvips) - the default behaviour drops EXIF; the .withMetadata() method tells the encoder to keep it.
ImageMagick - the -strip flag explicitly removes EXIF; without it, ImageMagick tries to preserve metadata, which makes ImageMagick the exception rather than the rule.
Browser-side compression using the HTML5 <canvas> element and canvas.toBlob() - the canvas API has no concept of metadata. Drawing an image to a canvas decodes pixels only; encoding the canvas to JPEG produces a fresh file with no EXIF block at all. Web tools that compress entirely in the browser using canvas always produce metadata-free output unless they parse and re-attach the EXIF block themselves with a separate library.

The takeaway: EXIF stripping during compression is a side-effect of how re-encoding works, not a deliberate privacy feature. The encoder does not "choose" to remove metadata - it simply does not copy it across unless told to. Whether your tool keeps or drops EXIF therefore depends on a single line of code (or a single CLI flag) at the encoding step.

What is in EXIF that matters

Different fields in the EXIF block have very different stakes for different readers. The four fields most readers ask about:

GPS coordinates (GPS IFD: GPSLatitude, GPSLongitude, GPSAltitude) - written by phones unless location is denied to the camera app. Reading these tells anyone with the file where the photo was taken, often to within a few metres. This is the single most-cited privacy concern with EXIF; sharing a "selfie at home" with GPS still attached effectively shares the home address.
Capture timestamp (Exif IFD: DateTimeOriginal) - the moment the shutter fired, accurate to the second. Useful for archival; potentially sensitive if the photo dates a private event.
Camera and lens identification (IFD0: Make, Model; Exif IFD: LensModel) - tells the reader which camera body and lens shot the image. Used by photographers as portfolio metadata; harmless on most consumer photos.
Exposure parameters (Exif IFD: ExposureTime, FNumber, ISOSpeedRatings, FocalLength) - the technical settings of the shot. Useful for photographers comparing shots; harmless to share.

Two other fields worth knowing:

Orientation flag (IFD0: Orientation) - tells the renderer to rotate the displayed image 90, 180, or 270 degrees without rotating the pixels. If a compressor strips this flag and does not pre-rotate the pixels first, an image that displayed correctly on a phone may suddenly appear sideways on the web. Most modern compressors auto-rotate pixels and clear the flag (the safe behaviour); a few drop the flag without rotating, producing visibly broken output.
Copyright and author (IFD0: Copyright, Artist) - ownership fields written by some cameras and most photo-editing software. Stripping them on a public-facing compress workflow is fine; stripping them on an archival or commercial workflow may break attribution.

When to keep EXIF

Three scenarios where preserving EXIF during compression is the right call:

Personal archival - the photo is moving from a phone to a long-term photo library (a NAS, a synced folder, an external drive) and the date and GPS are part of the value: this is when and where the moment happened. Stripping the EXIF here would erase the timeline and the place.
Photographer portfolio - exposure, lens, ISO, and copyright are part of how the photographer presents their work. Some portfolio platforms render EXIF as a sidebar; some browsers display it in image properties. Keeping EXIF lets the viewer see the craft.
Forensic or evidentiary use - timestamp, GPS, and camera identification may be relevant if the image is later used as evidence. The EXIF block is not a guarantee of authenticity (any of these fields can be edited), but stripping them entirely removes information that may be needed.

Picking a tool that preserves EXIF: in browser-based tools, look for an explicit "preserve metadata" or "keep EXIF" checkbox; in command-line tools, use cjpeg -copy all, jpegtran -copy all, ImageMagick without -strip, or call your library's preserve-metadata API. jpegtran from libjpeg-turbo is the special case: it does lossless recompression (re-arranges Huffman codes without decoding to pixels) and preserves all marker segments by default, so a jpegtran -optimise pass shrinks a JPEG slightly without touching EXIF or the pixels.

When to strip EXIF on purpose

Three scenarios where stripping EXIF is the right call - the default behaviour of most compressors does the right thing here, but if you are unsure, you can also pass an image through a dedicated metadata-strip tool first:

Public sharing of phone photos - posting a photo to a public website, forum, social network, or marketplace listing. The GPS coordinates and capture timestamp are not useful to a public viewer; they are a privacy leak. Strip EXIF before upload.
File-size minimisation for the web - an EXIF block from a phone photo is typically 10 - 60 kilobytes, which can be a significant share of a heavily compressed image (a 50-kilobyte JPEG with a 30-kilobyte EXIF block is 60 percent metadata). Stripping EXIF on a web-bound compress pipeline is a free byte saving.
Public marketplaces and listings - selling a used item, posting a real-estate photo, listing a rental: any context where the listing should not reveal where the photographer lives or works. Strip EXIF before the photo leaves your device.

For batch stripping, the simplest CLI is exiftool -all= image.jpg (the exiftool utility writes a copy with all metadata removed) or jpegtran -copy none input.jpg > output.jpg (lossless, no quality change, no EXIF). Both are widely available.

What is NOT in EXIF (common confusions)

A few categories of "metadata" are often confused with EXIF but are stored in different blocks of the file - or not in the file at all:

IPTC / XMP - separate metadata standards used by photo editors for keywords, captions, copyright statements, and ratings. Stored in their own JPEG marker segments (XMP usually in APP1 alongside EXIF; IPTC in a Photoshop image-resource block). Stripping EXIF does not always strip XMP; some tools strip both, some strip only one.
ICC colour profile - the colour-management profile (sRGB, Display P3, Adobe RGB) that tells a renderer how to interpret the colour values. Stored in the JPEG APP2 marker segment per ICC.1:2010-12. ICC profile is not EXIF; some compressors strip it alongside EXIF (which can shift colours visibly on wide-gamut displays), some keep it. If colours look "off" after compression on a calibrated monitor, the ICC profile is the suspect.
Filesystem metadata (file modification date, file creation date, file owner, OS-level extended attributes) - these are properties of the file on disk, not properties of the image data. They are independent of EXIF; uploading a file generally drops all filesystem metadata even if EXIF is preserved.
Steganography or watermarks embedded in the pixels - some workflows hide data inside the pixel values themselves (least-significant-bit watermarks, frequency-domain marks). This data is in the pixel data, so re-encoding usually corrupts or destroys it; EXIF preservation does not help here.

How to check what is in your file

The simplest cross-platform inspection tool is exiftool (a free Perl utility, available on Windows, macOS, and Linux package managers). Run exiftool image.jpg and it prints every metadata field organised by directory (IFD0, Exif IFD, GPS IFD, IFD1, XMP, IPTC, ICC). If the output shows GPS coordinates, the file still has them; if it shows only basic image properties (size, format), the metadata block has been stripped.

Operating-system shortcuts also work for a quick check:

macOS Finder - select the image, press Command+I, expand "More Info" - shows camera, exposure, and (if present) GPS coordinates rendered as a small map.
Windows Explorer - right-click the image, choose Properties, click the Details tab - shows EXIF fields including GPS as latitude/longitude numbers.
Linux file managers - most file managers (Nautilus, Dolphin, Thunar) show an Exif tab in the file properties dialog if a metadata library is installed.

For a related check after compression - did the compression also visibly hurt the pixels? - the companion guide at How to Tell If a JPG Was Compressed Too Much covers the visual artefacts of over-compression, which is a different question from "did the metadata survive".

Practical recipe: keep or strip, by scenario

The decision in most workflows reduces to one question: who will see this file next?

Sharing publicly (social, listings, forums, websites) - strip EXIF. The default behaviour of most compressors does this for free. If the compressor preserves EXIF by default, run the output through exiftool -all= file.jpg as a follow-up step.
Sending to a friend or family member - keeping EXIF is fine; the GPS and timestamp may be relevant context. If the photo will be re-shared further, strip first.
Archiving to your own library - keep EXIF. Use a tool with explicit "preserve metadata" or use jpegtran -copy all for lossless recompression.
Publishing on a photography portfolio - keep EXIF. The exposure and lens fields are part of the portfolio value.
Reducing file size for a web page where every kilobyte matters - strip EXIF and ICC. Pre-rotate pixels first to avoid losing the orientation flag silently.
Forensic or evidentiary copy - keep EXIF; ideally do not recompress at all (copy the original file as-is). If a smaller copy is needed, jpegtran -copy all is the safest path.

If you are about to compress an image and you are not sure which case applies: the conservative default is to strip EXIF when sharing externally and keep EXIF when storing internally. The companion guide on choosing a quality level is at How to Choose a Compression Level; the companion guide on whether compression is even the right operation (vs format conversion) is at When to Compress vs Convert an Image.