Does Social Media Strip Image Metadata? I Ran One Signed Photo Through 5 Platforms

I signed one JPEG so I could recognize it anywhere, then sent it through five platforms: Gmail, X, WhatsApp, Facebook, and YouTube. Every copy came back for inspection, and I compared all of them against the original, field by field. So does social media strip image metadata? Sort of, and the differences between platforms turned out to matter far more than the yes or no. One platform handed the file back untouched. Another deleted 29 fields and then wrote one of its own into the file.

The Test: One Signed Photo, Five Round Trips

Answer first: after an upload, a photo's metadata mostly describes the platform that handled it, not the camera that took it. Here is how I set the test up. I started with a single JPEG of 290,252 bytes and signed it, in the sense that I recorded its exact hash and noted the fingerprints already baked into the file, so any copy coming back could be matched against it. Thirty-five metadata fields in total, spread across the JFIF header and an embedded color profile.

That color profile is unusually chatty, which made it perfect for this. It identifies itself as sRGB IEC61966-2.1, credits Hewlett-Packard, carries a timestamp from February 1998, and still names cathode ray tube display as its target technology. Twenty-nine separate fields, all of them describing a monitor standard older than most of the people reading this. If a platform left that profile alone, I would know. If it touched it, I would know that too.

One thing I want to be upfront about: the file arrived with no EXIF block at all. No camera model, no shutter speed, no coordinates, because stock photo downloads have that removed long before you get them. So this test could not watch GPS data die. What it could measure is quieter and, I think, more useful. When there is no camera data left to delete, what do platforms do to everything else?

Gmail Handed Back the Exact Same File, Byte for Byte

Gmail was my control, and it passed cleanly. I attached the JPEG, sent it to myself, downloaded the attachment, and got back 290,252 bytes with an identical MD5 hash. Same 35 fields, same values, same bytes in the same order. Nothing in the chain touched it.

Worth remembering the next time you have to send someone a photo that must stay intact. Email treats an attachment as a file to move, not as content to optimize. One caveat on my method: I tested the attachment path specifically, downloading the file itself rather than saving a preview from the browser. Save a preview instead and you may walk away with something the client generated for display, which is a different file entirely.

X Kept Every Field and Still Returned a Different File

This is the result I did not expect. X gave back all 35 metadata fields with identical values: same profile version, same Hewlett-Packard copyright line, same 1998 timestamp, same 72 dpi JFIF resolution. On paper, a perfect match to the original. The bytes disagreed. The file came back 393 bytes larger, at 290,645, with a completely different hash.

Something in that pipeline rewrote the file while carefully carrying the metadata across. Whether that was a full re-encode or a lighter rewrite, the result is the same: those are no longer the original's bytes. For anyone doing image forensics, that gap is the lesson. Matching metadata does not prove two files are the same file, and any compression analysis you run on the X copy is measuring X's encoder rather than the camera or editor that came first.

WhatsApp Replaced My Color Profile With Google's

WhatsApp did not simply delete fields. It substituted its own. The copy came back at 257,498 bytes, roughly 11 percent smaller, carrying 22 fields instead of 35. Thirteen fields were gone outright, and ten of the survivors came back holding different values.

The changed values are where it gets interesting. Profile version jumped from 2.1.0 to 4.3.0. The description shortened from sRGB IEC61966-2.1 to a plain sRGB. The copyright line went from Hewlett-Packard 1998 to Google Inc. 2016, and the rendering intent flipped from Perceptual to Relative Colorimetric. That is the signature of an Android imaging pipeline, stamped into a file that had nothing to do with Android when I sent it.

Facebook Erased 29 Fields and Added One of Its Own

Facebook was the most aggressive and the most revealing. The file came back at 181,576 bytes, 37 percent smaller than what I uploaded. All 29 color profile fields were gone. The JFIF resolution had been rewritten from 72 dpi to a bare 1 with no unit attached. Seven fields left standing out of 35.

Then there is the field that was not there before. Facebook wrote an IPTC Special Instructions entry holding a long hex string that opens with FBMD, tucked inside an Adobe style resource block, which is why the raw header of a Facebook image announces Photoshop 3.0 even though Photoshop never opened it. What that string encodes is not publicly documented and I am not going to pretend I know. What it tells you is still unambiguous: this file went through Facebook.

Every platform took something out of the file. Only one wrote something in.

YouTube Did Not Strip the Metadata, It Threw Away the JPEG

YouTube is not a photo host and the result shows it. I put the image in as a video thumbnail, and what came back was not a JPEG at all. It was a 30,120 byte WebP, about a tenth of the original file size, and the parser could not read a single field from it because there was nothing left to read. No JFIF header, no color profile, no IPTC block.

This is a different category of loss from the others. WhatsApp and Facebook rewrote my file. YouTube discarded the container entirely and re-encoded into a format built for delivery speed. Any platform that serves modern image formats can do the same thing to you, and once it has, the file you are able to download is a distant relative of the one you sent.

The Before and After, All Five Platforms Side by Side

Lined up together, the pattern is hard to miss. Gmail preserved all 35 fields and the exact bytes. X preserved all 35 fields but changed the bytes, adding 393 of them. WhatsApp kept 22 fields and rewrote 10 of the survivors. Facebook kept 7 and invented 1. YouTube kept nothing.

One detail I only caught when the reports sat next to each other: WhatsApp and Facebook made the same JFIF edit. Both replaced the original 72 dpi resolution with a bare 1 and no unit, and both downgraded the JFIF version from 1.02 to 1.01. Different companies, same underlying habit, and a handy pair of fields to check when you want to know whether an image has been through a mobile-first pipeline.

If you want to see this on your own photo instead of taking my word for it, run the original and the downloaded copy through the metadata analyzer here and read the two reports against each other. It takes about a minute, and the differences tend to be more persuasive than any table I could put in front of you.

So Does Social Media Strip Image Metadata? Not Quite

Strip is the wrong verb for most of what I saw. Only YouTube did anything resembling a clean wipe, and even that was a side effect of changing formats. The rest edited: some fields removed, some quietly rewritten, one added. That distinction changes what a missing field actually tells you.

A photo with no camera data is not a suspicious photo. Usually it is a photo that has been posted somewhere. When someone sends you a download from a feed and you find nothing in the metadata, you have learned where the file has been, not whether anyone altered the picture. The useful question shifts from what is missing to what has been left behind: which profile, which JFIF version, which added tag.

Missing metadata is not evidence of tampering. Most of the time it is evidence of an upload.

What to Do Before You Post a Photo You Might Need to Prove

Keep an original that never touches a platform. That is the whole strategy and everything else is detail. The copy you post is disposable by design, so the version that matters is the one sitting in your own storage with its fields intact.

If provenance is part of your job, embedded content credentials are a better tool than raw EXIF, because they are designed to travel with a file and to be checked rather than silently overwritten. They are not immune to the pipelines above, and support still varies by platform, so treat them as one signal among several rather than a guarantee.

How to Read a Stranger's Photo and Tell Where It Has Been

You can often place a file's route without any camera data at all. Start with format and size, because a small WebP where you expected a photo usually means a delivery pipeline handled it. Then read the color profile. A recent vendor name paired with profile version 4.3.0 points toward a mobile messaging path, while a full 1998 sRGB profile with the Hewlett-Packard lines still attached suggests the file has been handled gently or not at all.

None of this tells you whether the picture is real. It tells you the file's history, which is a narrower question and a far more answerable one. Pair it with pixel-level analysis when the stakes are high, and treat any single indicator as a lead rather than a verdict.

FAQ

Wrapping Up: The One Habit Worth Copying

Run this test on your own photo before you need the answer. Pick one image, send it through the two platforms you use most, download both copies, and compare all three reports side by side. It takes about ten minutes and it will tell you more about your own posting habits than any general article can, this one included.

Then keep that original somewhere safe. It is the step everyone skips and the one that matters when a photo gets questioned six months later. When you are ready to see what your platforms are doing to your files, upload the original and the downloaded copy here and read the two metadata reports against each other.