iKit
Technical · 9 min read ·

EXIF Stripping: Why Re-encoding Drops GPS Data (2026)

EXIF stripping happens automatically when you re-encode an image — convert or compress a photo and its GPS coordinates and camera data vanish. Here's why.

EXIF Stripping: Why Re-encoding Drops GPS Data (2026)

EXIF Stripping: Why Re-encoding Drops GPS Data

Every photo your phone takes carries a hidden passenger: an EXIF block that often records the exact GPS coordinates of where you were standing. Post that file somewhere that doesn't scrub it and you've published your location. The fastest accidental fix is also the most common — EXIF stripping happens as a side effect whenever you re-encode an image. Convert a JPG to PNG or run it through a compressor and the metadata usually disappears.

TL;DR

  • Phone cameras write GPS, timestamp, and device data into a photo's EXIF block.
  • Re-encoding an image rebuilds it from raw pixels, so most encoders drop EXIF.
  • Format conversion (JPG→PNG, JPEG→WebP) is the most reliable accidental strip.
  • Re-encoding also recompresses pixels — lossless metadata removal keeps them intact.
  • PNG and WebP can carry GPS too, so don't assume a converted file is clean.

Where your location actually lives in a photo

Before you can strip something, it helps to know exactly where it sits. The location data in a photo isn't in the pixels — it's in a structured metadata block bolted onto the front of the file.

What EXIF is and what it stores

EXIF (Exchangeable Image File Format) is the standard your camera uses to annotate each shot. The current specification is CIPA DC-008, maintained by the Camera & Imaging Products Association. It defines fields for shutter speed, ISO, lens focal length, the capture timestamp, the camera make and model, and — the field that matters for privacy — a dedicated GPS Information IFD holding latitude, longitude, and altitude.

In a JPEG, all of that lives in the APP1 application segment, which begins with the marker bytes 0xFFE1. Per the Exif spec, APP1 holds what is effectively an entire little TIFF file, and its total size cannot exceed 64 KB. That's the block re-encoding throws away.

How GPS coordinates get written in the first place

You rarely add location data on purpose. iOS and Android write it automatically when location services are enabled for the camera. Each photo records latitude and longitude accurate to a few meters, plus a timestamp. The data is invisible in any normal image viewer, which is exactly why it surprises people.

The classic cautionary tale

The textbook example is from 2012, when VICE published a photo of fugitive John McAfee taken on an iPhone 4S with its EXIF intact. Readers pulled the GPS tags straight out of the file and pinpointed him to a location in Guatemala, which he later confirmed. One un-stripped photo undid weeks of hiding. The lesson holds in 2026: metadata travels with the file unless something removes it.

Does converting an image remove EXIF data?

This is the question most people actually type into Google, so let's answer it directly. In the overwhelming majority of cases, yes — converting an image between formats removes the EXIF block, including GPS.

Why a format change rebuilds the file

A converter doesn't edit your existing file in place. It decodes the source into a raw, uncompressed bitmap in memory, then runs a fresh encoder to write a brand-new file in the target format. EXIF is not pixel data, so it never enters the bitmap. Unless the converter goes out of its way to read the original metadata and re-inject it, the new file is born clean.

You can see this most clearly in browser-based tools. The pipeline is decode → draw to canvas → re-encode:

// Decode the source into a bitmap
const img = await createImageBitmap(file);

// Draw raw pixels onto a canvas
const canvas = new OffscreenCanvas(img.width, img.height);
canvas.getContext('2d').drawImage(img, 0, 0);

// Re-encode — the new Blob has NO EXIF block
const out = await canvas.convertToBlob({ type: 'image/webp' });

Per MDN, canvas.toBlob() and convertToBlob() "create a Blob object representing the image contained in the canvas." That blob is generated from canvas pixels only — there is no EXIF input, so there's no EXIF output. Browser image converters that run on a <canvas> strip metadata as an unavoidable consequence of how they work.

When conversion does NOT strip metadata

Conversion is reliable but not universal. Watch for these cases:

  • Desktop apps that preserve metadata on export. Lightroom and Photoshop can deliberately copy EXIF (and a separate XMP block) into the output, including a JPEG→PNG export.
  • Command-line tools with copy flags. ImageMagick, ffmpeg, and exiftool can be told to carry metadata forward.
  • "Edit" features that re-attach orientation. Some libraries re-read the source EXIF to fix rotation and write part of it back.

If your goal is privacy, verify the output rather than assuming. Open the converted file in any metadata viewer and confirm the GPS block is gone.

How to remove GPS location from a photo

There are two clean ways to do this, and the right one depends on whether you care about pixel quality.

Re-encode the image (the side-effect method)

The simplest route is to push the photo through any tool that re-encodes it. Convert the format with an in-browser image converter — JPG to PNG, or JPEG to WebP — and the EXIF block won't survive the round trip. The same thing happens when you run a photo through a client-side image compressor: the recompression step rebuilds the file from pixels and leaves the metadata behind. Resizing has the identical effect; an image resizer that draws to a canvas produces a metadata-free file.

The trade-off: re-encoding recompresses your pixels. A JPEG→JPEG pass adds a generation of lossy compression, and even JPEG→PNG re-derives the bitmap. For most web-sharing use cases the quality cost is invisible, but it isn't truly lossless.

Strip metadata losslessly (pixels untouched)

If you want the metadata gone but every pixel byte preserved, you don't re-encode at all. A lossless metadata remover walks the file's structure and deletes only the metadata segments — for JPEG that means dropping the APP1 (EXIF), APP13 (IPTC), and APP14 segments while leaving the compressed image data exactly as it was. The pixels never get decoded or recompressed.

# Lossless EXIF removal with exiftool — pixels untouched
exiftool -all= -overwrite_original photo.jpg

# Verify nothing remains
exiftool -gps:all -make -model photo.jpg

Choose lossless when archiving originals or working with already-optimized images; choose re-encoding when you were going to convert or compress anyway.

Verify the strip worked

Never trust a strip you haven't checked. The fastest verification is to re-open the file in a viewer and confirm the GPS and camera fields read empty. With exiftool the -gps:all query above returns nothing on a clean file. Treat verification as mandatory, not optional — a half-stripped file is the most dangerous kind because you believe it's safe.

What metadata survives a format conversion?

"Strips EXIF" is a useful shorthand, but different formats and pipelines behave differently. Here's what actually carries over.

Format-by-format behavior

Conversion EXIF / GPS result
JPEG → PNG (browser) Dropped — clean output
JPEG → WebP (browser) Dropped — clean output
JPEG → JPEG (recompress) Dropped on canvas re-encode
Lightroom/PS "export with metadata" Preserved if option enabled

The pattern: any canvas-based or pixel-only pipeline drops EXIF, while desktop "export" dialogs may preserve it on purpose. When in doubt, the browser tool is the more private default.

Don't assume PNG and WebP are automatically clean

A common myth is that PNG can't hold location data. It can. Since the PNG Third Edition became a W3C Recommendation in 2025, the dedicated eXIf chunk officially stores EXIF — including GPS — in the same binary layout JPEG uses in APP1. A share-sheet conversion from a phone or a Lightroom PNG export can embed a full GPS block inside that chunk. WebP likewise has an EXIF chunk. So "I converted it to PNG" is not, by itself, proof the location is gone. The protection comes from the re-encode dropping the block, not from the target format being incapable of holding it.

Orientation: the one tag you might miss

There's a small catch worth knowing. EXIF also stores an Orientation tag that tells viewers to rotate the image. When a tool strips all EXIF, it must "bake" that rotation into the pixels first, or the output appears sideways. Good converters apply orientation before stripping. If a stripped photo comes out rotated, the tool dropped the tag without baking it — re-run it through a converter that handles orientation correctly.

Why client-side stripping beats upload-based tools

The privacy math here is simple, and it's the whole reason iKit's image tools run in your browser.

Server tools see the very data you're trying to hide

When you upload a photo to a "remove EXIF online" service, the original file — GPS coordinates and all — travels to someone else's server before anything gets stripped. You've handed your exact location to a third party to ask them to delete it. That's backwards. A client-side tool decodes, re-encodes, and strips entirely in the browser tab; the un-stripped original never leaves your device.

What "no upload" actually buys you

  • The GPS-bearing original stays on your machine, full stop.
  • No server logs, no retention policy to read, no breach to worry about.
  • It works offline, because all the work happens in the page.
  • Batch jobs don't multiply your exposure across dozens of uploads.

For something as sensitive as your home or location history, "the file never left" is a stronger guarantee than any privacy policy.

References

Related on iKit

Related posts