← Back to all guidesUpdated Sep 30, 2026
Every photo on your phone carries metadata behind it. Date taken. Camera. GPS. Lens. Aperture. Edit history. When you move photos between cloud services and local storage, some of that survives and some of it quietly disappears. This guide covers which fields travel, which paths strip them, and what to do if your library has already lost them.
Written by Charles
What lives in photo metadata
Three formats matter. EXIF is the camera-and-settings block: date taken, camera model, lens, aperture, shutter, ISO, GPS. IPTC is the editorial block: caption, copyright, byline, headline. XMP is the edit block: Adobe-style non-destructive edits, ratings, keywords.
- EXIF: date taken, camera body, lens, aperture, shutter, ISO, GPS
- IPTC: caption, copyright, byline, headline
- XMP: edits, ratings, keywords (Adobe-style)
- Sidecar JSON: Google Photos and Apple export metadata in separate JSON files alongside the JPEGs
What survives each transfer
Every cloud service has its own behaviour. Some paths strip aggressively; others preserve everything. The list below is what the guides can verify against current platform behaviour; platform exports change occasionally, so re-verify on a sample after a major update.
- iCloud Photos to local via Photos app export: full EXIF preserved
- iCloud Photos to local by dragging from iCloud Drive: EXIF preserved
- Google Photos to Google Takeout: EXIF in the JPEGs, plus a sidecar JSON with album and shared-album metadata
- Google Photos to direct download from photos.google.com: EXIF preserved in the original ZIP
- Dropbox to local: EXIF preserved
- Local to Instagram upload: EXIF stripped on upload (Instagram policy)
- Local to Facebook upload: EXIF stripped on upload (Facebook policy)
- WhatsApp images to save to local: EXIF stripped by WhatsApp on send
Sidecar JSON files in Google Takeout
Google Takeout puts metadata that does not fit in JPEG headers into separate JSON files. The pattern is one `*.json` file per image, named the same as the image but with `.json` appended. Album membership, shared-album metadata, and some Google-specific edits live in these files. If you only copy the JPEGs to local storage and ignore the sidecars, you lose that metadata.
- Path pattern: `Takeout/Google Photos/Photos from 2024/IMG_1234.jpg` with `IMG_1234.jpg.json` next to it
- Albums.json at the top of the export describes the album hierarchy
- Some sidecars hold edits Google applied automatically. Re-merging requires a tool, not a manual process
How to check your library for lost metadata
exiftool reads and writes EXIF, IPTC and XMP on every platform. It is the standard tool for this. Before assuming a transfer lost your metadata, run it on the original and the copy and diff.
- macOS / Linux: install exiftool via Homebrew (`brew install exiftool`) or your package manager
- Windows: download from exiftool.org; rename `exiftool(-k).exe` to `exiftool.exe`
- Inspect one file: `exiftool path/to/IMG_1234.jpg`
- Inspect a folder recursively: `exiftool -r path/to/folder`
- Diff: hash the EXIF block on the original and the copy with `exiftool -s -DateTimeOriginal -GPSPosition file.path`
How to recover stripped metadata
If the metadata was lost on the way out, you cannot recover it from the file alone. If the platform still has it, you can re-export. If it is in a sidecar JSON, exiftool can write it back into the JPEG.
- Re-export from the platform: iCloud, Google Photos and Dropbox all retain EXIF server-side and can re-issue it
- Recover from sidecar JSON: exiftool reads Google Takeout sidecars and can write the metadata back into the JPEG
- Adobe Bridge and digiKam handle batch read/write of EXIF and XMP
- GPS is the field people most often want back. Once stripped from the original, only a re-export can restore it
How to preserve metadata going forward
The safest pattern is to always export through the original / unmodified option on every platform. Cloud services that re-encode on download are the ones that strip.
- Always pick "Original" or "Unmodified" on export. Never the "optimised" or "compatible" option
- Avoid services that re-encode on download. They almost always strip EXIF
- When uploading to share, accept that the destination may strip on its side. Your archive keeps the original
- For long-term storage, sync via a tool that copies files unmodified. rsync, rclone and Syncthing all preserve metadata
When this matters and when it does not
For casual photo libraries, lost metadata is an inconvenience. For a photo library that documents a year of a child growing up, a decade of travel, or work that needs to be attributed and dated, it is the difference between an archive and a pile of files.
- Casual sharing: who cares, the destination will strip it anyway
- Personal archives: EXIF matters. Date and GPS anchor memories and travel history
- Working photographers: copyright, byline and edit history are part of the work. Strip them and the archive has no provenance
FAQ
Does Google Photos strip metadata?
Google Takeout preserves EXIF in the JPEGs and adds sidecar JSON files for album and edit metadata. Direct download from photos.google.com also preserves EXIF.
Does iCloud strip metadata?
iCloud Photos export via the Photos app preserves full EXIF. Drag-from-iCloud-Drive also preserves it.
What is a sidecar JSON?
A separate JSON file alongside the image, with the same name and a `.json` extension. Google Takeout uses this pattern for metadata that does not fit in JPEG headers.
Can I recover stripped GPS?
Not from the file alone, once stripped. Only a re-export from the original platform can restore GPS.
Is there a tool to batch-check metadata?
exiftool reads and writes EXIF, IPTC and XMP on every platform. `exiftool -r path/to/folder` inspects a folder recursively.