What your photos reveal: EXIF, GPS and stripping metadata before you share

A phone photo is two things: a grid of pixels, and a few kilobytes of structured data about how, when and where that grid was made. The second part is what this guide is about. By the end you will know which fields a typical photo carries, which sharing channels pass them on untouched, how to read and remove them without recompressing the picture, and the two traps — orientation and colour profiles — that catch people who strip blindly.

What a photo carries besides the pixels

Three families of metadata travel inside an image file. EXIFis the camera’s own record, laid out as a TIFF structure; in a JPEG it sits in an APP1 segment that begins with the bytes Exif\0\0, and it is capped at 65,533 bytes. XMPis Adobe’s RDF/XML block, also in an APP1 segment (this one starts http://ns.adobe.com/xap/1.0/), written by editors rather than cameras. IPTC is the older press-caption standard, carried in an APP13 segment labelled Photoshop 3.0. Two more blocks matter: the MakerNote, a vendor-private blob inside EXIF holding serial numbers and shutter counts, and the ICC colour profile in APP2 — not personal data, but removed by most strippers, with a visible consequence covered below.

The thumbnail deserves a closer look. The camera generates it at capture time, and an editor that rewrites the pixels but copies the APP1 block unchanged leaves the original thumbnail in place: crop a stranger out, blur a number plate, and the small version may still show both. One command checks: exiftool -b -ThumbnailImage photo.jpg > thumb.jpg.

Other containers hold the same data in different boxes: PNG in an eXIf chunk plus tEXt/iTXt text chunks, WebP in EXIF and XMP RIFF chunks, HEIC as an Exif item inside its meta box, with rotation in a separate irot property.

Where it leaks — and where it does not

The pattern: anything that treats your photo as a file keeps everything, and anything that treats it as a picture and re-encodes it drops the metadata as a side effect. The dangerous middle is every website with an upload form, where the answer depends on software you cannot see. If you did not strip it, assume it is there.

How to see what is in a file

Operating systems show a curated subset: Windows Explorer under Properties → Details, macOS Preview under Tools → Show Inspector (the ⓘ tab has a GPS sub-tab with a map), the Photos apps on iOS and Android behind the ⓘ button. None of them shows the MakerNote, the XMP history or the embedded thumbnail. For the full picture use exiftool:

# every tag, with its group and exact name
exiftool -a -G1 -s photo.jpg

# position as signed decimal degrees, ready for a map
exiftool -n -gpslatitude -gpslongitude -gpsdatetime photo.jpg

# the embedded thumbnail, as a file
exiftool -b -ThumbnailImage photo.jpg > thumb.jpg

# what follows the SOI marker?
xxd -l 4 photo.jpg
#   ffd8 ffe1  -> APP1 (EXIF or XMP) first, as cameras write it
#   ffd8 ffe0  -> JFIF first; an APP1 may still follow

Without a terminal, drop the file on the metadata remover. Before you press anything it reads each image and lists the four fields that matter most: a GPS marker (hover for coordinates to five decimal places, about a metre), camera make and model, the capture date (DateTimeOriginal, else CreateDate) and the Softwaretag. Read the green “No metadata found” precisely: none of those four was present, not zero tags — an XMP DocumentID or an IPTC caption would not show, though the strip step removes them too.

How to remove it

In the browser, without recompressing

When we built the remover we chose to clean JPEGs by segment rather than by re-encoding. A JPEG is a list of marker segments — FF D8 start of image, FF E0 JFIF, FF DB quantisation tables, FF C4 Huffman tables, FF C0 frame header, FF DA start of scan followed by the compressed pixels. The tool keeps the structural segments and the scan verbatim and drops FF E1 through FF EF (every APP1–APP15 block: EXIF, XMP, IPTC, MakerNote, thumbnail) plus FF FE comments. The pixels are byte-for-byte what the camera wrote. It takes any number of files and returns one cleaned file under the same name, or cleaned-images.zipfor several, confirming with “Cleaned 3 images — download started.” Cleaning happens inside the tab, which matters for exactly this task: uploading a photo somewhere to hide where it was taken defeats the point.

Two consequences follow. First, APP2 goes too, and that is where the ICC colour profile lives: a modern iPhone JPEG is tagged Display P3, a DSLR may be set to Adobe RGB, and without the profile viewers assume sRGB, so saturated reds and greens come out slightly duller. For a marketplace listing nobody will notice; for a portfolio, keep the profile with the exiftool form below. Second, the Orientation tag goes with everything else — the next section is about that.

Non-JPEG inputs take a different path: the browser decodes the file, draws it onto a canvas and re-encodes it, which by construction carries no metadata. WebP comes back as WebP and everything else as PNG, so an animated GIF becomes a single frame, and a TIFF or HEIC, which browsers cannot decode, fails with “Could not process: photo.heic”. Convert those first.

With exiftool

# everything (without -overwrite_original you also get photo.jpg_original next to it)
exiftool -all= -overwrite_original photo.jpg

# location only
exiftool -gps:all= -overwrite_original photo.jpg

# everything except the colour profile and the rotation tag; -P keeps the modification time
exiftool -all= --icc_profile:all -tagsfromfile @ -orientation -P -overwrite_original photo.jpg

# verify: no IFD0:, ExifIFD:, GPS:, XMP-*: or IPTC: group should be listed any more
exiftool -a -G1 -s photo.jpg

-all= is lossless on JPEGs too — exiftool rewrites segments, never pixels — and it also handles PNG, WebP, HEIC and RAW.

By re-exporting through an editor

Any tool that renders the picture to a canvas and saves the result produces a metadata-free file, because a canvas has no EXIF to give. The site’s image compressoris one: the photo opens in an editor and Save writes a fresh JPG, PNG or WebP from the rendered pixels, with a 1–100 quality slider for JPG and WebP, a “Max file size (KB, optional)” field that searches the quality between 5% and 97% (stepping the dimensions down by a quarter at a time if even that is too big) and a pre-checked “Compress image” tick that encodes at quality 72 with the long edge capped at 2560 px. This route is lossy, so use it when you wanted a smaller file anyway — the compression guide explains how far to push it.

The orientation trap

Phones do not rotate pixels. A portrait shot is stored the way the sensor saw it — landscape — with Orientation set to 6 (rotate 90° clockwise to display) or 8 (rotate 270°); 3 is upside down and 1 needs nothing. Every viewer honours the tag, so you never notice — until you strip it without touching the pixels and the same photo lies on its side everywhere. This applies to the segment path above: the remover drops the tag and leaves the pixels alone, so a portrait JPEG that relied on it comes out sideways. Three fixes:

# 1. lossless: rotate the DCT blocks and drop all markers, no recompression
exiftool -Orientation -n photo.jpg          # 6 -> rotate 90, 8 -> rotate 270, 3 -> rotate 180
jpegtran -rotate 90 -perfect -copy none photo.jpg > upright.jpg
#   "jpegtran: transformation is not perfect" = edges not a multiple of the 8/16 px block;
#   drop -perfect to trim a few edge pixels

# 2. lossy but simple: bake the rotation and strip in one go
magick photo.jpg -auto-orient -strip -quality 92 upright.jpg

# 3. keep just the tag (it says "rotate", nothing about you)
exiftool -all= -tagsfromfile @ -orientation -overwrite_original photo.jpg

The editor route sidesteps the problem: current browsers apply the Orientation tag when they decode a JPEG for display, so the picture opens upright in the compressor and the saved pixels are already rotated. If a batch must stay lossless, run option 1 on every file exiftool reports as anything other than 1, then strip.

HEIC photos: convert, then check

An iPhone HEIC carries a full EXIF block — GPS, timestamps, model, lens — and exiftoolreads it as it reads a JPEG. What survives conversion depends on the converter: ImageMagick’s magick photo.heic photo.jpgcopies the EXIF across, and desktop exporters generally do the same unless they offer a “remove location” option. The last tool to touch the file decides, so the order is convert, then strip, then verify.

The site’s HEIC to JPG converter makes the strip step unnecessary. It decodes the HEIC with libheif into a PNG, draws that onto a canvas and encodes the JPG from there, so nothing from the original EXIF survives — no GPS, no date, no device — and because libheif applies the irotrotation while decoding, the JPG comes out upright with no Orientation tag to lose. One photo opens in the editor for a crop or rotation before saving; several offer “Convert all to JPG (ZIP)” (quality 92 by default, with the same optional KB cap and compress tick, delivered as converted-jpg.zip) or editing each in turn. “Could not read this HEIC photo” means a variant libheif does not know; “The HEIC engine did not load — reload the page and try again” means the decoder never arrived. Either way, finish by dropping the JPG on the remover and expect “No metadata found”. The date goes too, so keep the HEIC if you care when it was taken. The HEIC guide covers the format itself.

What stripping does not do

Metadata removal cleans the container, not the picture. The pixels still show street signs, house numbers, a school uniform, a parcel label, a Wi-Fi network name on a screen, a reflection in sunglasses, and shadows that give away the time of day. Two subtler channels survive too: the file name (IMG_4821.jpg places a photo in a sequence, and some Android cameras name files with the full timestamp, 20260906_141522.jpg), and sensor pattern noise, which forensic tools can match to a specific camera across photos. Rename the file, and review the pixels separately.

Common mistakes

• Stripping before rotating. The sideways-photo problem above. Check exiftool -Orientation -n first, or export through an editor.
• Trusting a rename. The remover picks the lossless path by extension or MIME type; a PNG renamed .jpg does not start with FF D8, so the segment walker passes it through untouched, text chunks and all. xxd -l 2 file.jpg settles what it is.
• Cleaning a copy, sharing the original. The cleaned download is a separate file; the photo in your camera roll still has its GPS, and any link created from a synced library carries it.
• Zipping the backup. Without -overwrite_original, exiftool leaves photo.jpg_original beside the cleaned file, and it is easy to select both when you zip the folder.
• Cropping and assuming. Editors that preserve the EXIF block when you crop or blur also preserve the original thumbnail. Run the -ThumbnailImage extraction, or strip after editing.