Your CMS Is Probably Stripping Your Image Metadata (Here's How to Check)

Here is a test worth running on your own site right now. Open any page with an image on it, copy the image URL out of the rendered markup, download that exact file, and look at its metadata.

On a large proportion of sites, the answer is that there is none. Not reduced. None.

This surprises people who have been carefully embedding descriptions and copyright fields for years, and it should, because nothing in the process announces itself. There is no warning, no log line, no validation error. The file goes in with metadata and comes out without it, and every tool in the chain considers this correct behaviour.

Where it actually disappears

Metadata can be removed at four separate points between your desk and a visitor's browser, and most sites have at least two of them active.

On upload. Some platforms normalise images as they arrive, re-encoding them into a standard format and size. Re-encoding without explicitly copying metadata across discards it.

On derivative generation. This is the big one and the one almost nobody accounts for. A CMS that generates thumbnails and responsive sizes is creating new files, and those new files typically carry little or none of the original's metadata. The original in your media library is untouched, which is exactly why the problem is invisible: you inspect the original, find your metadata intact, and conclude everything is fine. Meanwhile the page is serving a resized derivative that has none.

On optimisation. Compression tools and plugins strip metadata by default because it is free file size. Many list it as a feature. It is a feature, right up until it removes something you put there deliberately.

At the CDN or image service. Transformation layers that resize and reformat on the fly are generating new derivatives too, with the same consequence.

Pipeline stage	Typical default	What usually survives
Direct file upload, no processing	Preserved	Everything
CMS thumbnail and size generation	Stripped from derivatives	Little to nothing
Compression plugin or build step	Stripped	Nothing, unless configured
Format conversion to WebP or AVIF	Usually stripped	Varies by encoder
CDN on-the-fly transformation	Usually stripped	Sometimes copyright only
Social and marketplace re-upload	Always stripped	Nothing

That last row is worth noting separately. Anything re-uploaded to a third-party platform loses metadata unconditionally, and no configuration on your side changes that.

The ten-minute test

Do this once, properly, and you will know where you stand rather than guessing.

1. Take a source file and embed something unmistakable. A description field reading METADATA-TEST-2026 is ideal, because it is impossible to confuse with anything real.
2. Upload it through your normal process. Not a special direct upload. The route your team actually uses.
3. Publish it on a page. A draft is fine.
4. View the rendered page and copy the image URL from the markup. This step is the whole test. Do not take the URL from the media library. The served derivative is frequently a different file at a different path, and that file is what matters.
5. Download it and inspect the metadata. Command-line tools, a desktop viewer or a browser extension all work.

If your test string is there, your pipeline preserves metadata and you can stop. If it is gone, walk back one stage at a time until you find the step that removed it. In practice it is derivative generation or an optimisation plugin around three-quarters of the time.

Worth doing the same check on a few real images while you are there. A quick pass over what your library actually contains tends to surface surprises, and auditing images across an entire site is a reasonable companion exercise if you have never done one.

What to do about it

The answer depends on what you were trying to achieve, and it is worth being honest about that before spending time on a fix.

If you wanted ranking benefit from EXIF fields, adjust the expectation. There is no good evidence that embedded camera or description fields function as a ranking signal, and the claims circulating to the contrary are considerably stronger than the evidence supporting them. What embedded metadata genuinely contributes is a smaller and more specific set of things than the marketing around it suggests. Filenames, alt text and the surrounding page content remain the signals that do the work, and none of those travel inside the file.

If you wanted licensing and attribution to survive, this matters and is worth fixing. Licensing information can surface in image search results, and it is the clearest practical case for preserving metadata. The structured-data route is more reliable than the embedded route in any case, since ImageObject markup and licensable image fields live in the page rather than inside a file that four different systems feel entitled to rewrite.

If you wanted GPS coordinates to persist for local relevance, test specifically for that field, because coordinates are the single most commonly stripped item — deliberately, for privacy reasons that are entirely legitimate. What geo-tagged images can and cannot do for local visibility is worth reading alongside the test result, since the honest position is that the effect is unproven even when the data does survive.

If this is asset management, preserve it at the source and stop worrying about the served copy. Your master library keeps the metadata; the derivative on the page does not need it.

How the common platforms behave

Specific behaviour changes between versions and configurations, so treat the following as where to look rather than as a settled answer. The test above is what tells you the truth for your own installation.

WordPress preserves metadata on the original upload and generally loses most of it in the generated thumbnail sizes, which are usually what pages display. Optimisation plugins then strip more, often as an advertised feature. Because the original in the media library stays intact, this is the platform where the problem is most consistently invisible. The wider trade-offs of image plugins on WordPress include this one directly, since the same plugin doing the compressing is usually the one doing the stripping.

Hosted site builders such as Squarespace, Wix and Webflow process uploads through their own pipelines and serve transformed derivatives, with limited or no user control over metadata handling. Assume it does not survive unless you have verified otherwise, and plan to carry licensing and attribution information in the page rather than the file. What each of those platforms gives you control over varies considerably, and metadata is rarely among the exposed settings.

Static site generators and custom builds depend entirely on the image plugin in the build pipeline. Most modern ones strip by default for size, and most expose a flag to change it. This is the easiest category to fix because the behaviour is in a config file you control.

Headless CMS with an image API almost always transforms on delivery, which means new derivatives and the same consequence. Check the transformation service rather than the content API.

The pattern across all of them is that the more a platform does for you automatically, the less likely your metadata is to survive, and the less likely you are to be told.

Configuring for preservation

Where you decide it matters, the levers are usually these.

Optimisation tools generally have a preserve-metadata option, sometimes with per-field control such as keeping copyright while discarding everything else. That granularity is ideal when available, because it retains what has value at almost no size cost.

CDN transformation layers usually have a metadata setting too, and it is frequently the one people forget because the CDN was configured by someone else two years ago.

Format conversion is the fiddliest case, since whether metadata survives a WebP or AVIF encode depends on the encoder and its flags. If you convert formats in your pipeline, test that step in isolation. This interacts directly with compression, and how quality settings and format choice affect your files is the same set of decisions viewed from the size side rather than the metadata side.

There is a legitimate opposite case as well. If your images come from phones and include coordinates of places that are not commercial premises, stripping is the correct default and you should leave it on. Deciding when to strip GPS data before publishing is a genuine judgement call rather than an automatic one, and the distinction is whose location the file reveals.

The part that is easy to miss

Chasing metadata through a pipeline is satisfying work that can absorb a surprising amount of time, and it is worth periodically asking what it is buying.

An image with perfect embedded metadata, a filename of DSC_0043 and an empty alt attribute is worse off than an image with no metadata, a descriptive filename and a sentence of useful alt text. The signals that travel with the page are the ones that reliably do work. The ones inside the file are supplementary, sometimes valuable, and frequently deleted by systems that were never asked.

If metadata is being stripped and you also cannot find your images in search results at all, the metadata is almost certainly not the cause. Diagnosing images that do not appear in Google Images starts with crawlability, indexing and page context, which is where the actual answer nearly always is.

Where SEOpix sits in this: metadata is written at the moment each image is generated, so the master file arrives complete rather than needing a separate embedding pass. What happens to it downstream still depends on your pipeline, which is why the ten-minute test above is worth running whatever tool produced the image. See what gets written, or test it on ten free images and run them through your own upload path.