Your photos know where you live

What’s actually in the file

EXIF is a block of tagged fields sitting in the header of a JPEG or HEIC, defined by a Japanese industry spec (JEITA, now CIPA) that camera makers have been extending since the late nineties. Your phone fills in more of it than you’d guess. The parts that matter for privacy:

The coordinates are the sharp end. A phone with a clear sky writes a fix that is good to a handful of metres, which on a map is your building, not your neighbourhood. Indoors it falls back to Wi-Fi positioning and gets vaguer, but “vaguer” still means the right street. And it is not one photo, it is the pattern: a few dozen images with coordinates and timestamps sketch out where someone sleeps, works and drops their kids off, without a single word of caption.

Formats differ. JPEG and HEIC carry EXIF by default. PNG had no standard EXIF chunk until eXIf was added in 2017, which is why old PNG screenshots are metadata-poor almost by accident. WebP and AVIF both have metadata boxes and will happily carry an EXIF payload across a conversion, so switching format is not a way to sanitise a file.

The photo that found McAfee

The story everyone half-remembers, with the details right. On 3 December 2012 Vice published a piece about being with John McAfee, then on the run from Belizean police, headlined “We Are With John McAfee Right Now, Suckers”. The photo at the top was taken on an iPhone 4S with location services on, and it went up with the EXIF intact.

Within hours people were reading the GPS tags out of the file. The coordinates put the shot at a resort by the pool in the Río Dulce area of Guatemala, several hundred kilometres from where McAfee was supposed to be hiding. McAfee first claimed he had deliberately faked the metadata to mislead pursuers, then admitted the next day that he was indeed in Guatemala, where he was picked up shortly after. He blamed “an unseasoned technician at Vice headquarters”.

The bit worth keeping: nobody hacked anything. A publisher uploaded a file from a phone to a CMS, and the CMS passed the bytes through unchanged. That is still the default behaviour of a depressing number of upload paths, fourteen years later.

Who strips EXIF, and who just hides it

The big social platforms do strip. Upload a geotagged photo to Facebook, Instagram or X, download it back, and the GPS tags are gone from the file you get; the platforms recompress everything on ingest and the metadata does not survive that pass. So the specific risk of a stranger pulling your home coordinates out of your Instagram post is largely dealt with.

What that does not mean: that the data was never collected. The file you uploaded contained the coordinates, and the server read them before it produced the version everyone else sees. Stripping on delivery is a rendering decision, not a deletion. Meta’s own data-download archives have historically included metadata from uploads, and the platforms’ location features have to come from somewhere. Treat “platform X strips EXIF” as protection against other users, and nothing else. If the company is in your threat model, the metadata has to be gone before the upload starts.

Also worth remembering that stripping is not consistent within a single company. It applies to the image pipeline for posts. Anything that ships a file rather than an image, such as an attachment in a chat product or a link to the original in a storage product, follows completely different rules.

The gaps where EXIF walks straight through

These are the paths where the original file arrives at the other end byte for byte:

• Email attachments. No recompression, no processing, nothing. Your mail client attaches the file it was given. This is the single most common way a geotagged original leaves a device, and no one thinks about it because email feels private, which is not the same as clean.
• Chat apps in document mode. WhatsApp compresses photos sent as photos, and the EXIF dies in that step. Send the identical file with “Document” instead and it goes as-is, GPS included. Telegram’s “send as file” works the same way. That is a feature, journalists and photographers rely on it, but it means the privacy behaviour of one app depends on which button you tapped.
• Cloud share links. A link to a file in a storage service serves the original file. Sharing an album from Google Photos is a different case: Google’s help pages state that apart from partner sharing, links, albums and conversations you share do not include location details by default. Anything where the recipient downloads the source file, though, gives them the source file.
• Your own website. If your CMS or static-site build copies uploads into a folder without touching them, everything is still in there. Worth a spot check with exiftool on a handful of production images.

Removing location before you send

On iOS this has been in the share sheet since iOS 13: tap Options at the top of the sheet, switch Location off, then choose where it goes. It sticks for that share and covers every item you selected. The original in your library keeps its coordinates, which is usually what you want, since the map view in Photos is genuinely useful. If you want the location gone from the stored photo too, open it, bring up the info panel and use Adjust or Remove Location.

Android has no single system-wide equivalent, it depends on the gallery app. Google Photos exposes location removal per photo and controls what shared links carry. The platform-level change worth knowing is quieter and better: since Android 10, an app that reads your photos through MediaStore gets the location tags redacted unless it holds the separate ACCESS_MEDIA_LOCATION permission. Storage access and location access were split apart, so a random photo-editing app no longer gets your movements for free just because it can open your gallery.

For bulk work on a machine, exiftool -gps:all= -overwrite_original *.jpg takes out the GPS block and leaves the rest, and exiftool -all= takes out everything. Check the result rather than trusting the command; some files carry the same information twice, in EXIF and in an XMP packet, and a GPS-only removal leaves the XMP copy sitting there.

Why stripped photos come out sideways

You strip metadata from a batch of holiday photos, open the folder, and half of them are lying on their side. This is the most common self-inflicted wound in the whole topic, and it has a specific cause: EXIF tag 0x0112, Orientation.

Phone sensors are mounted in a fixed direction. When you shoot a portrait photo, the camera often does not rotate the pixel data; it stores the frame the way the sensor read it and sets Orientation to a value that says “display this rotated 90 degrees clockwise”. The tag has eight legal values, four rotations and four mirrored variants. Every viewer that reads EXIF applies it, so you never notice. Delete the metadata and the instruction goes with it, leaving the raw landscape pixels on screen.

The order of operations is the whole fix: apply the rotation to the pixels first, then remove the metadata. ImageMagick’s -auto-orient flag does exactly that and must come before -strip. In Node, sharp’s .rotate() with no argument means “read the EXIF orientation and bake it in”, and sharp discards metadata by default anyway. Get this wrong on a user-upload pipeline and you will hear about it, because it is a bug users can see instantly and describe perfectly.

For developers: re-encode, don’t delete

If you accept image uploads, the safe default is to decode the image and encode a new one, rather than to surgically remove the EXIF block from the file you were handed. Two reasons.

First, coverage. EXIF is one of several metadata containers. There is also XMP (an RDF/XML packet, often with a second copy of the coordinates), IPTC blocks from editing software, ICC profiles, JPEG comment segments, and in HEIC and AVIF a set of metadata boxes with their own rules. A stripper that knows about EXIF and nothing else is a stripper that leaks. Decoding to pixels and re-encoding produces a file whose metadata is whatever you chose to write, which is a much easier thing to reason about.

Second, everything else you get for free. Re-encoding is where you cap dimensions, normalise the format, enforce a size budget, and neutralise files that are a valid image and something else at the same time. Polyglot files, where the same bytes parse as both an image and a script, stop being interesting once the bytes are regenerated from a decoded bitmap. The same logic applies to any user-supplied content you pass along: what looks like inert data often carries a payload, which is also the story behind zero-width characters hiding inside text you thought was plain.

Practical shape of it, whatever your stack: decode, auto-orient, resize to your maximum, re-encode with your chosen quality, write only the metadata you want (an ICC profile if colour matters, nothing else), store under a name you generated. Keep the original if your product needs it, but keep it somewhere the web server does not serve directly.

What stripping metadata does not fix

Metadata is the easy half. The photo itself often gives away more, and no tool removes that: the view out of the window, the house number across the street, the reflection in the kettle, the school logo on a jacket. People-search and OSINT work leans on visible details far more than on EXIF, precisely because EXIF disappeared from the big platforms years ago.

Two more things that survive a clean strip. Perceptual hashes of the image content still match the same picture across services, so removing tags does not make a file unlinkable; taking metadata off a photo is a hygiene step, not a security control, the same category error as treating base64 as encryption. And anything you did to the image with a browser tool is only as private as that tool, which is why our own converters run entirely in the browser and never send a file anywhere. A metadata remover that uploads your photo to a server to remove the location from it has, at minimum, an amusing threat model.

Three habits we picked up from cleaning up upload pipelines: strip on the device for anything personal, re-encode on the server for anything a user sends you, and check with exiftool instead of assuming. The assumption is where the coordinates always turn out to be.

Questions about photo metadata