MemoriesExport.Fix my export

Technical

The QuickTime Keys:GPSCoordinates atom: why an MP4 with GPS still has no location in Apple Photos

Guides · Video metadata

You wrote GPSLatitude and GPSLongitude to an MP4. exiftool said “1 image files updated”. The tags read back. Apple Photos still shows no place, and the clip never appears under Places. Nothing failed — the coordinates went into a field Apple Photos does not consult for video. This page explains where video location actually lives, how the three candidate fields differ, and the exact commands to inspect and set the right one.

The short version

Three different places “GPS” can live in an MP4

An MP4 or MOV is a tree of boxes (atoms). Metadata is not one place; it is several boxes that different writers and readers happen to prefer. For location, three matter:

A file can carry all three, disagree between them, and still show no place in Photos if the Keys atom specifically is absent. That is the whole failure mode.

What writing EXIF GPS to an MP4 really does

This is the step worth reproducing yourself, because the silent redirect is what makes the bug so confusing. Take any MP4 and run the command that works perfectly on a JPEG:

exiftool -overwrite_original \
  -GPSLatitude=59.9139 -GPSLatitudeRef=N \
  -GPSLongitude=10.7522 -GPSLongitudeRef=E \
  clip.mp4

exiftool reports 1 image files updated and exits 0. Now ask the file what it stored:

exiftool -G1 -s -a clip.mp4 | grep -i gps
[XMP-exif]      GPSLatitude       : 59 deg 54' 50.04" N
[XMP-exif]      GPSLongitude      : 10 deg 45' 7.92" E
[Composite]     GPSPosition       : 59 deg 54' 50.04" N, 10 deg 45' 7.92" E

Note the group in square brackets. There is no [EXIF] group and no [Keys] group — the tags were diverted into XMP because an MP4 has no EXIF IFD to hold them, and [Composite] is exiftool computing a display value from what it found. The file now looks tagged in every metadata viewer you will check it in, and Apple Photos will still show no place. The -G1 flag — print the specific group, not just the family name — is the single most useful habit when debugging this class of problem.

Inspecting what a file actually has

Ask for the Keys atom by name:

exiftool -G1 -s -Keys:GPSCoordinates clip.mp4

On a file that lacks it, this prints nothing at all and still exits 0 — empty output is the diagnosis. On a file that has it:

[Keys]          GPSCoordinates    : 59 deg 54' 50.04" N, 10 deg 45' 7.92" E

exiftool pretty-prints the value. To see the bytes as stored, add -n for the numeric form:

$ exiftool -G1 -s -n -Keys:GPSCoordinates clip.mp4
[Keys]          GPSCoordinates    : 59.9139 10.7522

On disk the atom holds the ISO 6709 string +59.9139+010.7522/, sitting next to its key name in the Keys table. You can see it without any tool at all:

strings -a clip.mp4 | grep quicktime.location

To compare all three candidate fields at once on a file you are debugging:

exiftool -G1 -s -a \
  -Keys:GPSCoordinates \
  -UserData:GPSCoordinates \
  -XMP:GPSLatitude -XMP:GPSLongitude \
  clip.mp4

Writing the atom

The fix is to name the group explicitly. exiftool takes decimal degrees separated by a space and encodes ISO 6709 for you:

exiftool -overwrite_original \
  "-Keys:GPSCoordinates=59.9139 10.7522" \
  clip.mp4

Negative values are south and west, as usual: "-Keys:GPSCoordinates=-33.8688 151.2093" for Sydney, "-Keys:GPSCoordinates=40.7128 -74.0060" for New York. Quote the whole assignment so the shell keeps the space and does not read the leading - as a flag. If you also want the value visible to players and Android galleries, write the older atom in the same pass — the two do not conflict:

exiftool -overwrite_original \
  "-Keys:GPSCoordinates=59.9139 10.7522" \
  "-UserData:GPSCoordinates=59.9139 10.7522" \
  clip.mp4

Verify with the read command above. If [Keys] appears in the output, the field Apple Photos reads is populated, and the clip should carry its place on import.

The date has exactly the same problem

Anyone hitting the GPS issue usually hits the date issue in the same hour, for the same structural reason. QuickTime:CreateDate is defined as UTC and stores no offset, so a wall-clock time written there is reinterpreted on read:

$ exiftool -G1 -s -QuickTime:CreateDate clip.mp4
[QuickTime]     CreateDate        : 2021:06:02 14:31:05

$ exiftool -G1 -s -api QuickTimeUTC=1 -QuickTime:CreateDate clip.mp4
[QuickTime]     CreateDate        : 2021:06:02 16:31:05+02:00

The Keys equivalent, com.apple.quicktime.creationdate, takes an explicit offset and is unambiguous, which is why it is the one to set when you want a clip to sit in a timeline next to photos taken at the same moment:

exiftool -overwrite_original \
  "-Keys:CreationDate=2021:06:02 14:31:05+02:00" \
  "-CreateDate=2021:06:02 14:31:05" \
  "-ModifyDate=2021:06:02 14:31:05" \
  clip.mp4

Why exiftool, and not a library

The honest reason this is a hard dependency in anything that has to get video location right: the ecosystem splits along the wrong seam. Image metadata libraries — the Pillow/piexif tier in Python, the equivalents in Rust — are EXIF-shaped, and EXIF is a JPEG/TIFF structure that has no place in an ISO base media file. Video libraries, meanwhile, are demux/encode-shaped: they read container metadata willingly, but changing it generally means remuxing the file through the tool’s own writer, which rebuilds the boxes it knows about and quietly drops the ones it does not. Writing one specific Apple Keys atom in place, preserving every other box byte-for-byte, is a narrow job that only exiftool has done well for long enough to trust across the shapes of real-world files.

There is a practical consequence worth knowing: exiftool silently ignores Keys:* tags when the target is a JPEG. It does not warn, does not fail, and writes the EXIF tags in the same command normally. That means a single tag set can be applied to a mixed directory of photos and videos, with each file taking the fields that apply to it — which is exactly how batch tagging stays simple.

Doing it to a whole library

One exiftool process per file spends most of its time starting up, so a per-file loop gets slow long before a real library is done. exiftool’s CSV mode takes one row per file and applies the whole set in a single run:

SourceFile,DateTimeOriginal,CreateDate,Keys:CreationDate,Keys:GPSCoordinates
clip.mp4,2021:06:02 14:31:05,2021:06:02 14:31:05,2021:06:02 14:31:05+02:00,59.9139 10.7522
photo.jpg,2021:06:02 14:33:41,2021:06:02 14:33:41,,
exiftool -csv=tags.csv -overwrite_original -progress -@ filelist.txt

Two details that matter at scale. Pass the file list via -@ rather than a shell glob, or a large library will overflow the argument limit; add -charset filename=utf8 if any path is non-ASCII. And -progress prints a [current/total] counter per file, which is the only sane way to drive a progress bar over a run this long.

One ordering rule: if you are also compositing anything onto the frames — a caption, a sticker, a watermark — re-encode first and tag second. The encode writes a new file and will not carry your atoms across.

Where this bites hardest

The most common way to meet this problem is a Snapchat Memories export. The capture time for each memory — and its coordinates, where Snapchat recorded any — sits in the export’s memories_history.json manifest, while the media files themselves come out with their date and location fields blank. The commands above are the whole fix, and you can run them yourself: parse the JSON, match entries to files, emit the CSV, run exiftool once.

If you would rather not write that matcher for several thousand files, MemoriesExport does exactly this. You export from Snapchat yourself and hand it the zip files you downloaded; it reads the manifest and writes Keys:GPSCoordinates, Keys:CreationDate and the EXIF equivalents for photos in one exiftool pass, with no re-encoding of the video. The first 100 main memories are free and a one-time $9.99 unlocks the rest for life; there is an offline Mac and Windows app if you would rather nothing left your machine. The non-technical version of this page is why Snapchat videos never show up on the Apple Photos map.

Fix my Snapchat export →

Frequently asked questions

Which field does Apple Photos read for video location?
The QuickTime Keys atom com.apple.quicktime.location.ISO6709, which exiftool exposes as Keys:GPSCoordinates. It is a single ISO 6709 string such as +59.9139+010.7522/ stored in the mdta Keys metadata namespace. EXIF GPS tags and the older UserData ©xyz tag are not what places a clip on the Photos map.
Why did writing GPSLatitude and GPSLongitude to my MP4 do nothing?
There is no EXIF IFD in a normal MP4, so exiftool has nowhere to put those tags in their native form. It falls back to writing them into an XMP-exif block inside the file. The command succeeds and the tags read back, but Apple Photos ignores XMP for video location, so the clip still has no place.
What is the difference between Keys:GPSCoordinates and UserData:GPSCoordinates?
They are two different atoms. UserData:GPSCoordinates is the older ©xyz atom in the moov/udta box; Keys:GPSCoordinates is com.apple.quicktime.location.ISO6709 in the moov/meta Keys box. Many tools and cameras write ©xyz, and plenty of players display it, but Apple Photos reads the Keys atom. Writing both is harmless.
Is exiftool really required, or is there a library that does this?
For writing the Keys atom in place, exiftool is the practical answer. The common image libraries write EXIF and stop at photos, and the common video libraries either only read metadata or force a full remux to change it. exiftool rewrites the moov box in place without re-encoding, which is why it is a hard dependency in tooling that has to get this right.
Does writing this atom re-encode the video?
No. exiftool rewrites the container's metadata boxes and leaves the media samples untouched, so quality is unchanged and the work does not scale with the length of the clip. If you also composite something onto the frames, do that first and tag afterwards, because re-encoding drops metadata.