Takeout JSON

Takeout Live Photos: the MP4 and MOV Pairs, Explained

Why iPhone Live Photos come out of Google Takeout as a still plus a short video, why the video has the wrong date, and three ways to handle the pairs.

Your Takeout has IMG_4698.HEIC and, right next to it, IMG_4698.MP4, a three-second clip. Thousands of these pairs. The photo has the right date once you merge its sidecar. The clip is dated today, and in your new gallery it sits alone at the end of the timeline as a random short video.

Those are Live Photos. Google stores them as two files, and only one of them has a sidecar.

What a Live Photo is on disk

When an iPhone takes a Live Photo it saves a still image and a short video of the moments around it. Apple keeps them as two files, IMG_4698.HEIC and IMG_4698.MOV, linked by a shared content identifier written into both. Apple Photos shows them as one item.

Google Photos accepts the pair and displays it as one item too. In Takeout you get both files back, usually with the video re-wrapped as .MP4, sometimes still .MOV. The still has a .json sidecar with the real photoTakenTime. The clip usually has none. Its date lives only in the video container, and sometimes not even there.

Pixel and Samsung phones do the same thing differently. Their "Motion Photos" embed the clip inside the JPEG as one file. Takeout returns those as a single .jpg that plays on Android and looks like a still everywhere else. See Motion Photos and Live Photos explained for the difference.

Why the clip gets today's date

Photo apps date a video by the creation time in its MP4 or MOV container. Google's re-wrap often leaves that field empty or set to the upload time. With no sidecar to override it, a metadata tool has nothing to write, and the clip falls back to the file's modified time, which is when you unzipped.

So the still lands on 14 July 2019 and its clip lands on the day you did the export. In Apple Photos, Immich or an Android gallery, the two are no longer recognized as a pair. You get a still and, far away in the timeline, an orphan clip.

Fixing pairs by hand

The rule is simple: the clip should get the still's date. With exiftool, in a folder of pairs:

for v in *.MP4; do
  s="${v%.MP4}.HEIC"; [ -f "$s" ] || s="${v%.MP4}.JPG"
  [ -f "$s" ] && exiftool -tagsfromfile "$s" "-CreateDate<DateTimeOriginal" \
    "-ModifyDate<DateTimeOriginal" "-TrackCreateDate<DateTimeOriginal" \
    "-MediaCreateDate<DateTimeOriginal" "-FileModifyDate<DateTimeOriginal" \
    -overwrite_original "$v"
done

Run this after merging the sidecar dates into the stills, so DateTimeOriginal is already correct. Repeat for .MOV. Any short video with a matching still name is a Live Photo clip; a long video with a matching name is a coincidence, so check the durations if your naming is unusual.

Then keep the pair together. Same folder, same base name. If you rename stills by date, rename the clip identically. Apple Photos and Immich pair them by name on import, and a renamed still with an un-renamed clip breaks that.

The three choices

Keep the pair. The clip sits beside the still with the same name and date. Apple Photos, Immich and Google Photos re-pair them on import and the photo stays live. This is the safe default and the only choice if you are heading to Apple Photos.

Photo only. Drop every clip. Many people never look at the moving version and the clips add 30 to 50 percent to the library size. Nothing else is lost. You cannot get the clips back later without the original export, so keep the zips.

Merge into one Motion Photo. Embed the clip inside the JPEG the way Pixel and Samsung phones do. One file per photo, plays in Google Photos and most Android galleries, shows as a normal still everywhere else. Apple Photos does not read Motion Photos, so this suits people going to Android or a plain folder, not to a Mac or iPhone.

Doing it with the app

Takeout JSON Metadata Fixer finds the pairs and offers those three choices, on macOS, Windows and Linux.

It matches a still and a short video with the same base name in the same folder, and reads Apple's content identifier when the clip carries it, so a long unrelated video is not mistaken for a clip. The clip inherits the still's date and GPS from the sidecar. With "Keep the clip beside the photo", the default, both files get the same new name and folder, so the pair survives renaming and sorting into year and month folders. "Photo only" drops the clips and does not count them against the free 500. "Merge into one Motion Photo" writes a single JPEG with the clip embedded.

HEIC stills can be converted to JPG at the same time; the pairing still works because the name is preserved. The first 500 photos are free.

Frequently asked questions

Some clips are .MOV and some are .MP4. Does it matter?

No. Google re-wraps most clips to MP4 but some come through as MOV. Both are handled the same way. If you want one container for everything, the app can re-wrap MOV to MP4 without re-encoding.

Apple Photos imported the pair as two items. Why?

The names did not match, or the clip's date was too far from the still's, or the two ended up in different folders. Put them side by side with identical base names and re-import.

Will Immich show Live Photos?

Yes. Immich pairs a still and a clip with the same name on upload and shows the live badge. immich-go does this too.

Why does a Live Photo count as two photos toward the free limit?

Because it is two files. Only the "Photo only" mode skips the clips entirely; in the other modes the clip is processed and counted.

Related articles