Documentation review · Photo privacy

What Happens to Photo Metadata When You Share It?

Some sharing workflows expose location metadata, while others offer controls that hide it. The safest answer is not a universal list of platforms that “strip EXIF.” It is to understand the documented controls, inspect the file yourself, and remove sensitive metadata before the image leaves your device.

Inspect photo metadata Remove EXIF locally

What this article can prove

This page combines current first-party documentation with a small independent test performed on August 10, 2026. The test covers only two platforms and three named web workflows. Every other app, message mode, quality setting, and export path remains unknown unless explicitly documented below.

The short answer

Do not assume a social network or messaging app will protect you by removing EXIF. Sharing is a pipeline: your camera creates the file, a photo library may add or display location information, the share sheet may convert the file, and the destination app may process it again. A change in any step can change the output.

Apple explicitly documents controls for excluding location and, in limited workflows, sending all photo data. Google Photos documents separate rules for camera-provided, manually added, and estimated locations. Neither set of documentation proves how every external destination handles every EXIF field.

What the official documentation says

Workflow	Documented behavior	What remains unknown
Apple Photos share sheet	Apple says shared photos can include date, time, location, device, and captions. Users can turn off Location before sharing. “All Photos Data” is available for AirDrop and iCloud links when the original file, edits, and metadata should be included.	The guide does not define the final metadata output for every third-party destination shown in the share sheet.
Google Photos sharing	Google says camera-provided or user-added locations may be shared through Google Photos when location sharing is enabled. Estimated locations are treated differently and are not shared in the same way.	Hiding a displayed location is not documented as removing every embedded EXIF field from a downloaded or externally shared file.
Other social and messaging apps	No broad first-party guarantee was found in the sources reviewed here that covers every platform, upload mode, device, and metadata field.	Whether a specific app preserves, removes, or rewrites a field requires a controlled test of that exact workflow.

Location in a library is not always the same as EXIF GPS

A photo service can know or display a location from several places. The camera may have embedded GPS coordinates in the image. A user may add a location later. A service may estimate one from landmarks or related photos. Those values can have different sharing and download rules.

That distinction matters when checking a result. A location hidden in an album interface is not automatically proof that the original file no longer contains GPS tags. Conversely, a service can display an estimated location even when the file never contained GPS EXIF.

A conservative workflow before sharing

Inspect the original with a local metadata viewer. Look for GPS, capture time, device model, serial-number fields, comments, and embedded thumbnails.
Make a copy and remove sensitive EXIF before sharing. Keep the original separately if its metadata is useful to you.
Use the location-sharing control provided by Apple Photos, Google Photos, or the destination workflow as an additional safeguard.
When the destination matters, download or save the received file and inspect it again. Test the exact app, device, and sending mode you plan to use.
Review visible content too. Faces, house numbers, landmarks, signs, reflections, and repeated posting across accounts can reveal identity or location without metadata.

Limited independent test · August 10, 2026

What happened in three controlled web workflows

We uploaded the same synthetic JPEG with a fictional camera, a date in 2000, and harmless 0,0 GPS coordinates. We downloaded each result and compared its format, dimensions, byte size, SHA-256 hash, and EXIF presence with the original.

Tested workflow	Downloaded output	Observed result
Google Photos web upload → original-quality direct download	263,793 bytes; SHA-256 matched the input	Controlled EXIF retained; downloaded JPEG was byte-identical
Telegram Web Saved Messages → default photo send	46,766 bytes; progressive JFIF JPEG at the same 694 × 361 size	Image re-encoded and EXIF removed
Telegram Web Saved Messages → Send as file	263,793 bytes; SHA-256 matched the input	Controlled EXIF retained; downloaded JPEG was byte-identical

The two Telegram results show why the sending mode matters: default photo mode removed EXIF by re-encoding the image, while Send as file preserved the original bytes. Google Photos' original-quality direct download also preserved the original bytes. None of these observations is a promise about mobile apps, share links, edits, other quality settings, or future platform behavior.

Download synthetic input, tested outputs, and hashes

Sanitized interface screenshots were reviewed but remain private to avoid publishing account or browser-interface metadata.

How this limited platform test was run

This test asks only whether three named Google Photos and Telegram Web workflows retained or removed the controlled EXIF in one synthetic JPEG.

Sample

One synthetic 694 × 361 JPEG containing a fictional camera, a date in 2000, and GPS 0,0. Input SHA-256: 04c1d69f…02cdfe.

Environment

Google Chrome on macOS, tested August 10, 2026.

Steps

1. Upload the unchanged controlled JPEG through the named web workflow.
2. Download the resulting image without editing it.
3. Compare file type, dimensions, byte size, SHA-256, and EXIF presence with the input.
4. Review a sanitized screenshot of the platform state and retain the downloaded artifact.

Limitations

Only Google Photos web and Telegram Web were tested; no other platform result is implied.
The Telegram default-photo screenshot documents Saved Messages, while its retained output artifact came from the immediately preceding default-photo test and was not re-downloaded from that exact message.
Platform processing can change by app version, device, account setting, region, quality choice, or delivery mode.
A platform can store or display separate location data even when an output file has no EXIF GPS.

Sources reviewed

Sources were reviewed on July 22, 2026; the independent workflows were tested on August 10, 2026. Platform interfaces and documentation can change, so verify the current controls before relying on them.

Editorial review

This page separates documented platform controls, three independently observed web workflows, and behavior that remains untested. Send corrections when a linked source or product workflow changes.

Huy

Editor, EXIFDataView

Published: Jul 22, 2026
Updated: Aug 10, 2026
Last tested: Shown on test-backed guides

Corrections and reproducible issues belong in the contact workflow. We update visible dates only when the page content or testing notes materially change.

Continue with practical EXIF inspection, location-risk, and cleanup guidance.

Provenance guidesUpdated Jul 25, 2026

C2PA Verification Lab: What Survives an Edit?

Test signed, edited, screenshot, re-encoded, and unsigned synthetic files while separating claim validity from signer trust.

By Huy · Published Jul 25, 2026

Read guide

Privacy guidesUpdated Jul 23, 2026

EXIF Privacy Lab: What a Photo Can Reveal

Use a controlled sample to compare GPS, device, and capture-time metadata before and after local EXIF removal.

By Huy · Published Jul 23, 2026

Read guide

Provenance guidesUpdated May 14, 2026