For a long time my mental model of photo location was a database one. The phone keeps a list of photos, each photo has a "place" field, and the map in the gallery app reads that field. Under that model, sending someone the photo sends the picture, and the place stays behind in the phone's database. It's a reasonable guess, and it's wrong in the way that matters most: the location is written into the image file itself, so it travels with every copy of that file, and only disappears when some program writes a new file without it.
Where it actually lives
A JPEG from a phone is not just compressed pixels. Near the start of the file there is a metadata block called EXIF, and inside it are several small tables of tags. One table describes the camera and exposure. Another, pointed to by tag 0x8825, is the GPS block: latitude, longitude, altitude, sometimes a timestamp. The pixels come after all that in the same file. So "the photo" and "the photo's location" are literally neighbours in one sequence of bytes, and anything that copies the file byte for byte (email attachment, USB stick, cloud folder sync) copies both.
To see it for myself I used a real photo I'm allowed to share: "Avions à l'aéroport de Madrid - 2015" from Wikimedia Commons, which is released under CC0 and was taken on an iPhone 6. Then I made two derived files. One is a screenshot of that photo displayed at 1000×750 in a headless browser. The other is a copy resized to 1200 px with macOS's built-in sips tool, the kind of "make it smaller before sending" step a lot of people do. For each of the three files I opened it with Pillow in Python, read the camera model from the main EXIF table, then followed tag 0x8825 into the GPS block and read the latitude.
The original is 3264×2448, says iPhone 6, and has a latitude of 40 degrees, 29 minutes, 27.76 seconds north, which is 40°29′27.76″N. The screenshot is 1000×750 and has neither a camera model nor a latitude. The resized copy is 1200×900, still says iPhone 6, and still has 40°29′27.76″N. It's about 37% of the original's width and says exactly the same thing, down to the hundredth of a second of arc. That was the result I didn't expect. I'd assumed resizing counted as "making a new photo".
Why the screenshot is different
The screenshot looks almost the same as the original, yet it has no GPS and not even a camera model. Once I thought about how it's made, that stopped being surprising. A screenshot isn't a copy of the photo file. The screenshot tool takes the pixels currently being displayed and encodes them into a brand-new PNG, and the only metadata in that PNG is whatever the screenshot tool decides to write. The display never had the GPS block in the first place; it only ever received pixels. I also checked a screenshot from the macOS system screenshot tool (of my screen, not of this photo), not only the browser one: the PNG it produced had a colour profile, some XMP and a very small EXIF block, and no GPS in any of them.
A resized copy works on the same principle but with a different outcome. The resizing program reads the old file, makes new pixels, and writes a new file, and at that point it chooses what metadata to carry over. sips chose to carry the GPS over. Pillow's default save, in the tests I ran on the same photo, writes no EXIF at all, so its copy came out with no location. Neither behaviour is "correct"; they're just different programs making different choices, and the file name or format tells you nothing about which one happened.
What I still don't know
Phone gallery apps let you hide or change a photo's location, and I wanted to know whether that edits the file or just the app's own records. I don't know. Apple's documentation for the Photos app talks about hiding the location and reverting to the original, which suggests the original value is kept somewhere, but it doesn't say where, and I'd rather not guess. Also, the screenshot shows an airport apron with airline logos on the planes, which is its own kind of location information that no metadata tool will remove.
So the practical version of all this for me is small. Location is a property of a specific file, not of "the photo" in the abstract. Before I send or upload something, I check that exact file, the one I'm about to attach, by reading its GPS block the same way as above, instead of trusting that some earlier step must have stripped it.
Top comments (0)