Reference
How to check whether a platform strips image metadata
Search this question and you will find a dozen tables telling you what each platform does. Most are undated, none state a method, and several contradict each other. This page gives you the method instead, because a platform's pipeline can change next week and your test cannot.
Why the published tables are unreliable
Metadata handling is a side effect of an image-processing pipeline, not a documented feature with a changelog. Platforms adjust compression, resizing and delivery formats continuously, and none of them announce it. An article written eighteen months ago can be confidently, precisely wrong today and give no sign of it.
Worse, the answer is not one value per platform. Within a single app, these are four different paths with four different behaviours:
- a feed post
- a story
- a direct message with standard compression
- a file or document attachment
Any table with one row per platform has already lost the distinction that decides the outcome.
The one rule that stays true
Whatever the table says, the mechanism is stable: metadata disappears when a file is re-encoded and survives when it is copied.
Re-encoding decodes the picture to pixels and compresses a new file from them. The original container — JPEG APP segments, PNG text chunks, WebP metadata chunks — plays no part, so EXIF, XMP and IPTC are gone and whatever the encoder writes takes their place.
Copying moves the bytes. Everything in the container arrives intact.
This is why "send as document" and "send as file" modes preserve metadata in apps whose normal photo picker does not, and why a feed post and a chat attachment can differ inside one product. When you want to predict a path you have not tested, ask whether it re-encodes.
The round-trip test
Five minutes, and it produces an answer about today rather than about whenever someone wrote a blog post.
1. Prepare a fixture. Use a photo that definitely carries what you are testing for — GPS coordinates, camera make and model, an XMP packet. Confirm it does in our metadata viewer or with exiftool -a -G1 -s original.jpg. Keep this file; reusing the same fixture makes results comparable over time.
2. Upload by the exact route you care about. Not an equivalent route. If the question is about direct messages, test direct messages.
3. Download the delivered copy. Save it the way a recipient would, from the interface a recipient would use. This matters: some platforms serve a different derivative to the web than to the app.
4. Inspect the downloaded file. Compare it against the fixture, field by field, rather than just looking for GPS.
5. Record the date. A result without a date is not a result.
Reading the outcome honestly
A positive finding is strong. If EXIF or GPS is still present in the delivered file, that path demonstrably does not strip it.
A negative finding is weaker than it looks. "No metadata found" is consistent with several explanations: the platform stripped it, your fixture lost it earlier in the chain, or your inspection tool cannot read the structure it is stored in. Check the fixture again and inspect with a second tool before concluding anything.
Also look at what was added. Re-encoding commonly introduces a JFIF header and an ICC profile that the original never had. A file whose only metadata is a colour profile is usually a re-encoded file.
A dated sample of what CDNs serve
To illustrate what this looks like in practice, we inspected images served publicly by several hosts on 18 September 2026, using the same parser the tools on this site use.
| Host | Delivered structures found |
|---|---|
| Wikimedia Commons | Full EXIF block, XMP packet, Photoshop IRB (IPTC), embedded thumbnail |
| X (pbs.twimg.com) | JFIF header and ICC profile only |
| Unsplash (images.unsplash.com) | JFIF header and ICC profile only |
| WordPress.org static (PNG) | gAMA, sRGB, PLTE, tRNS — rendering chunks only, no text chunks |
What this does and does not show. It was a first-hand spot check on that date, but the specific image URLs were not recorded so it cannot be reproduced exactly. The Wikimedia row is a genuine positive: that host demonstrably delivers complete metadata, which also confirms the method detects it when it is there. The other rows are negative findings, and negative findings are weak — we did not upload those files and cannot know what the originals contained. Read this as a worked example of the method, not as a verdict on those platforms.
That limitation is exactly why the method matters more than any table, including this one. A proper verdict needs a round trip with a fixture you control.
What "stripped" never means
Even a path that strips everything leaves all of this untouched:
- The platform still received your original. Stripping happens after upload. It protects you from other viewers, not from the service. See does Instagram remove EXIF data for why the order of events is the whole point.
- Visible content is unaffected. A street sign or a recognisable view is in the picture, not the container.
- Pixel-level watermarks are unaffected. They are encoded into the image data.
- Your caption, tags and attached location are the post, not fields in the file.
The only step that keeps information away from every recipient, the platform included, is removing it before the file leaves your device.
Re-testing
We will re-run this sample and update the date on this page each quarter, with the next check due in December 2026. If the date above is stale by the time you read it, treat the table as expired and run the round-trip test yourself — which was the point.
Inspect a file before and after