What Happens to EXIF, HDR & Live Photos When You Move from Apple to Google Photos?
When you capture a memory on a modern iPhone, you aren't just saving a simple .jpg image. You are generating a sophisticated bundle: a 24MP or 48MP HEIC still image, an embedded 10-bit HDR gain map, a 3-second 60fps/30fps HEVC video clip with spatial audio, and dense EXIF metadata containing GPS latitude, longitude, altitude, lens optics, and millisecond timestamps.
When users decide to move their library from Apple Photos on a Mac to Google Photos, they usually do what seems obvious: open a web browser, drag photos from the Photos app into Google Photos, or export them to a Finder folder first.
The result is often catastrophic: Live Photos become lifeless still images, 3-second video clips are dumped as orphaned files scattered across the timeline, and vacation photos taken in Tokyo suddenly show the upload date instead of 2022. Here is the engineering reality of how Live Photos and EXIF work, why web uploads break them, and how native byte streaming preserves 100% of your capture data.
1. The Anatomy of an Apple Live Photo: The Dual-Asset Pair
A Live Photo is not a GIF, and it is not a proprietary single-file container. Under the hood inside Photos Library.photoslibrary, every Live Photo consists of two distinct, synchronized assets:
- The Still Image: An
IMG_xxxx.HEIC(or.JPG) file containing the high-resolution frame. Inside its EXIF MakerNote binary directory sits an Apple metadata key:[MakerNotes] ContentIdentifier = "9B3A2C81-4D52-47E1-897B-7F1F8301B2E0". - The Paired Video: An
IMG_xxxx.MOVQuickTime container containing approximately 45-90 frames of H.264/HEVC video and stereo AAC audio. Inside its QuickTime User Data atom (moov/trak/udta), it carries an identical identifier:[QuickTime:UserData] com.apple.quicktime.content.identifier = "9B3A2C81-...".
When Apple Photos renders a Live Photo, it reads this matching 128-bit UUID, synchronously binds the video to the still photo, and loops or plays the motion when long-pressed.
2. Why Web Browser Drag-and-Drop Destroys Live Photos
When you drag a Live Photo from the macOS Photos app directly into Chrome, Safari, or Edge:
- The Flattening Trap: The browser's drag-and-drop pasteboard (
NSPasteboardItem) only requests the primary representation (kUTTypeJPEG). macOS automatically flattens your 48MP HEIC Live Photo into an 8-bit sRGB JPEG. The paired QuickTime video is silently discarded. - The Orphan Video Nightmare: If you use File > Export > Export Unmodified Original, macOS writes out two distinct files:
IMG_4021.HEICandIMG_4021.MOV. Dragging both into Google Photos web causes the web uploader to ingest them as two independent timeline entries. You end up with a static photo and a random 3-second video clip cluttering your feed. - EXIF Sub-Second & Timezone Corruption: Browsers reading files from disk frequently parse the file system timestamp (
NSFileCreationDate) instead of the true camera sensor tag (SubSecTimeOriginal). If your Mac is in New York and the photo was shot in Tokyo, browser uploads often shift the photo by 14 hours, destroying chronological timeline order.
3. Display P3 Color Gamut & 10-Bit HDR Gain Maps
Modern iPhones (iPhone 12 through iPhone 16 Pro) do not shoot in standard sRGB. They capture images in the Display P3 wide color gamut and embed an Apple HDR Gain Map (ISO 21496-1 standard).
This gain map allows displays like Apple's Liquid Retina XDR or modern OLED screens to render specular highlights (sunlight reflecting off water, neon street signs) at 1,000+ nits while maintaining natural shadow tones. Web browser upload pipelines and naive third-party converters strip this auxiliary HDR gain map, flattening dynamic range into dull, washed-out images.
4. How PhotoRelay Preserves 100% of Live Photos & EXIF
PhotoRelay was engineered in native Swift specifically to preserve raw Apple photography assets. Here is how our ingestion pipeline operates:
Native PHAssetResourceManager Extraction
PhotoRelay queries the macOS PhotoKit framework directly via PHAssetResource. It extracts the raw, unmodified byte stream of both the HEIC master and the paired MOV container directly from disk without decoding or re-compressing.
ContentIdentifier UUID Preservation
PhotoRelay verifies that both the HEIC's Apple MakerNote and the MOV's QuickTime atom share the identical 128-bit com.apple.quicktime.content.identifier UUID.
Dual-Stream Multipart Upload Handshake
Both assets are transmitted to Google Photos via official Google Photos Library API endpoints with proper metadata headers. Google Photos recognizes the matching ContentIdentifier, seamlessly binding them in the cloud into a fully functional Google Photos Motion Photo with live motion and sound.
Bit-for-Bit Color & EXIF Fidelity
Because PhotoRelay performs zero lossy transcoding, your Display P3 color profile, 10-bit HDR gain maps, GPS latitude/longitude, and camera sensor microsecond timestamps remain 100% intact.
Comparison: Browser Drag-and-Drop vs PhotoRelay
| Feature / Technical Capability | Browser Drag & Drop | PhotoRelay Native Relay |
|---|---|---|
| Live Photo Motion & Audio | ❌ Lost (Flattens to static JPG) | ✅ Fully Preserved (Plays with audio) |
| 10-Bit HDR Gain Map & P3 Gamut | ❌ Crushed to 8-bit sRGB | ✅ 100% Bit-for-Bit Preserved |
| EXIF GPS & Sub-Second Timestamps | ⚠️ Scrambled by file creation date | ✅ Exact Camera Sensor Metadata |
| Orphan 3-Second Video Files | ❌ Clutters timeline with random clips | ✅ Bound into single Motion Photo |
Frequently Asked Questions
Will Live Photos play in the Google Photos iOS and Android app?
Yes. Once uploaded with matching ContentIdentifier metadata through PhotoRelay, Google Photos natively recognizes the asset as a Motion Photo. Long-pressing the photo in Google Photos on iOS, Android, or the web will play the full motion and audio.
Does PhotoRelay support Apple ProRAW (.DNG) and 48MP files?
Yes, absolutely. PhotoRelay transfers 12-bit Apple ProRAW Linear DNG files in their full byte-for-byte resolution without any downscaling or lossy compression.
What happens if a photo is missing GPS metadata?
PhotoRelay never alters original EXIF data. If GPS was intentionally disabled when the photo was shot, it will upload cleanly without inserting synthetic location data.