Why Two Copies of the Same Photo Can Have Different Metadata

People say “the same photo” when they mean the same scene. Files are not scenes. A byte-for-byte Finder copy of a JPEG still has the APP1 segment: GPS, DateTimeOriginal, Make, Model, MakerNotes. A WhatsApp “photo” send is often a new, smaller JPEG the app encoded, with a stripped or rewritten header. An iMessage original-quality send can be closer to the Finder copy. A screenshot of the image on-screen is a PNG (or a screenshot JPEG) that never contained the camera’s GPS IFD at all. Four channels, four headers, one visual. If you needed a rule: do not assume a messenger already wiped the file you still hold, and do not assume a wiped-looking chat preview means every copy is clean.

Platform behavior after a post is how to tell if a photo still has metadata after sharing. Confirming a strip worked on one file is how to verify metadata was removed. This page is the fork before that: why two objects that look like one picture disagree in a metadata panel.

Direct copies: the header comes along

Copy on disk, USB, many email attachments, and typical AirDrop/original Bluetooth transfers duplicate the container. EXIF is inside the container. The copy is not a “new photo” to the camera; it is the same file family. If GPS was in the source, it is in the destination unless something in the path re-encoded. Desktop “compress for email” can go either way depending on the client. When in doubt, open the attachment you actually sent, not the thumbnail in the composer.

Cloud “original quality” libraries (iCloud Photos at full resolution, Google Photos Original quality) are also in this family for the object stored in the library. A download of that object is not a social-tile re-encode. Treat library downloads as tagged until the panel is empty.

Messengers: photo mode vs document mode

WhatsApp, Telegram, Signal, Messenger, and iMessage each have at least two mental modes even when the UI uses one paperclip. Compressed in-line images are often resized and re-encoded; testers keep finding empty GPS on those public-style sends. “Send as file / document / keep original” skips the compressor on purpose so the recipient gets a usable original — which is how GPS survives a chat that people thought was “just WhatsApp.” Discord’s inline JPEG versus attachment path has the same split. iMessage original quality is a file transfer. None of this is a warranty; apps change. It is a reason to inspect that outbound copy.

The dangerous inference is “I already sent it through WhatsApp, so I can post the camera-roll file to a blog.” The blog file was never in WhatsApp. WhatsApp’s compressor did not reach into Photos and rewrite the HEIC. Two copies.

Screenshots: none of the original EXIF, and a new file

A screenshot samples the screen. It does not clone APP1 from the JPEG decoder’s input. Camera GPS does not “jump” into the PNG. Software and capture-time tags on the screenshot are about the screenshot, not about the shutter that took the original. This is why people screenshot a photo as a folk privacy trick: the new file is usually thin. It is a bad trick for two reasons. Quality drops. The original remains on the device, in backups, and in any album you still share. You also still have to cover pixels if the scene itself identifies you — a screenshot of a geotagged mountain does not remove the mountain, and it does not strip the HEIC sitting in Recents.

How to stop guessing which copy you have

1. Name the objects. camera-original.heic, whatsapp-received.jpg, airdrop-from-mac.jpg, screenshot.png. If they share a thumbnail, they still do not share a header.
2. Open each JPEG or PNG in the MetadataWipe panel. Note GPS, DateTimeOriginal, Make. HEIC: convert or use a HEIC-aware viewer first; this tool opens JPEG and PNG.
3. Strip the copy that will leave the device if that copy still has tags you do not want to send. Re-open the download to confirm.
4. Do not send the original because a chat preview looked clean. The preview is another object.

After-share inspection of what a platform did to a public file is how to tell if a photo still has metadata after sharing. The strip-confirmation walkthrough is how to verify metadata was removed. Use this page when two files of the “same” picture disagree and you were about to trust the wrong one.

False all-clears from the wrong copy

WhatsApp looked clean, camera roll still has GPS. Expected. Strip the roll file before the next non-WhatsApp send.

AirDrop “felt like a message” so it should have stripped. AirDrop is not WhatsApp photo mode. Check the panel.

A screenshot of the photo was clean, so you shared the album. The album is the original.

Two JPEGs with the same pixel dimensions, so they must have the same tags. Dimensions are not APP1. Open both.

Assuming last year’s messenger behavior still holds. Test the path you actually use, then strip for real work anyway.

Related guides

See also:

• How to tell if a photo still has metadata after sharing
• How to verify metadata was removed