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
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, andexiftoolcan 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
- CIPA DC-008-2019 — Exchangeable image file format for digital still cameras: Exif Version 2.32 — primary Exif spec; cited for the APP1 segment marker, 64 KB limit, and GPS Information IFD.
- MDN: HTMLCanvasElement.toBlob() — confirms canvas re-encode produces a blob from pixels only, with no metadata input.
- PNG Specification (Third Edition) is now a W3C Recommendation — 2025 status of PNG's eXIf chunk that can carry GPS.
- Betrayed By Metadata: John McAfee Admits He's Really In Guatemala — NPR — the 2012 EXIF location-leak case used as a cautionary example.
Related on iKit
- Convert between JPG, PNG, and WebP without uploading a thing — the converter whose re-encode step strips EXIF as a side effect; the practical tool behind this article.
- How to batch convert 50 images at once, browser-only — batch conversion re-encodes every file, so it scrubs metadata across a whole folder in one pass.
- PNG vs JPG vs WebP vs AVIF: which format to pick in 2026 — picking the target format for the conversion that does your EXIF stripping.
- How to convert JPG to PNG (and when you shouldn't) — a JPG→PNG pass is one of the cleanest accidental EXIF strips.
- Convert PNG to WebP and cut image size 30% — re-encoding to WebP both shrinks the file and drops the metadata block.
- Compress PNG images without losing quality — recompression rebuilds the file from pixels, leaving EXIF behind.
Related posts
Ignore Whitespace in Git Diff: When It Hides Bugs (2026)
Ignore whitespace in a diff and you cut formatting noise — but the same flag can hide real bugs in Python, YAML, and Makefiles. Here's when to use it.
Side-by-Side vs Unified Diff: How to Compare Text (2026)
Side-by-side and unified diff show the same edits two ways. Learn how each format reads, what the @@ hunk header means, and when to pick which.
Regex Capture Groups Explained: $1, $&, and $<name> (2026)
Understand regex capture groups, backreferences, and the $1, $&, and $<name> replacement tokens — with copy-paste JavaScript examples that actually work.