Takeout JSON

Google Takeout Photos Missing Location? Restore the GPS

Where the location data goes in a Google Takeout export, what geoData and geoDataExif mean, why many say 0.0, and how to write real GPS back.

In Google Photos you could search "Lisbon" and get the right trip. After Takeout, the same photos have no location at all. Your new photo app shows a blank map. Someone told you the GPS is in the .json files, and you opened one and found 0.0.

Here is what happened and what you can realistically get back.

Two location fields, and what they mean

Each Takeout sidecar has two location blocks:

"geoData": {
  "latitude": 38.7223,
  "longitude": -9.1393,
  "altitude": 12.0,
  "latitudeSpan": 0.0,
  "longitudeSpan": 0.0
},
"geoDataExif": {
  "latitude": 38.7223,
  "longitude": -9.1393,
  "altitude": 12.0
}

geoDataExif is the position that was in the photo's own EXIF when you uploaded it. If your phone's camera stamped GPS, it is here. geoData is the location Google Photos used, which starts as the same value but also includes places you set or corrected by hand in the app.

When both blocks say 0.0 for latitude and longitude, the photo has no location. That is not a real place; it is Google's way of writing "unknown". A lot of photos are in this state, more than people expect.

Why so many photos have no GPS

Phones only stamp coordinates when location access is on for the camera. Many people turn it off. Screenshots, WhatsApp images, downloaded pictures and scans never had GPS. Older cameras had no receiver at all.

Google Photos hid this from you. It guessed locations from your location history and from landmarks it recognized in the picture, and it showed those guesses in the app. Those estimated locations are not in the sidecar. Only explicit positions are: from EXIF, or from a place you set by hand.

On one real 991-photo Takeout part, 12 percent of sidecars had real coordinates and 81 percent had the 0.0 placeholder. Your library will vary, but if your search in Google Photos worked for photos you never geotagged, that search depended on estimates you did not get back.

Why the GPS is missing from the files themselves

For photos that did have GPS in EXIF, Takeout usually returns the file with that EXIF intact. So a lot of camera photos still carry their coordinates; the app you moved to just has not indexed them yet, or was looking at a different field.

The exceptions are photos whose EXIF was stripped before upload, and photos where you set the location in Google Photos. For those, the sidecar is the only copy. If you delete the sidecars without merging, that location is gone.

Check what you actually have

With exiftool:

exiftool -r -if 'not $GPSLatitude' -ext jpg -ext heic -filename .

lists images with no GPS in the file. Compare it with the sidecars that have non-zero geoData, which you can grep for:

grep -L '"latitude": 0.0' *.json

The overlap is what you can restore.

Restore the coordinates by hand

exiftool can copy geoData from the sidecar into the EXIF GPS tags:

exiftool -r -tagsfromfile "%d/%F.supplemental-metadata.json" \
  -if '$GeoDataLatitude ne 0 or $GeoDataLongitude ne 0' \
  "-GPSLatitude<GeoDataLatitude" "-GPSLatitudeRef<GeoDataLatitude" \
  "-GPSLongitude<GeoDataLongitude" "-GPSLongitudeRef<GeoDataLongitude" \
  "-GPSAltitude<GeoDataAltitude" \
  -ext jpg -ext jpeg -ext heic -overwrite_original .

The -if line matters. Without it you write 0.0, 0.0 into hundreds of photos, and every map view in your new app shows a cluster in the Atlantic Ocean off West Africa. The Ref tags take the sign of the coordinate, which is why they are set from the same value.

Repeat with "%d/%F.json" for older exports. Files with truncated sidecar names and (1) duplicates need special handling, as covered in the exiftool guide.

Restore them with the app

Takeout JSON Metadata Fixer does the same job with no command line, on macOS, Windows and Linux.

It reads geoData first, then geoDataExif, then any GPS already in the file, and writes the coordinates into the photo's EXIF. It treats 0.0, 0.0 as unknown and leaves those photos without a location rather than putting them in the ocean. Dates are written at the same time, since the two problems almost always come together.

If you want the place in the filename or the folder, the app can turn coordinates into a town name and give you 2019-07-14-1105_Lisbon.jpg, or a 2019/Lisbon folder. That lookup uses OpenStreetMap, so it needs an internet connection and sends the rounded coordinates, and nothing else, to that service. Turn it off and the app runs fully offline. Photos with no location simply get a name without a place.

The first 500 photos are free. After that a one-time $9.99 unlocks unlimited photos.

For photos that never had a location

Nothing in the export can recover a position that was never recorded. You can add one yourself, though. Apple Photos, digiKam and Immich let you drop a photo on a map. For a batch, exiftool can set the same coordinates on a whole folder. We cover approaches in adding location to photos without GPS.

Frequently asked questions

Google Photos showed a location for this photo. Why is the sidecar zero?

Because that location was estimated from your location history or from the image content, and estimates are not exported. Only coordinates from the file or from a manual edit are.

Should I use geoData or geoDataExif?

geoData includes your manual corrections and is otherwise equal to geoDataExif. Use geoData, and fall back to geoDataExif if it is zero.

Will Immich or Apple Photos read the GPS after merging?

Yes. Both read the standard EXIF GPS tags, which is where the merge writes them. Immich shows them on its map view after it reindexes the file.

Can I remove GPS instead, for privacy?

Yes. exiftool -gps:all= -overwrite_original . strips it from a folder. Do this after organizing if you still want location-based folder names.

Related articles