The journey of an image
Provenance data lives inside the image file: IPTC fields for captions, credits and the digital source type, EXIF for camera details, and C2PA manifests for signed history. Any tool that decodes the pixels and writes a new file decides afresh what to keep. Many keep nothing, because metadata is weight and most sites never read it.
Step by step, where it goes missing
| Step | What usually happens | What you can do |
|---|---|---|
| Export from an editor | Settings may drop metadata to reduce size | Enable keeping metadata and credentials on export |
| WordPress upload | Resized copies are regenerated; the image_strip_meta filter controls stripping in some setups | Check the filter and your image library behaviour |
| Optimisation plugin | Often strips metadata by default | Exclude featured and og images, or keep IPTC |
| CDN image resizing | Frequently strips unless told otherwise | Use a preserve-metadata option where offered |
| Social network upload | Re-encodes and usually removes most fields | Nothing on your side; rely on page captions |
The WordPress developer reference documents the image_strip_meta filter for image editors that support it, which is the switch to look at when resized copies lose their fields. Check it on a staging copy rather than assuming, because behaviour depends on the image library your host provides.
A practical setup for provenance
- Keep the original upload intact and point
og:imageat a size that is generated with metadata kept, or at the original when it is already 1200 by 630. - Exclude featured images from aggressive optimisation, or configure the optimiser to preserve IPTC and C2PA data.
- After publishing, download the image from your own page and inspect it. If the fields are gone there, no network will ever see them.
- Keep a caption on the page regardless, as the guide to labelling AI images in link previews recommends.
The IPTC Photo Metadata Standard lists the fields and where they are stored, and the C2PA specification describes how manifests are embedded. Both assume the file is left alone; the practical work is making sure your own stack does that. For the reader's side of the same problem, see checking Content Credentials before you share. The rest of the provenance section covers the authorship signals that do not depend on files at all.
Image metadata stripped in WordPress: a worked example
Take a test upload: a 2400 by 1260 JPEG with a caption, a credit, a digital source type and a signed manifest, uploaded to a WordPress site that runs an optimisation plugin and a CDN with on-the-fly resizing. The results are invented but typical. Downloading each generated copy and inspecting it shows the original intact; the 1536, 1024 and 768 wide sub-sizes with EXIF and IPTC removed and no manifest; the optimiser's WebP copies with nothing at all; and the CDN's resized responses with nothing at all, even for the original address, because the CDN re-encoded it on the way out.
Three settings changes fix most of it in the example. Returning false from the image_strip_meta filter keeps EXIF and IPTC on the sub-sizes, though not the manifest, since the pixels change. Excluding the media folder used for share images from the optimiser keeps their files byte for byte. Turning on the CDN's preserve-metadata option for that folder stops the last rewrite. After the changes, the file at the og:image address carries caption, credit, source type and a valid manifest, and the sub-sizes carry caption, credit and source type.
Pitfalls
- Testing the original address through the CDN and assuming the bytes match the upload. Fetch with the CDN bypassed and compare file sizes.
- Keeping metadata on every image, including location fields from staff phones. Strip GPS and keep the provenance fields.
- Regenerating thumbnails with a plugin after changing the filter, then forgetting that the optimiser runs again on each new file.
- Assuming a plugin's keep-metadata setting covers WebP or AVIF output. Some libraries write those formats without any metadata support.
- Expecting a network to keep what your own server kept. Uploads and preview fetches are typically re-encoded; the platform side is covered in what platforms strip from shared images.
Check it worked
Fetch the og:image address and the largest sub-size directly, both through the CDN and with it bypassed, and inspect each file with a metadata reader and a C2PA reader. Then share the page once on each network and download the preview image from the network's debugger. Log all of it in one table; the rows below are examples.
| Page | Fetched from | Time (UTC) | File size | File carried |
|---|---|---|---|---|
| /2026/09/river-walk/ | Origin, CDN bypassed | 2026-09-15 13:02 | 184 KB | EXIF, IPTC, valid manifest |
| /2026/09/river-walk/ | CDN, same address | 2026-09-15 13:06 | 97 KB | Nothing (re-encoded) |
| /2026/09/river-walk/ | CDN after preserve option | 2026-09-15 13:40 | 184 KB | EXIF, IPTC, valid manifest |
| /2026/09/river-walk/ | Facebook debugger image | 2026-09-15 13:48 | 88 KB | Nothing |
The last row is the expected end state on most networks. The point of the exercise is the first and third rows: your own copy of the file should carry what you put in it, so that anyone who fetches it from your page, rather than from a feed, can verify it.
Sources
- WordPress developer reference: the image_strip_meta filter
- IPTC Photo Metadata Standard 2025.1
- C2PA Content Credentials technical specification 2.1
Questions
Does WordPress remove image metadata?
It can, depending on the image library and the image_strip_meta filter. Resized copies are the usual place fields go missing, so test your own install.
Do CDNs strip EXIF and IPTC data?
Many image resizing services strip metadata by default to save bytes. Look for an option to preserve it for the images that need provenance.
Do social networks keep image metadata?
Most re-encode uploads and remove most fields. Some read provenance data on upload before stripping it, which is how certain labels are applied.
Should I keep GPS data in published photos?
Usually not. Keep credit, caption and source type fields, and drop location for privacy.
How do I test whether my site strips image metadata?
Upload a file with known caption, credit and source type values, download every generated copy and the og:image address, and inspect each with a metadata reader. Compare the CDN response with a direct fetch from the origin.
Hannah Voss, Editor. Checks every guide against a working WordPress install and the networks' current documentation. Last reviewed September 2026.
Related reading
- 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
- Labelling AI-generated images in link previewsHow to label an AI-generated og:image honestly: captions, alt text, digital source type metadata and what networks show when the card is shared.6 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
- Facebook showing the wrong image or share textFix Facebook showing the wrong image or text when you share a WordPress post: duplicate tags, small images, cache, blocked crawlers, and the Sharing Debugger.7 min read