All guides

When does photo metadata survive sharing?

By · Updated

In short: if a recipient gets an identical copy of the original file, its embedded metadata travels with it. Email, cloud links and messaging can use different export paths. Re-encoding or a hidden map does not prove that personal metadata was removed: check the downloaded file.

The question to ask: is it the same file?

Metadata lives inside the image file. It disappears only when something rewrites that file: an app that removes it on purpose, or a service that re-compresses the image and does not copy the metadata into the new version. So the useful question about any way of sharing is whether the person at the other end receives your original file or a new one.

Channels that pass the original along

These routes can deliver the original file. Their names alone do not prove that the bytes or metadata are preserved:

  • Email attachments. Resizing and attachment options vary by client. Compare the saved attachment received at the other end; “full size” is a label, not a byte-level result.
  • Cloud storage and share links. A service may offer both an original download and a rendered preview. Inspect the download route the recipient actually uses.
  • File transfer services and messaging “as a file”. A document/file option may preserve the original. Check the received file for the specific app version and option; do not assume that “HD” or “original quality” guarantees identical bytes.
  • Direct transfers. A raw file copy preserves embedded metadata if the bytes are unchanged. Photo-library exports can transform files before transfer. On Apple devices, review Options → Location in the Photos share sheet and inspect the received copy.
  • Websites that keep originals. Forums, blogs, marketplaces and smaller sites often store the uploaded file and serve it, or let visitors download it, unchanged.

Channels that usually re-encode

Social networks and messaging apps may compress or resize images for display. A displayed copy may be a new file, but that alone does not establish which metadata survives. Three caveats make that less reassuring than it sounds:

  • The platform received the original. Removing metadata from the public copy happens after upload, on the platform’s servers. What the service does with the location it read is governed by its own privacy policy.
  • Behavior changes. Options such as “HD” or “original quality” uploads, new app versions and different upload paths (app, website, desktop client) can change what is kept. A rule that held last year is not a guarantee.
  • Re-encoding is not removal. Some services keep selected fields, such as the date or the color profile, in the new file.

A simple routine

Reduce exposure before upload, then check the copy that actually reaches the recipient:

  1. Decide what the recipient needs. A friend may like knowing where a photo was taken; a buyer on a marketplace does not need to know where you live.
  2. Remove metadata from the copies you share, not from your originals, so your own library keeps its dates and places. The platform guide covers the built-in options; delexif removes targeted personal metadata from a copy and reports the scope of its check.
  3. Check the result when it matters, by opening the shared copy in a metadata viewer.

When it matters most

  • Selling things online. Photos taken at home may include home coordinates when location recording was enabled.
  • Photos of children at home, at school or at their regular activities.
  • Sharing with people you don’t know, or in public places where the file can be downloaded.
  • Sensitive work: sources, activism, journalism or anything where linking several photos to one device or person is a risk. What EXIF, IPTC and XMP metadata reveal lists the fields that do the linking.

Metadata is not the whole story

A clean file can still reveal a place through what it shows: house numbers, street signs, landmarks, the view from a window, reflections in glasses or screens. Removing metadata closes the invisible channel; the visible one needs a look at the picture itself.

A repeatable sharing check

As of 21 October 2026, this guide does not publish an executed matrix of email clients, messaging apps or cloud services. The channel descriptions above explain what to check; they are not measured promises about particular versions.

Use our synthetic JPEG input to test a route without exposing a real photo. Its reference values are GPS 40.5, -3.7, device TestCam, author Example Author and a file size of 1,359 bytes.

  1. Record the sending and receiving devices, OS/app versions, date and exact option: photo, document/file, link preview or original download.
  2. Send only the synthetic input, then save the received file rather than a screenshot or preview.
  3. Compare its SHA-256 hash with the input hash in the reference record. An identical hash means the file, including its metadata, is unchanged. A different hash requires a metadata inspection; it does not prove removal.
  4. Open the received file in a metadata viewer and record GPS, device and authorship separately. Repeat after changing an option or updating the app.

For a local baseline, delexif’s JPEG Lossless implementation produced this 633-byte output on 21 October 2026. It removed the sample’s EXIF, XMP, comment and 23 appended bytes while preserving compressed scan data. This reproduced cleaning result does not establish what any external service will do to either file.

Sources and scope

Primary documentation checked on 21 October 2026. The downloadable example is synthetic; the recorded test does not establish the behavior of every photo, device or sharing service.

Clean the copy before you send it: drop your photos into delexif and download them without location, device or authorship data. The images are processed in your browser and never uploaded by the tool.