DEV Community

Cover image for Image Metadata Privacy Leaks: EXIF, GPS & Thumbnails
Muhammad Ali Mughal
Muhammad Ali Mughal

Posted on

Image Metadata Privacy Leaks: EXIF, GPS & Thumbnails

#privacy #webdev #tutorial #security

A photo is two things: the pixels you chose to share, and a block of metadata you probably never looked at. The pixels are reviewed. The metadata is not, and it can carry the GPS position where the shot was taken, the exact device that took it, a timestamp with your timezone offset, your name from an editing app, and sometimes a small preview of the uncropped original.

I build privacy and developer tools at PixelValut, and this is the leak I most often find in otherwise careful people's files. The fix is not complicated, but you have to verify it, because "the platform strips it" is a belief, not a test.

What does image metadata reveal, and how do you remove it?

Direct answer: JPEG, PNG, WebP and HEIC files can embed EXIF, XMP and IPTC metadata: GPS coordinates, camera make, model and serial number, capture time, author names and an embedded thumbnail. Remove it before sharing with a metadata stripper, then verify by re-reading the exported file, not the original.

Where the leak lives: EXIF, XMP, IPTC and the thumbnail

Block Typical fields Who writes it Privacy risk
EXIF (IFD0, ExifIFD) Make, Model, Software, DateTimeOriginal, OffsetTimeOriginal, LensModel, BodySerialNumber Camera or phone at capture Device fingerprinting, linking photos across accounts, timeline of your day
EXIF GPS IFD GPSLatitude, GPSLongitude, GPSAltitude, sometimes direction Phone with location enabled for the camera Home, office or school location
EXIF IFD1 thumbnail A small embedded JPEG preview Camera, phone, some editors Can show the original frame after you crop
XMP Creator, edit history, original file name, rating, keywords Lightroom, Photoshop, many editors Real name, workflow details, source file names
IPTC By-line, City, Country, Copyright, Caption Photo editors, newsroom tools Name and place written in plain text

Camera-specific MakerNotes can add more, such as internal serial numbers or lens data, in vendor formats that generic tools do not always display.

Real exiftool output from a tagged test file

To show exactly what a reader can pull out, I tagged a test JPEG with the kind of values a phone writes (the coordinates point at a public landmark in Karachi, not a home) and ran ExifTool 13.25 against it. This is the unedited output:

$ exiftool -G1 -a -s -Make -Model -SerialNumber -Software -DateTimeOriginal \
    -OffsetTimeOriginal -GPSPosition -GPSAltitude -ThumbnailImage -Creator -City IMG_4821.jpg
[IFD0]          Make                            : Apple
[IFD0]          Model                           : iPhone 14 Pro
[ExifIFD]       SerialNumber                    : DNPXK0QYLC
[IFD0]          Software                        : 17.5.1
[ExifIFD]       DateTimeOriginal                : 2026:10:18 21:42:07
[ExifIFD]       OffsetTimeOriginal              : +05:00
[Composite]     GPSPosition                     : 24 deg 50' 51.00" N, 67 deg 1' 58.80" E
[GPS]           GPSAltitude                     : 11.2 m
[Composite]     GPSAltitude                     : 11.2 m Above Sea Level
[IFD1]          ThumbnailImage                  : (Binary data 1741 bytes, use -b option to extract)
[XMP-dc]        Creator                         : Example Seller
[IPTC]          City                            : Karachi
Enter fullscreen mode Exit fullscreen mode

One more command turns that into something you can paste into any map:

$ exiftool -n -p '$GPSLatitude,$GPSLongitude' IMG_4821.jpg
24.8475,67.033
Enter fullscreen mode Exit fullscreen mode

Four decimal places of latitude is roughly ten metres of precision. That is a building, not a neighbourhood.

The cropped-thumbnail problem

Cropping does not necessarily remove the preview. I cropped the same file to a 1600x1200 region and copied the metadata across, which is what many editors and export pipelines do to "preserve" EXIF:

$ exiftool -s -ImageSize -ThumbnailImage -GPSPosition listing_crop.jpg
ImageSize                       : 1600x1200
ThumbnailImage                  : (Binary data 1741 bytes, use -b option to extract)
GPSPosition                     : 24 deg 50' 51.00" N, 67 deg 1' 58.80" E

$ exiftool -b -ThumbnailImage listing_crop.jpg > embedded_thumb.jpg
$ exiftool -s -ImageSize embedded_thumb.jpg
ImageSize                       : 160x120
Enter fullscreen mode Exit fullscreen mode

The visible image is the crop. The embedded 160x120 thumbnail is still the full 4032x3024 frame, including whatever you cropped out: a house number, a car plate, a reflection. Small, but often enough to identify a place.

A single red pushpin in a cork board, representing a precise location leaked through photo metadata

Threat scenarios that actually happen

  • Marketplace listings. Someone sells a sofa and photographs it in their living room. If the marketplace delivers the original file, or the seller emails the "full-size" photos to a buyer, the GPS block can resolve to the flat. The sofa is now an address and a time window when they are home.
  • Home location from routine posts. One photo is a data point; ten photos taken in the evening at the same coordinates are a home address. Personal blogs and self-hosted galleries often serve originals untouched.
  • Device linking. A pseudonymous account and a real-name account that both publish originals with the same BodySerialNumber can be linked without any GPS at all.
  • Document leaks. Screenshots and scans exported from editors can carry XMP with the author's name and the original file path or name.
  • Thumbnail recovery. As shown above, "I cropped it out" is not a guarantee.

Which platforms strip metadata? Test it yourself

I am deliberately not publishing a "platform X strips, platform Y keeps" table. Behaviour changes, differs between upload paths (feed post vs direct message vs "send as file"), and differs between the version shown to others and the copy the platform stores. What is safe to state:

Channel What to assume How to verify
Email attachment The original file bytes are delivered, metadata included Email the photo to yourself, download it, read it with an EXIF viewer
Cloud drive share link The original file is served Open the link in a private window, download, inspect
Chat apps, "send as photo" Often recompressed; metadata may be removed Send to a second account you own, save, inspect
Chat apps, "send as file/document" Usually the original file Same test as above
Social feeds and marketplaces Public copies are commonly stripped, but do not assume Upload a test image with known GPS, download the public copy, inspect
Your own website or CMS Whatever your upload pipeline does, often nothing Download the served image URL and inspect

The rule: never trust the channel, always test the file the recipient actually receives.

A browser-side verification workflow with PixelValut

Every step below runs in your browser, so the photo is not uploaded to a server for processing.

  1. Inspect the original. Open it in the PixelValut EXIF Viewer. Note GPS, make, model, serial, timestamps, thumbnail, IPTC and XMP.
  2. Strip it. Run the file through the PixelValut EXIF Remover. JPEG and PNG are rewritten without re-encoding, and batches download as a ZIP.
  3. Re-inspect the output. Load the stripped file back into the EXIF Viewer. You want no GPS block, no device fields and no ThumbnailImage.
  4. Confirm pixels are untouched. Compare original and stripped versions in the Image Diff Checker. A lossless strip should show no pixel changes.
  5. Check orientation. If the stripped photo appears rotated, the original relied on the EXIF Orientation tag. Rotate the pixels first, then strip.
  6. Test the delivery channel once. Send the cleaned file through the channel you plan to use and inspect what arrives.

The same "read what the recipient reads" discipline applies to hidden content inside pixels, which I covered in How to Hide a Secret Message Inside an Image.

For developers: strip on upload, and keep orientation

If your application accepts user photos, strip metadata server-side by default. In Node.js with sharp, output does not carry input metadata unless you opt in with withMetadata() or keepMetadata(); call rotate() first so EXIF orientation is baked into pixels:

import sharp from "sharp";

export async function sanitizeUpload(inputBuffer) {
  return sharp(inputBuffer)
    .rotate()              // apply EXIF Orientation to pixels
    .jpeg({ quality: 85 }) // re-encode; metadata is dropped by default
    .toBuffer();
}
Enter fullscreen mode Exit fullscreen mode

In PHP with Imagick:

$img = new Imagick($path);
// Bake EXIF orientation into pixels before stripping it
match ($img->getImageOrientation()) {
    Imagick::ORIENTATION_BOTTOMRIGHT => $img->rotateImage('#000', 180),
    Imagick::ORIENTATION_RIGHTTOP    => $img->rotateImage('#000', 90),
    Imagick::ORIENTATION_LEFTBOTTOM  => $img->rotateImage('#000', -90),
    default => null,
};
$img->setImageOrientation(Imagick::ORIENTATION_TOPLEFT);
$img->stripImage();   // removes EXIF, XMP, IPTC and profiles
$img->writeImage($cleanPath);
Enter fullscreen mode Exit fullscreen mode

For a lossless batch from the command line, keep only orientation:

exiftool -all= -tagsfromfile @ -Orientation -overwrite_original *.jpg
Enter fullscreen mode Exit fullscreen mode

Then add one integration test that uploads a fixture with GPS and asserts the served file has none. Pair it with the response-header checks from How to Audit HTTP Security Headers so served media cannot be sniffed or framed.

Pre-share checklist

  • [ ] Camera location access off for photos you plan to share
  • [ ] GPS, device, serial and thumbnail fields removed and re-verified
  • [ ] XMP and IPTC author fields cleared unless deliberately kept
  • [ ] Orientation baked into pixels before stripping
  • [ ] Delivery channel tested once with a known-tagged file

Frequently asked questions

Does taking a screenshot remove EXIF data?

A screenshot is a new image, so it does not carry the original photo's camera or GPS EXIF. It may carry its own metadata, such as the device and creation time, and it captures anything visible on screen. Inspect the screenshot file before sharing it.

Does turning off location in the camera app fix this?

It stops new photos from getting GPS tags, which is the biggest single improvement. It does not remove make, model, timestamps or editor metadata, and it does not clean photos already taken. Strip existing files before sharing them.

Is HEIC metadata different from JPEG metadata?

HEIC stores the same kinds of EXIF and XMP data in a different container. Many sharing flows convert HEIC to JPEG on export and may carry metadata across. Inspect the exported file, whatever its format.

Can metadata be faked?

Yes. EXIF fields are plain values anyone can rewrite with standard tools, which is how I built the test file above. Treat metadata as a leak risk for your own files and as weak evidence when judging someone else's.

Does stripping metadata reduce image quality?

Not if the tool removes metadata segments without re-encoding the pixels. Tools that re-encode, such as canvas exports or some converters, drop metadata as a side effect but recompress the image. Confirm with a pixel diff.

What should I keep?

For most sharing, nothing. Photographers may want copyright and creator fields; add them back deliberately, and keep GPS, serial numbers and thumbnails out.

Follow & Connect

Top comments (0)