What EXIF Data Actually Contains (and What It Leaks)

EXIF borrows its structure from TIFF. A block of tags is arranged into image file directories, each tag being a numeric ID, a type and a value. The groups that matter in practice:

MakerNotes is the group people forget. It is proprietary, it is not covered by the specification, and it can be large. An iPhone 16 Pro Max JPEG on the test machine carried 25 Apple MakerNote tags alongside its 62 standard EXIF tags, including an accelerometer reading at the moment of capture.

Different authors, different eras, different jobs. They coexist in the same file and they frequently disagree with each other.

That last row is the one that gets people. A photo can have every GPS coordinate removed and still carry an IPTC Sub-location field reading “7th arrondissement of Paris.” Coordinates and place names are different fields in different standards, and a tool that targets GPS:all only clears the first kind.

The overlap is deliberate. IPTC’s own account is that it “worked alongside Adobe on the technical implementation” of XMP “as an enriched alternative to the IIM format,” so a modern file often holds the same caption twice. CIPA publishes a parallel standard for the EXIF side of that mapping, DC-010-2026, “Exif metadata for XMP,” last revised in June 2026.

The file below is public, so you can reproduce this exactly. It is Arc de Triomphe de l’Étoile 20221115 (01).jpg by Katie Chan on Wikimedia Commons, CC BY-SA 4.0: 7,573,756 bytes, 6,241 × 4,161, Canon EOS 5D Mark IV. Download it and run exiftool -a -G1 -s and you will get what follows.

First, the shape of it. 342 tags, in seven standards:

exiftool -a -G0 -s photo.jpg | grep -oE '^\[[A-Za-z_]+\]' | sort | uniq -c | sort -rn

 195 [XMP]            <- Lightroom's develop settings, document history, IPTC mirror
  64 [EXIF]           <- the camera's own record, including GPS
  39 [ICC_Profile]    <- colour, not identity
  22 [Composite]      <- exiftool's derived values, not stored in the file
  18 [File]           <- read from the bytes, not stored as tags
  12 [IPTC]           <- the human-written editorial fields
   6 [Photoshop]

Now the tags themselves, trimmed to the interesting ones:

[IFD0]     Make                : Canon
[IFD0]     Model               : Canon EOS 5D Mark IV
[IFD0]     Software            : Adobe Photoshop Lightroom Classic 12.0.1 (Windows)
[IFD0]     Artist              : Katie Chan
[ExifIFD]  DateTimeOriginal    : 2022:11:15 19:15:39
[ExifIFD]  OffsetTimeOriginal  : +00:00
[ExifIFD]  ExposureTime        : 1/50
[ExifIFD]  FNumber             : 2.8
[ExifIFD]  ISO                 : 4000
[ExifIFD]  FocalLength         : 200.0 mm
[ExifIFD]  LensModel           : EF70-200mm f/2.8L IS III USM
[ExifIFD]  OwnerName           : Katie Chan
[ExifIFD]  SerialNumber        : 343037005264
[ExifIFD]  LensSerialNumber    : 0000c0cf05
[GPS]      GPSLatitude         : 48 deg 51' 30.29"   (North)
[GPS]      GPSLongitude        : 2 deg 17' 40.18"    (East)
[GPS]      GPSAltitude         : 307.1 m Above Sea Level
[GPS]      GPSSatellites       : 6
[GPS]      GPSDOP              : 2
[GPS]      GPSMapDatum         : WGS-84
[IFD1]     ThumbnailImage      : (Binary data 16444 bytes)
[IPTC]     Sub-location        : 7th arrondissement of Paris
[IPTC]     Country-Primary...  : France
[XMP-xmpMM] PreservedFileName  : 20221115-EM4A0217.CR2
[XMP-crs]  Exposure2012        : +0.30
[XMP-crs]  Highlights2012      : -54

Read that as a story rather than a table and it says: a Canon body with serial number 343037005264, wearing a 70-200 mm lens racked out to 200 mm, wide open at f/2.8 and ISO 4000 because it was after dark, on 15 November 2022 at 19:15:39 UTC, standing at 307 metres above sea level with a six-satellite fix, in the 7th arrondissement of Paris. The file also still names the original RAW it came from and remembers that the highlights were pulled down 54 points in Lightroom.

One detail is worth pausing on, because it is the most misunderstood thing about GPS in photographs. Those coordinates are 1.6 metres from the published location of the Eiffel Tower. The photograph is of the Arc de Triomphe, 1.71 km away. EXIF records where the camera was. It has no idea what the camera was pointed at.

In a JPEG, before the picture. A JPEG is a sequence of marker segments, and the metadata standards each get their own. Parsing the same file’s bytes directly:

APP1   17,768 bytes   "Exif"                        <- EXIF, including GPS
APP13  16,736 bytes   "Photoshop 3.0"               <- IPTC, inside a Photoshop resource block
APP2    3,160 bytes   "ICC_PROFILE"                 <- colour profile
APP1   14,155 bytes   "http://ns.adobe.com/xap/1.0/"<- XMP
DQT / SOF0 / DHT                                    <- the JPEG tables
SOS                                                 <- and only now, the actual image

Fifty-two kilobytes of description before a single pixel. That is 0.68% of this file, and a much larger share of a small one.

Other containers put it elsewhere, which is why generic advice about “the EXIF header” fails:

• TIFF has no separate block. EXIF is the TIFF directory structure, which is why the two look so similar.
• PNG uses an eXIf chunk, with XMP in an iTXt chunk and loose key/value pairs in tEXt. A PNG converted from our test file carried a 17,760-byte eXIf chunk and 74 separate tEXt chunks.
• HEIC is an ISO base media container, so EXIF sits in a metadata item inside the meta box, alongside HEVC configuration records.
• PDF does not use EXIF at all. It has a document information dictionary and an XMP packet, holding Title, Author, Creator and Producer.

Because the same fact is often stored more than once, in more than one standard, and nothing keeps the copies in sync. Our test file states the creator’s name three times: as EXIF Artist, as IPTC By-line, and as XMP dc:creator. It names Paris in EXIF coordinates, in IPTC Province-State, and in XMP photoshop:State. An application that reads only one of those will show you one answer.

The IPTC standard anticipated this and built in a tamper check that almost nobody knows about. When software writes IPTC data it also stores an MD5 digest of that block. exiftool recomputes the digest on read and shows you both:

exiftool -s -CurrentIPTCDigest -IPTCDigest photo.jpg

CurrentIPTCDigest  : 1455afc50d25486015f28f9211771793
IPTCDigest         : 1455afc50d25486015f28f9211771793

They match, so the IPTC block has not been touched since the last application that wrote it. Change a single IPTC field and the two diverge immediately:

exiftool -IPTC:City="Nowhere" photo.jpg
exiftool -s -CurrentIPTCDigest -IPTCDigest photo.jpg

CurrentIPTCDigest  : 090bd0dcbcdbf3a8a02503e24948b9c3   <- recomputed now
IPTCDigest         : 1455afc50d25486015f28f9211771793   <- what the writer recorded

A mismatch is Adobe’s signal that IPTC and XMP have drifted apart and the XMP copy should win. It is also, incidentally, evidence that someone edited the file.

One more number worth carrying around, because it explains why metadata is a file-size question as well as a privacy one. On the 6,241-pixel original, all four metadata blocks together came to 51,827 bytes: 0.68% of the file. Resize that same image to 600 pixels wide, keeping the metadata, and the file is 185,898 bytes of which 54,432 bytes are metadata. That is 29.3%. The smaller the picture, the larger the share of it that is description.

Most of EXIF is inert. Shutter speed identifies nobody. These are the fields that do real work in an investigation, ranked roughly by how much:

The thumbnail deserves its own warning, and it is easy to demonstrate. Crop the test image from 6,241 pixels wide down to 2,000, copy the metadata across the way most conversion workflows do, and extract the embedded thumbnail from the result. It is still 256 × 171 and byte-identical to the one in the uncropped original. The visible image was cropped. The copy inside the metadata was not.

This is how redactions have failed in public before, and it is a reason to prefer removing metadata over editing it.

Three routes, in increasing order of completeness.

# 1. Preview, no install: open the image, then
#    Tools > Show Inspector, and pick the metadata tab.

# 2. Spotlight already parsed it at index time
mdls -name kMDItemLatitude -name kMDItemAcquisitionModel photo.jpg

# and this finds every geotagged file it knows about
mdfind -onlyin ~/Pictures 'kMDItemLatitude > -180'

# 3. exiftool, which is the only one that shows you everything
brew install exiftool
exiftool -a -G1 -s photo.jpg

The flags on that last command matter. -G1 prints the group each tag came from, so you can tell EXIF from IPTC from XMP. -a shows duplicates, which is how you discover that a file states the same fact twice in two standards. -s prints the short tag names, which are the names you would use to write or delete a tag.

One quirk worth knowing, because it confuses people reading their first dump. By default exiftool shows GPSLatitude in the Composite group, because it merges the raw numeric tag with its separate GPSLatitudeRef hemisphere tag into one signed value. Add -a and you see both: the real [GPS] GPSLatitude and the convenience [Composite] GPSLatitude.

EXIF is a record of what the camera believed, which is not the same as what happened. Four limits that matter when you are reading someone else’s file:

• It is trivially editable. Any of these tags can be rewritten in one command. EXIF is evidence of nothing on its own, which is why forensic workflows hash files rather than trusting their tags.
• Timestamps drift. DateTimeOriginal comes from the camera’s clock, which nobody sets. GPSDateStamp and GPSTimeStamp come from satellites and are usually the more reliable pair.
• It describes the camera, not the scene. The 1.71 km gap in the example above is the general case, not an oddity. Telephoto lenses, windows and viewpoints all break the assumption.
• Absence proves nothing. A file with no EXIF has been through something, and that something is usually an upload, a screenshot or a messaging app. It is not evidence that the photo was never geotagged.

To read metadata, install exiftool and stop there. It is free, it is the reference implementation the rest of the industry checks itself against, and no paid app shows you more than exiftool -a -G1 -s does. To read it without installing anything, Preview’s Inspector covers the common fields.

To edit metadata, exiftool again. Correcting a wrong capture date across a shoot, writing a copyright line into 400 files, or copying a GPS track onto un-geotagged frames are all one-line exiftool jobs and are not things a drop-target app should be doing.

To remove it, the routes and their measured differences are in how to remove EXIF data on Mac, and the location-specific version, including the Photos library, is in stripping GPS from photos before you share, with a three-step version in our help docs. If your concern is privacy rather than tidiness, read why removing EXIF no longer makes a photo location-anonymous before you decide you are finished, and what PDF compression does to document metadata if you work with files rather than photographs.

We make Smol, a $29 Mac app that strips metadata from a folder in one drop without re-encoding the images, which matters when you have 400 files and not when you have one.