Three metadata layers, three ways to die
EXIF is the oldest layer: a TIFF-structured block of camera fields, such as make, model, exposure, orientation and GPS position, stored in a JPEG's APP1 segment. The IPTC Photo Metadata User Guide describes how that block sits beside the IPTC and XMP layers. A decoder that re-encodes the pixels without copying that segment drops EXIF completely. Most upload pipelines do exactly that, and some apply the orientation field to the pixels first, so the image looks correct while the field is gone.
XMP and IPTC fields are the descriptive layer: caption, credit, copyright, and the digital source type that says whether an image came from a camera or a trained algorithm. The IPTC Photo Metadata Standard specifies how these fields are stored, as an XMP packet and in the older IIM block. Editors usually copy them on export; optimisers and upload pipelines usually do not. They die by omission, because most software never reads them.
A C2PA manifest is the signed layer. The C2PA specification stores the manifest in a JUMBF box and binds it to the content through hashes over the asset, so the manifest is valid only for the exact bytes that were signed. This layer dies twice: when a pipeline drops the box, and when it keeps the box but changes the pixels, which leaves a manifest present but invalid. The specifications index lists the current version.
Link preview fetch versus direct upload
The two ways an image reaches a platform behave differently. A direct upload hands the platform your file; it is typically resized and re-encoded, and the platform may read the metadata before discarding it, which is how some AI labels are applied. A link preview fetch is a request to your server for the address in og:image, followed by the platform's own resize and re-encode; nothing about it gives your metadata a route to the card. Both channels typically end with a file that carries little or nothing.
A third channel matters: a reader saving your image and re-uploading it, or forwarding it through a messaging app. Every hop re-encodes, and by the third hop no layer is left. The steps before the platform, on your own WordPress and CDN, are covered in where image metadata gets stripped on your own site.
What platforms strip from shared images: channel by layer
The table gives typical outcomes, because behaviour differs by platform and changes without notice. Confirm each row for your own channels with the probe below, and date the results.
| Channel | EXIF | XMP and IPTC | C2PA manifest | How to check |
|---|---|---|---|---|
| Direct upload to a network | Typically stripped | Typically stripped; may be read first | Typically stripped, or kept but invalid | Download the posted image |
| Link preview fetch of og:image | Typically stripped | Typically stripped | Typically stripped | Download the card image from the debugger |
| Messaging app forward | Typically stripped | Typically stripped | Typically stripped | Have the recipient send the file back |
| Download from a platform after posting | Typically absent | Typically absent, sometimes rewritten | Typically absent | Compare with your original |
| Your own CDN with metadata preserved | Kept | Kept | Kept and valid if bytes are unchanged | Fetch with and without the CDN; compare hashes |
A worked probe: 12 images with distinctive values
The reliable way to know what a channel does is to send it a file whose fields you can recognise in the bytes. Prepare 12 JPEGs at 1200 by 630. In each, set the EXIF artist field to a marker such as PROBE-EXIF-0412, the XMP creator and IPTC credit to PROBE-XMP-0412, the digital source type to the value for a trained algorithm, and sign a manifest. Push four images through each of three channels: direct upload, a link share whose og:image is the probe, and a messaging forward. Download every copy, search its bytes for the markers and open it in a C2PA reader.
The results in this example are invented but typical of what such probes find. Of the 4 direct uploads, 0 kept the EXIF marker, 0 kept the XMP marker, and 1 kept a manifest box that a reader reported as present but invalid, because the pixels had been resized. The 4 link shares and the 4 messaging forwards kept no layer at all. The control, the 4 originals fetched from the publisher's own CDN with metadata preserved, kept all three layers with hashes identical to the uploads. The probe took under an hour and produced a dated answer for those channels.
Stripped, rewritten and preserved
A downloaded copy is in one of three states, and the log should say which. Stripped means the segment is absent: no EXIF block, no XMP packet, no JUMBF box. Rewritten means a segment is present but its contents are the platform's: a new software tag, orientation set to normal, an XMP packet with none of your fields. Preserved means the bytes match: your markers, and for a manifest, a signature that still validates. Only the third state carries provenance. Rewritten fields mislead most, because a reader shows a populated panel.
| State | How you recognise it | What it means for provenance |
|---|---|---|
| Stripped | Segment absent; file smaller; reader shows nothing | Nothing travels; rely on the page |
| Rewritten | Fields present but the platform's; manifest present but invalid | Proves nothing about the original |
| Preserved | Your markers present; manifest validates; hash matches | Credentials can be checked |
What a publisher can do
You cannot make a platform keep your metadata, so put the facts where a reader can find them without the file. Keep the Content Credential on the page: a caption saying how the image was made, a link to the original signed file at a stable address, and the signer's name. Keep the digital source type in the file you serve, so a platform that reads before it strips gets the right value; the guide to labelling AI-generated images in link previews gives the wording. Write alt text that describes the image plainly. Serve og:image at the size set out in choosing an Open Graph image size, so at least the crop is yours.
- Point og:image at the signed original and exclude it from optimisation.
- Publish a verification path: original file, signer, date. A reader with a stripped copy can come to your page and check it, using the routine in checking Content Credentials before you share.
- Repeat the probe after platform announcements about provenance and after any change to your own pipeline.
Pitfalls
- Reading a populated metadata panel as proof of preservation. Check for your own markers or compare hashes first.
- Probing with an image whose fields you did not set. Without known values you cannot tell stripped from rewritten.
- Assuming a manifest that survived as bytes is still valid. The signature covers the pixels; resized pixels fail it.
The provenance section covers the signals that do not depend on the file: the byline, the head tags and the disclosure line that travel with the page.
Sources
- IPTC Photo Metadata User Guide (how Exif, IPTC and XMP fields are written and read)
- IPTC Photo Metadata Standard: overview
- C2PA technical specification 2.2
- C2PA specifications index
Questions
Is EXIF stripped on upload to social media?
Typically yes. Most upload pipelines re-encode the image without copying the EXIF segment. Confirm for your platforms by uploading a file with a known artist field and downloading the posted copy.
Does XMP metadata survive on social media?
Typically not. XMP and IPTC fields are usually dropped on re-encode, though some platforms read the digital source type before discarding it. Probe with known values rather than assuming.
Is the C2PA manifest stripped when an image is shared?
In a link preview the fetched image is typically re-encoded, which removes the manifest or leaves it invalid. On direct upload behaviour varies by platform; a downloaded copy tells you the state on that day.
What is the difference between a stripped and a re-encoded image?
Stripping removes metadata segments and can leave pixels untouched. Re-encoding rewrites the pixels, which usually drops metadata too and always invalidates a C2PA signature, even if the manifest bytes are copied.
Does the preview image keep any metadata?
Typically none. The network fetches og:image, resizes it and re-encodes it. Keep the caption, credit and credential on the page.
Hannah Voss, Editor. Checks every guide against a working WordPress install and the networks' current documentation. Last reviewed September 2026.
Related reading
- Where image metadata gets stripped: WordPress, CDNs and uploadsWhere IPTC, EXIF and Content Credentials metadata is lost between your camera and a reader's feed: WordPress resizing, optimisers, CDNs and social uploads.5 min read
- Content Credentials on shared images: what survives a shareWhat C2PA Content Credentials are, why WordPress image sizes and social uploads often strip them, and how to keep provenance on the images you share.6 min read
- Checking Content Credentials before you share an imageHow to check an image's Content Credentials before you share or publish it: what a C2PA manifest shows, what a missing one means, and what to record.5 min read