The file you upload is almost never the file that comes back down.
Between pressing send and the image appearing in someone’s feed, it has been decoded, re-encoded, resized, stripped of some things and quietly assigned others. Most people assume the platform simply stores what they gave it. It does not, and the gap matters — both for how your photo looks and for what it still says about you.
The three things that happen
It gets re-encoded. Almost every platform re-compresses uploaded images to control storage and bandwidth. Your carefully exported JPEG at quality 90 becomes the platform’s JPEG at whatever quality their pipeline uses. This is lossy on top of lossy — the detail discarded on the second pass is gone for good, and it is why photographs that looked crisp on your machine look faintly soft once uploaded.
It gets resized. Platforms cap dimensions. Upload a 6000-pixel-wide photograph and you will get back something considerably smaller, downsampled by an algorithm you did not choose.
Its metadata gets rewritten. Not simply removed — rewritten. Some fields are dropped, some are preserved, and some are replaced with the platform’s own. The specifics vary by service, by upload path, and over time.
Why you cannot get a reliable answer to “does X strip EXIF?”
This is the question everyone asks, and the honest answer is that no lasting answer exists.
The behaviour differs along at least four axes:
- By platform. Each pipeline makes its own choices.
- By upload path within the same platform. A photo sent as an image attachment and the same photo sent as a file frequently take different routes. The file path often preserves the original untouched — which is precisely when people assume they are safest.
- By what the platform shows versus what it keeps. Several services strip metadata from the version served to viewers while retaining the original, complete with location, on their own servers.
- Over time. Pipelines are rewritten. An article confirming a platform’s behaviour in 2023 is evidence about 2023.
Any table claiming to settle this is a snapshot of one test on one day through one upload path. Treat published tables — including any you find on sites like this one — as a starting hypothesis rather than a finding.
How to check for yourself, in three steps
The good news is that verifying it takes two minutes and the answer is authoritative for your platform, your device and today.
- Read the original. Open your photo in our EXIF viewer and note what is there — GPS coordinates, camera make and model, serial numbers, timestamps.
- Upload it, then get it back. Post it, send it, or share it exactly as you normally would. Then download the resulting image from the platform as a viewer would see it — not from your own camera roll, which still holds the original.
- Read the downloaded copy. Same tool. Compare. What is missing was stripped; what remains was kept.
Also compare the file sizes and dimensions while you are there. A file that came back noticeably smaller was re-encoded, which tells you the platform is not preserving your image either.
Repeat for each upload path you actually use. The attachment-versus-file distinction is the one that catches people out.
What the operating systems give you
Both major mobile platforms now offer a control at the point of sharing, and it is worth knowing what it does and does not cover.
Apple documents a location metadata control in Photos that lets you share an image without its coordinates. Android offers equivalent behaviour in recent versions.
Two caveats. First, these controls address location — they are not general metadata strippers, and camera model, serial numbers and software fields typically survive. Second, they apply to the share sheet. A photo moved by some other route — a file manager, a cloud sync, an app with its own picker — may not pass through that control at all.
They are a genuine improvement and worth using. They are not a substitute for knowing what is in the file.
The practical conclusion
Strip it yourself before it leaves your device, and the question stops mattering.
This is not a counsel of paranoia; it is a way of removing a variable you cannot otherwise control. If the photo carries nothing sensitive when you upload it, you do not need to know what the platform’s pipeline does this month, whether the file path differs from the image path, or whether the original is retained on a server somewhere. You have made the answer irrelevant.
Doing it costs a few seconds and, done properly, costs no image quality at all — the metadata is removed by rewriting the file’s structure, leaving the compressed image data untouched.
What to strip, and when
Anything going somewhere public — strip location and serial numbers at minimum. A serial number is a persistent identifier linking every photograph a camera has ever taken, and almost nothing surfaces it.
Photographs of documents — strip everything. A scan of a form has no business carrying the coordinates of your desk.
Listings and marketplace photos — these are shared with strangers who have a reason to look closely, and they are among the most common ways home locations leak.
Photos you are sending to one person — usually fine as they are, with the reminder that anything forwarded is out of your hands.
Photos you are archiving for yourself — keep the metadata. It is genuinely useful, and this whole problem only begins at the point a file leaves its original context.
Screenshots and documents are the sharper case
Photographs get the attention, but the images people upload most carelessly are screenshots and photographs of documents, and those carry a different kind of risk.
A screenshot is usually a PNG, and PNGs carry their own metadata in named chunks rather than in an EXIF block. Many screenshot tools write the software name, and some write the window title or source application. A screenshot posted to a public forum can disclose which internal tool it came from before anyone reads the pixels.
A photograph of a document is worse, because it is a photograph — full camera metadata, full GPS, taken at the desk where the document lives. People strip metadata from holiday pictures and upload a photographed invoice without a second thought.
Both cases share a property: the person uploading is focused on the content and forgets the file is also a record of its own creation.
Keep the metadata, share without it
None of this argues for turning everything off.
Location tagging exists because organising a decade of photographs by place is genuinely useful. Timestamps let you find the day. Camera and lens fields are how photographers learn what they did. Deleting all of it from your own archive to solve a sharing problem is trading something valuable for something you could have had for free.
The distinction that matters is not store or do not store. It is archive versus publish. Keep everything in your own library, where it works for you, and strip on the way out, at the moment a file crosses from private to public. That way the metadata does its job for as long as it is useful and disappears at exactly the point it becomes a liability.
Doing that reliably means building the habit into the moment of sharing rather than trusting yourself to remember, which is why the check is worth running until it becomes automatic.
See exactly what your photos carry, before and after upload, with the EXIF viewer and remover. Nothing is uploaded and nothing is re-encoded.