Metadata & Privacy on Social Media

When a large platform processes an uploaded photo, it usually re-encodes it to its own size and quality, and that step typically discards the EXIF block from the public image. So the version other users can download often has no GPS or camera data. However, the platform itself frequently reads the original metadata before removing it — using your location and device data internally for advertising and analytics, even though it is stripped from what the public sees.

Removal is also not the same as absence. The file you download back from a feed is a new file the service generated, and it can carry metadata the service added rather than metadata you wrote — a Software tag naming its own encoder, or an IPTC block of its own. Facebook, for one, has long been observed attaching IPTC fields to the images it processes. A photo that has been through a platform is therefore not a clean photo in the sense you want; it is a differently tagged one.

So there are two different questions: "can strangers read my EXIF?" and "did the platform read it?" Stripping on display answers the first, not the second. If you would rather the service never see your coordinates at all, the only reliable answer is to remove them before uploading.

Stripping is not universal. Direct-message attachments, "send as file" or "send in original quality" options, and cloud-drive links often preserve the full original, metadata and all. Smaller sites, forums and marketplaces may do no processing whatsoever, publishing your file exactly as uploaded. And profile-photo or document upload flows sometimes behave differently from the main feed.

A rough map helps, as long as you treat it as a starting point rather than a guarantee. The large feed-based networks — Facebook, Instagram, X, Reddit — re-encode what they display, so the public image generally arrives without EXIF. Services built for photographers go the other way: Flickr keeps EXIF and shows it on the photo page by design. Storage services such as Google Drive, Dropbox and Google Photos exist to hand back what you gave them, so a download or a shared link usually returns the original file with its GPS directory intact. Messaging apps split the difference: the compressed photo path strips, the send-as-file path does not.

Because each platform, app version and upload path can behave differently — and can change silently with an update — you cannot memorise a safe list. The behaviour you tested last year may not hold today. That uncertainty is precisely why cleaning on your side is the durable strategy.

You do not have to take any of this on faith. Take a throwaway photo with geotagging switched on, note the coordinates, upload it through the exact path you care about, then fetch the image back the way a stranger would — the public URL, the download button, the shared link — and inspect what arrives. Dropping the downloaded file into MetaCleanse answers the question in a few seconds; exiftool answers it in one command.

Test each path separately, because they are separate pieces of code: the main feed, a direct message, a send-in-original-quality option, a profile picture, an attachment in a group chat. Repeat the test occasionally, since an app update can change the behaviour with no announcement at all. And keep in mind what the test cannot tell you — whether the service read your metadata before discarding it.

The dependable rule is simple: clean before you upload, every time, regardless of the platform's reputation. When the file that leaves your device already contains nothing but pixels, it no longer matters whether the service strips metadata, keeps it, or reads it on the way through — there is nothing to read.

MetaCleanse makes that pre-upload step quick: drag in the photos you are about to post, review what they were carrying, clean and download, then upload the clean copies. It runs entirely in your browser, so the images you are trying to protect are never handed to yet another server on the way to being cleaned.