August 9, 2026

Why your iPhone photos still have location data when GPS is off

You went to Settings → Privacy & Security → Location Services → Camera and set it to Never. You shared a photo anyway. Someone opened it and the map still showed your street.

This is one of the most common privacy surprises on iOS, and the reason is not that the toggle is broken. It's that "location" on an iPhone is not one thing stored in one place. It's at least four different things stored in four different places, and the Camera toggle only governs one of them.

The four places iOS records where you were

1. EXIF GPS tags inside the image file

This is the one everybody means. A photo taken with Location Services enabled gets a block of GPS tags written directly into the file:

GPS Latitude                    : 37 deg 46' 29.88" N
GPS Longitude                   : 122 deg 25' 9.12" W
GPS Altitude                    : 15.7 m Above Sea Level
GPS Speed                       : 0
GPS Date/Time                   : 2026:08:09 18:22:41Z
GPS Horizontal Positioning Error: 4.87 m

Note that last field. Modern iOS writes a horizontal error estimate, and when it says roughly five metres, that is not "somewhere in this neighbourhood." That is which side of the building you were standing on.

Turning the Camera permission off does stop these tags from being written on new photos. It does nothing to photos already in your library. If your surprise came from a photo taken last year, this is almost certainly the explanation — the toggle is not retroactive, and nothing in iOS goes back and cleans your existing library.

2. The Photos library database

Open a photo in the Photos app and tap the info button. You may see a place name even for a photo with no EXIF GPS at all.

That's because the Photos app keeps its own database alongside the image files, and location lives in that database as well as in the file. Photos also reverse-geocodes coordinates into names — "Golden Gate Park", "Cafe on Valencia" — and stores those names too. The Places album and the Memories feature are built on this database, not on EXIF.

The practical consequence is the one that trips people up: what the Photos app shows you is not what's in the file. You can be looking at a photo the app labels with a neighbourhood while the exported file contains no GPS whatsoever, and you can also have the reverse. If you want to know what a recipient will actually receive, you have to inspect the exported file, not the app's info panel.

3. Live Photos — the video half nobody checks

This is the one that catches even careful people.

A Live Photo is not one file. It's a pair: a still (HEIC or JPEG) plus a short QuickTime .mov. When you export, AirDrop, or back up a Live Photo, both halves travel together.

You may strip the EXIF from the still and consider the job done. But the .mov carries its own metadata in QuickTime atoms, entirely separate from EXIF, including:

com.apple.quicktime.location.ISO6709 : +37.7747-122.4192+015.700/
com.apple.quicktime.make             : Apple
com.apple.quicktime.model            : iPhone 15 Pro
com.apple.quicktime.creationdate     : 2026-08-09T18:22:41-0700

That ISO6709 string is a full coordinate pair with altitude. An EXIF cleaner that only understands images will hand back a spotless still and leave the paired video untouched, with your coordinates sitting in plain text inside it.

If you handle Live Photos, clean both halves, or convert to a still first.

4. Third parties putting it back

Location can re-enter a file after you have cleaned it. Editing apps that read a photo and write a new one often copy the original metadata forward. Cloud services may restore metadata from their own copy when you re-download. And plenty of apps request Photos access with full metadata even though they only need the pixels.

Cleaning is a step in a pipeline, not a permanent property of an image. Whatever you clean, clean it last, immediately before the file leaves your control.

Why the share sheet toggle isn't the answer either

iOS offers a per-share Options → Location: Off control. It works, and it's genuinely useful. But note the scope: it strips location from that one share. The file in your library is unchanged. The next time you share it — a different app, a different day, a moment when you don't think to check — the coordinates go out with it.

It's a per-transmission filter, not a fix to the file. For anything you'll share more than once, or for files already sitting on disk, you want the file itself cleaned.

Check it yourself in ten seconds

Never trust a tool's claim, including ours. Export the photo the way you'd actually send it, then look:

exiftool -GPS:all -a -G1 your_photo.jpg

Empty output means no GPS. For a Live Photo, check the video half too:

exiftool -ee -G1 -Location -GPS:all your_live_photo.mov

No exiftool? Drop the file into the image metadata viewer — it runs in your browser and lists every field it finds, including the QuickTime atoms in a .mov.

Do this on a file you know has location before you rely on any tool. If the check can't detect GPS in a photo that definitely has it, the check is what's broken.

Removing it

For files already on disk, the reliable approach is to re-encode from pixels only. Draw the image to a canvas, read the bitmap back out, and write a new file — metadata never enters the bitmap, so there's nothing to carry across. That's the mechanism behind remove GPS from photo, and it runs locally: open your browser's Network tab and watch zero requests fire while it works.

A note on HEIC. Browsers can't decode Apple's HEIC format natively, so convert to JPEG first — on iOS, Settings → Camera → Formats → Most Compatible, or export as JPEG from the Files app. Then clean the JPEG.

What this doesn't solve

The short version

The Camera location toggle governs one of four location stores, and only for photos you take after flipping it. Your existing library, the Photos database, and the video half of every Live Photo are all untouched by it. Verify the exported file rather than trusting the app's info panel, and clean as the last step before sharing rather than the first.