Your messaging app or social platform almost certainly stripped it. When you upload or send a photo through apps like WhatsApp, iMessage, Instagram, or Facebook Messenger, the platform rebuilds the image file from scratch to shrink it and remove identifying details. That rebuild wipes out the embedded information, called EXIF data, that recorded when the photo was taken, what device captured it, and sometimes where.
What EXIF data actually is
When a camera or phone takes a photo, it writes a small block of information into the file alongside the image itself. This is EXIF data (short for Exchangeable Image File Format). It can include the date and time the shutter opened, the camera model, exposure settings, and GPS coordinates if location services were on.
That data lives inside the original file the camera produced. It's not a separate attachment. It's baked into the same file you'd see if you plugged your phone into a computer and looked at the photo directly.
Why platforms strip it out
Two things happen when you send a photo through almost any messaging app or social platform, and both destroy the metadata.
First, the platform re-encodes the image. A photo straight off a phone camera can be several megabytes. Sending that at full size to every recipient, every time, would eat bandwidth and storage fast. So most platforms compress the image: they decode it, resize it, re-save it at a lower quality, and send that smaller file instead. Re-encoding doesn't selectively keep some data and drop the rest. It builds a new file, and EXIF data isn't part of what gets carried over unless the software is specifically written to preserve it. Most isn't.
Second, platforms strip metadata on purpose for privacy. GPS coordinates embedded in a photo tell anyone who downloads it exactly where it was taken, down to a few meters. A photo posted publicly with location data attached can expose someone's home address or daily routine. Stripping EXIF before an image goes out the door closes that privacy gap. It's a deliberate design choice, not a bug.
Put those two together and you get what you're seeing: a photo that goes in one end with a timestamp and device signature, and comes out the other end as a generic, anonymous image.
The file you're looking at isn't the file that was taken
Here's the part that trips people up in a dispute. The photo you received on WhatsApp, saved from Instagram, or screenshotted off a text thread is not the same file the camera produced. It looks the same. The pixels are probably close enough that you can't tell the difference by eye. But at the byte level, it's a different file, created by a different piece of software, at a different moment, with different information inside it.
That matters because file identity and visual appearance aren't the same thing. If someone later asks "when was this photo actually taken," the honest answer for a file that's passed through a messaging app is: you can't get that answer from the file you're holding. The evidence that would have answered it got discarded during transfer.
Screenshotting a photo to share it makes this worse, not better. A screenshot captures whatever your screen displayed at that instant. It has its own EXIF data, from your phone's screenshot function, with its own timestamp. The original photo's metadata was already gone by the time it reached your screen, and the screenshot buries that fact one layer deeper.
What to do if you need the original to matter
If you think a photo might need to hold up later, in an insurance claim, a dispute, or anything where "when was this taken" could get challenged, the fix has to happen before you send it anywhere.
Transfer the original file, not an inline share. Most messaging apps have a way to send a photo "as a file" or "as a document" rather than as an inline image. That path usually skips the re-encoding step, because the app isn't trying to display a compressed preview, it's just moving the file. AirDrop, a cable transfer, or a cloud upload set to preserve originals will do the same thing. Check the setting before you rely on it; some apps compress "as a file" sends too.
Keep the device original. Don't delete the photo off the phone or camera once you've shared a copy. The copy that traveled through a platform has already lost what made it provable. The version still sitting on the device that took it hasn't.
Don't use a screenshot as your sharing method. If you need to get a photo to someone, send the file itself. A screenshot is a photo of a photo, with its own disconnected timeline.
Where this connects to anchoring a hash
Re-encoding doesn't just remove metadata, it changes the file's contents at the byte level, even when nothing looks different to your eye. That matters for anything that verifies a file by its hash, including ProofLedger. A hash is a fingerprint of the exact bytes in a file. Change one bit, compress the image, convert the format, and the fingerprint comes out completely different.
That means anchoring a hash only means something if you anchor the file you actually intend to rely on later, before it gets forwarded, re-uploaded, or converted. Anchor the original straight off the camera or phone, and you have an independent, timestamped record of that exact file's existence at that moment, on a public ledger that didn't come from you and can't be edited after the fact. Anchor a copy that already went through a messaging app, and you've anchored a file with no EXIF data anyway, which solves less of the problem.
It's also worth being clear about what an anchor does and doesn't do. Anchoring a hash proves that specific file existed at a specific time. It doesn't prove who took the photo, and it doesn't prove what's depicted in it is what it claims to be. It answers one question: did this exact file exist by this date. For a photo whose timing might get challenged later, that's often the question that matters most, but it's the only one it answers.