Image Metadata Through the Pipeline: What Survives Optimisation

01 /The metadata blocks inside an image file

Image metadata is not one thing. A photograph that has passed through a camera and an editor carries four or five separate blocks, written by different standards bodies at different times, each in its own segment of the container. EXIF, maintained by the camera industry association CIPA, records the capture: make, model, exposure, date, orientation and, if the device had a fix, GPS coordinates. IPTC IIM is the newspaper wire format of the early 1990s, still written for creator, caption and copyright. XMP is the RDF-in-XML envelope that carries the current IPTC Photo Metadata Standard fields. The ICC profile describes the colour space. A C2PA manifest store, where present, is a signed provenance record bound to the bytes of the rest of the file.

Each block lives somewhere specific, and the location determines what happens to it later. In JPEG, EXIF and XMP each occupy an APP1 segment, IPTC IIM rides inside an APP13 segment in the image-resource block format, the ICC profile takes APP2, and the C2PA store takes APP11. The other containers have their own arrangements, set out in the table below, and a tool that understands one container's metadata does not necessarily understand another's.

02 /Which operations keep or strip each block

Plain copying keeps everything, and so does any delivery that leaves the bytes alone: caching, range requests, transport compression and TLS. The trouble starts when a tool decodes the image and writes a new file. What survives then depends on whether the encoder was told to copy metadata, whether it knows how to represent each block in the output container, and whether the operator set a strip flag, which is on by default in most web optimisation tools because it saves a few kilobytes.

Resizing and re-encoding within the same format usually preserve EXIF and XMP if the tool copies metadata, but a C2PA manifest is either dropped or, if copied, invalid, because its hash no longer matches. Format conversion is harsher: JPEG to PNG has nowhere to put IPTC IIM unless the tool folds it into XMP; JPEG to WebP keeps EXIF and XMP only if the encoder writes the extended VP8X container; JPEG to AVIF depends on the encoder's support for HEIF metadata items. The ICC profile is the block most tools preserve, because dropping it visibly changes colours. Orientation is a recurring trap: a resizer that applies the EXIF orientation tag and then copies EXIF unchanged produces an image that displays rotated twice.

03 /What social platforms and sharing services do

IPTC tests about a dozen widely used image-sharing and file-sharing sites every few years by uploading a reference image with every field populated and checking what a viewer can display, save or download; the 2019 results are the most recent published set. Most image-sharing and social platforms displayed few or no embedded fields, and the files a viewer could save had lost XMP, often IPTC IIM and EXIF as well; several stock-photo and community sites stripped everything. File-sharing services passed the original through unchanged but served previews with metadata removed. IPTC's position, that embedded metadata should not be removed, remains the standard's expectation rather than the industry's practice.

For an operator the lesson is that metadata you rely on for credit or provenance will not survive the first re-share. Keep the canonical file, with its metadata, at a stable URL of your own, and treat every copy elsewhere as stripped. The same reasoning applies to a signed manifest, which is why serving C2PA manifests through a CDN is a matter of protecting the original rather than the copies.

04 /Deciding deliberately: provenance and credit against privacy

A site that serves photographs has two legitimate interests that pull in opposite directions. Creator, copyright and credit fields exist so that the image can be attributed, licensed and, increasingly, machine-checked; stripping them removes the photographer's name from every copy and, where a jurisdiction protects rights-management information, may raise legal questions. GPS coordinates and capture times, on the other hand, can reveal where a contributor lives or was standing, and a site that publishes them by accident has published personal data.

The defensible policy is selective: keep the IPTC and XMP descriptive and rights fields, keep the ICC profile, keep any C2PA manifest intact, and remove the EXIF GPS block, and possibly the serial numbers, before the file reaches the origin store. Do the removal once at ingest, on a copy, and keep the untouched original in a private archive. Then configure the delivery path to pass the ingested file through unchanged, with the hashes and digests for bytes in transit as the proof. A policy applied at ingest is auditable; a strip flag at the edge is not.

05 /Inspecting image metadata

The reference tool for reading and writing every block discussed here is exiftool, an open-source command-line program that understands EXIF, IPTC IIM, XMP, ICC profiles and the JUMBF container across all four formats. Run it on the file as served, not as stored, since the point is to learn what the pipeline did. The -G option prints the group each tag came from, the quickest way to see which blocks are present.

$ curl -sS -o served.jpg https://example.org/photos/2026/harbour.jpg
$ exiftool -G -s -a served.jpg | awk '{print $1}' | sort | uniq -c
     14 [EXIF]
      3 [File]
      5 [ICC_Profile]
      6 [IPTC]
      2 [JUMBF]
     11 [XMP]
$ exiftool -G -EXIF:GPS* -XMP-dc:Creator -IPTC:By-line -XMP-photoshop:Credit served.jpg
[EXIF]          GPS Latitude Ref                : North
[EXIF]          GPS Latitude                    : 51 deg 30' 26.00" N
[XMP]           Creator                         : A. Example
[IPTC]          By-line                         : A. Example
[XMP]           Credit                          : Example Picture Desk
$ exiftool -GPS:all= -o ingested.jpg served.jpg
    1 image files created

The first command counts tags per group and tells you at a glance whether IPTC, XMP and the JUMBF store are still present. The second pulls the fields a publisher cares about. The third writes a copy with the GPS block removed and nothing else touched; note that it creates a new file rather than editing in place, which is the habit to keep for anything that might carry a manifest, because a rewrite is exactly what breaks one.

06 /Worked example: one photograph through a pipeline

Follow a single JPEG from a contributor's camera to a reader's screen. The camera writes EXIF with the model, exposure and a GPS fix. The contributor's editing software adds XMP with creator, description and a copyright notice, writes the same into IPTC IIM for older readers, embeds an ICC profile, and signs a C2PA manifest. At this point the file has all five blocks and exiftool reports six groups.

On upload, the ingest step removes the GPS tags and writes a copy; the manifest is now invalid, which the site accepts because it re-signs ingested files with its own certificate, recording the contributor's file as an ingredient. That signed copy is the canonical asset in the origin store. The delivery path serves it unchanged at its own URL, so a reader who saves it gets every remaining block and a manifest that validates. The responsive variants the page displays are generated separately, with EXIF and XMP copied but no manifest, each linking back to the canonical file. When a reader reposts a variant, the platform strips what is left; the credit survives only because the canonical file is a click away.

07 /Pitfalls

• The default strip. Nearly every web optimisation tool removes metadata unless told otherwise. Check the setting on every tool in the chain, including the origin's media library.
• Double rotation. Applying the EXIF orientation and keeping the tag produces images that display wrongly in browsers that honour it.
• Lost IIM on conversion. PNG, WebP and AVIF have no place for IPTC IIM. Make sure the same fields exist in XMP before converting.
• GPS in the archive. Removing location data at delivery while keeping it in a public archive folder protects nobody. Strip at ingest and keep the original private.
• Caching derivatives only. A cache that never holds the canonical file makes every reader fetch a stripped variant; the notes on caching originals for crawler traffic apply here too.

Image metadata survives a pipeline only where someone has decided it should. Inventory the blocks your files carry, write down which ones you keep and which you remove, apply that policy once at ingest and prove it on the served bytes; the rest of the wider provenance section covers how to show that what left the origin is what arrived.

Metadata survival is the practical side of the wire-provenance section: a signed C2PA manifest that must reach the reader unbroken depends on the same pipeline decisions, and a Content-Digest on the served file is how you prove the pipeline did not touch it. Verified crawlers can be given the original file while everyone else gets the optimised one.