EXIF vs IPTC vs XMP vs GPS: How Metadata Fits into Modern Image Pipelines

If your image pipeline only preserves pixels, you are probably losing useful data.

A modern image file can carry multiple metadata layers at once: technical camera data, location coordinates, rights and credit fields, editable descriptions, workflow information, and application-specific properties. That metadata can affect archives, DAM workflows, publishing pipelines, debugging, licensing, and image SEO operations.

This post is a technical adaptation of the original guide on GeoImageTagger. The full canonical version lives here: Understanding Image Metadata: EXIF, IPTC, XMP and GPS Data Explained.

The useful mental model

The cleanest way to model image metadata is by purpose:

• EXIF = capture and device data
• IPTC = descriptive and rights metadata
• XMP = extensible framework for modern metadata exchange
• GPS = location data, often stored in the GPS area of EXIF

That sounds simple, but in real systems the boundaries blur because one file can contain all of them, and software may write overlapping values into multiple places.

What each layer is good at

EXIF

EXIF is the default technical layer written by cameras and phones. Typical fields include:

• device make and model
• lens data
• exposure settings
• timestamps
• orientation
• image dimensions
• GPS coordinates when enabled

In the Exif spec, GPS data is stored in a separate GPS IFD, which is why developers often encounter it as a distinct metadata block even though it is functionally part of Exif-oriented file metadata.

IPTC

IPTC is the descriptive and administrative layer. This is where you usually want:

• Creator
• Credit Line
• Copyright Notice
• captions and descriptions
• keywords
• location descriptors
• licensing-related fields

If you care about attribution and publishability, IPTC is a big deal.

XMP

XMP is the flexible container and exchange layer. It is common in Adobe workflows and in many DAM systems because it can store a wide range of metadata cleanly and extensibly.

It is also where a lot of modern IPTC-compatible fields are expressed. In practice, that means XMP often becomes the interoperability layer between apps, editorial systems, and file workflows.

GPS

GPS metadata is about location, not ranking magic.

It is useful for inspections, field operations, travel archives, local-photo organization, and certain publishing workflows. But it should be treated as location context, not as a replacement for page relevance, HTML alt text, structured data, or strong site architecture.

File-level metadata vs page-level metadata

This is the distinction most technical SEO discussions need to make earlier.

File-level metadata lives in the image or in a sidecar:

• EXIF
• IPTC
• XMP
• GPS
• ICC profiles
• provenance metadata

Page-level image metadata lives in the document or HTML environment:

• alt
• surrounding headings and copy
• captions
• structured data
• og:image
• canonical context
• internal links
• crawlability and indexing signals

If you are optimizing images for the web, both layers matter. But page-level signals usually matter more for search interpretation.

A practical inspection workflow

When you ingest or publish images, verify metadata at these points:

1. before editing
2. after export from the editing app
3. after compression
4. after format conversion
5. after CMS upload if your platform rewrites media

That catches the most common failure mode: successful image transformation with silent metadata loss.

For command-line inspection, ExifTool is still the reference utility in most technical workflows.

exiftool -G1 -a -s sample.jpg

That gives you grouped output and helps you see whether fields are living in EXIF, IPTC, XMP, or elsewhere.

Writing metadata in a pipeline

A simplified example with ExifTool might look like this:

exiftool \
  -overwrite_original \
  -GPSLatitude=40.7128 \
  -GPSLongitude=74.0060 \
  -IPTC:Keywords+="brooklyn bakery" \
  -IPTC:Keywords+="custom cakes" \
  -XMP-dc:Description="Custom cake display inside a Brooklyn bakery" \
  image.jpg

The exact tags you write should depend on the format and your standardization rules, but the important idea is this: write intentionally, not opportunistically.

Do not assume the right field got populated just because the UI shows a description somewhere.

Structured data is not the same as embedded metadata

This is another important engineering distinction.

Google’s image-related documentation makes it clear that embedded IPTC metadata and page-level structured data are separate inputs. Structured data is associated with the page instance, while IPTC travels with the image file itself.

A minimal ImageObject example looks like this:

{
  "@context": "https://schema.org/",
  "@type": "ImageObject",
  "contentUrl": "https://example.com/images/storefront.webp",
  "license": "https://example.com/license",
  "acquireLicensePage": "https://example.com/licensing",
  "creditText": "Example Studio",
  "creator": {
    "@type": "Person",
    "name": "Alex Rivera"
  },
  "copyrightNotice": "Example Studio"
}

This is page-level markup. It does not replace the file metadata. It complements it.

Format conversion is where metadata often breaks

This is where image-processing pipelines get messy.

A conversion to WebP, a lossy export, a CMS thumbnail step, or a CDN rewrite may preserve all metadata, preserve some of it, or strip it entirely. The problem is not always the format. It is often the toolchain.

That is why format support and tool support should be treated as separate questions:

• Can the format store the metadata?
• Does this tool preserve it by default?
• Does the receiving system read it correctly?

If you want a browser-based way to verify what is actually present in a file, GeoImageTagger’s Metadata Viewer is useful for quick checks. If you also need to optimize images without losing important fields, the platform’s tools hub includes browser-based compression and conversion utilities aimed at preserving metadata during processing.

The SEO reality check

From a technical SEO perspective, the right priority stack looks like this:

1. make the page crawlable and indexable
2. use descriptive filenames
3. write useful alt text
4. keep the image near relevant copy
5. use structured data where it makes sense
6. optimize dimensions and file size
7. preserve embedded metadata when it has attribution, licensing, location, or workflow value

That is a much stronger model than treating geotagging or EXIF alone as a ranking shortcut.

What teams should standardize

If you manage an image-heavy product, a content library, or a local business media workflow, document these rules:

• required descriptive fields
• required rights fields
• location retention rules
• compression and conversion behavior
• post-processing verification steps
• HTML image requirements for the CMS
• which formats can use embedded metadata vs sidecars

The win is not “more metadata.” The win is predictable metadata.

Closing thought

The best image pipelines do two things well:

• preserve meaning inside the file
• preserve context on the page

EXIF, IPTC, XMP, and GPS each do a different job. Once your team understands that, debugging gets easier, publishing gets cleaner, and your SEO workflow stops depending on guesswork.

If you want the broader strategic version of this topic, including the SEO and local-business angle, read the original article here: Understanding Image Metadata: EXIF, IPTC, XMP and GPS Data Explained.