Image EXIF and Privacy: What Your Photos Carry, and How to Strip It

A friend once sold a piece of furniture on a local marketplace by posting four photos taken on her phone. Within an hour she got a message from a stranger asking why she didn't want him to come pick it up "at the address in the photos". The photos showed her empty living room. The address was in the EXIF: latitude, longitude, time of capture, even the device serial number. None of it was visible in the image itself, all of it was sitting in the file header for anyone who knew where to look. She took the listing down. That afternoon was the start of me asking, on every project that accepts user-uploaded photos, what the default policy is for stripping metadata.

Every photo from a modern phone or camera carries a metadata block called EXIF (Exchangeable Image File Format). Most of the time nobody cares. The cases when it matters — sharing photos publicly, journalism with vulnerable sources, web apps that accept user uploads — are the cases worth knowing about. This guide walks through what EXIF actually contains, when it leaks something dangerous, when it is useful, and how to strip it cleanly across platforms.

What lives inside an EXIF block

EXIF was originally a Japanese camera-industry standard from 1995, designed to embed capture settings alongside the image so that photo editing software could read them back. JPEG, TIFF, HEIC, and some PNG variants all support EXIF blocks. The current spec is EXIF 2.32; in practice every camera manufacturer extends it with their own makernote tags, so a single file can carry hundreds of fields.

A representative dump of EXIF from a recent iPhone photo looks like this (trimmed for the ones most people would not expect):

Make                            : Apple
Model                           : iPhone 15 Pro
Lens Model                      : iPhone 15 Pro back triple camera 6.86mm f/1.78
Software                        : 17.4.1
Date/Time Original              : 2026:04:18 15:42:11
Sub Sec Time Original           : 314
Offset Time                     : +09:00

GPS Latitude                    : 37 deg 33' 54.12" N
GPS Longitude                   : 126 deg 58' 33.84" E
GPS Altitude                    : 18.4 m Above Sea Level
GPS Speed                       : 0.6 km/h
GPS Img Direction               : 187.4 deg
GPS Dest Bearing                : 187.4 deg
GPS Horizontal Positioning Error: 4.8 m

Exposure Time                   : 1/120
F Number                        : 1.78
ISO                             : 64
Focal Length                    : 6.9 mm
Focal Length In 35mm Format     : 24 mm

Composite Image                 : General Composite Image
Run Time Value                  : 2841392 (since boot)

Three groups of fields tend to matter for privacy. Location (GPS coordinates, altitude, speed, direction) is the obvious one. Device identifiers (Make, Model, Lens Model, Software version, sometimes a Camera Serial Number on dedicated cameras) build a fingerprint that ties multiple photos to the same physical device. Timestamps (capture time, sub-second precision, time-zone offset) reveal when and roughly where the photo was taken, even without GPS, because the offset narrows the time zone to a few candidates.

For a quick interactive view of what any one photo carries, BeautiCode's EXIF viewer parses files in your browser using the exifr library; the photo never leaves the tab, so it is safe to inspect sensitive files there before you decide what to do with them.

When EXIF actually matters

Most photos posted on the open internet do not need to retain location data. The cases where preserving it causes real harm are narrower than people assume, but each one is worth recognising before you ship a default.

Photos of your home (or someone else's)

Marketplace listings, room-share posts, real estate ads, and pet adoption photos all regularly carry the seller's home GPS in the metadata. The image shows a couch in a generic room; the EXIF shows the exact street corner. Anyone who downloads the photo and runs exiftool against it has the location in seconds. This is the most common "why my photo had my home address" complaint.

Journalism and source protection

When a source sends a photo to a journalist, the device fingerprint and capture location are the two pieces of information a state actor or hostile party would most want to recover. Newsrooms with serious operational security pipelines explicitly strip EXIF (and re-encode the image to break any residual steganographic markers) before publishing. The risk here is not theoretical; specific de-anonymisation cases have turned on GPS coordinates left in supposedly anonymous photos.

User-uploaded content in web apps

Profile pictures, support-ticket attachments, comment images — anywhere your app accepts a photo from a user and serves it back publicly, you are republishing whatever EXIF the original carried. The user expectation is almost always "the platform strips this". Many platforms do (Facebook and Twitter strip aggressively; Instagram strips most but not all; Discord strips on the upload path; Slack preserves in some cases). If you run a smaller app, you have to decide explicitly.

Forensic verification

EXIF can also be a signal you actively want. When verifying that a photo was taken at a claimed time and place (insurance claims, news desk verification, on-site contractor reports), the timestamps and GPS are part of the evidence. Stripping them defeats the verification. The right call depends on whose interest is being served by the metadata.

When EXIF helps (and you want to keep it)

The same data that looks like a privacy hole in a marketplace listing is the backbone of professional photography workflows.

• Photographer cataloguing: Lightroom, Capture One, and Darktable index entire libraries by camera body, lens, focal length, and date. Strip the EXIF and you lose every smart album.
• Contest and stock submissions: most photo contests require unmodified EXIF as evidence of capture device and settings. Re-encoding the file or stripping metadata disqualifies the entry.
• Insurance and field reports: timestamps and GPS coordinates are the proof that a claim photo was taken on-site at the relevant time. Carriers increasingly require this in mobile claim apps.
• Geotag map workflows: pulling photos onto a map for a trip log or archaeological survey is built on the GPS field. Worth keeping for personal archives.

The pattern that resolves the tension is to keep the original and strip the copy. Save the original file with full EXIF in your local archive, and strip metadata only on the export that gets shared. Most desktop photo tools have an explicit "export without metadata" toggle for exactly this reason.

How to strip EXIF: browser, mobile, CLI, server

There are four contexts where stripping happens, each with its own toolset.

In the browser

Re-encoding an image through a <canvas> automatically drops the EXIF, because canvas only encodes pixel data and standard image headers — the entire metadata block is left behind. This is the simplest way to strip metadata client-side before uploading.

// Strip EXIF in the browser by round-tripping through canvas
async function stripExif(file) {
  const img = await createImageBitmap(file);
  const canvas = new OffscreenCanvas(img.width, img.height);
  const ctx = canvas.getContext('2d');
  ctx.drawImage(img, 0, 0);
  // The new blob has no EXIF — canvas does not preserve metadata
  return await canvas.convertToBlob({ type: 'image/jpeg', quality: 0.92 });
}

// Usage in a file input handler
input.addEventListener('change', async (e) => {
  const original = e.target.files[0];
  const stripped = await stripExif(original);
  // Upload the stripped blob instead of the original file
});

Two caveats. The re-encode is lossy if you target JPEG; pick a quality value the user is happy with, or convert to PNG/WebP if losslessness matters. And the orientation flag in the original EXIF is what tells browsers to rotate sideways photos; once you strip it, you need to bake the rotation into the pixel data before encoding, or the photo will display the wrong way up.

On iOS and Android

Both mobile OSes now have a per-app toggle for whether photo location data is shared.

• iOS 14+: Settings → Privacy & Security → Location Services → (pick the app) → toggle "Precise Location" off, or use the share sheet's "Options" → Location → Off when sending a specific photo.
• Android 13+: Camera app → Settings → Save location → Off (varies by manufacturer; the gallery app's share menu also has a per-share toggle on Pixel and Samsung devices).

The catch with both is that the toggle only affects new captures (or specific shares). Photos already in the camera roll keep their EXIF until you re-export or run a scrubber over them.

Command line

For batch jobs and server work, exiftool(Phil Harvey's Perl tool) is the canonical choice. It reads and writes almost every metadata standard ever shipped, and the strip-everything invocation is one line.

# Remove all metadata from a single file (writes in place; backs up to .original)
exiftool -all= image.jpg

# Same, but keep ICC color profile and orientation (sane default for web)
exiftool -all= -tagsfromfile @ -ICC_Profile -Orientation image.jpg

# Recursive batch over a folder, no backups
exiftool -all= -overwrite_original -r ./photos

# Strip GPS but keep camera and exposure data (photographer workflow)
exiftool -gps:all= image.jpg

ImageMagick's convert -strip and mogrify -strip work for the "remove everything" case as well, and they are usually already on a Linux server. Python's Pillow exposes the same via image.save(out, exif=b''); the empty exif argument writes a header with no fields.

Server-side resize as a side effect

Most server-side image pipelines that resize uploads also drop EXIF as a side effect, because the resize library decodes pixels and re-encodes a fresh file. If you already run uploads through sharp, ImageMagick, or a CDN-side transformer, EXIF is probably already gone before the file reaches your storage bucket. Worth confirming once with a test upload before relying on it.

For browser-side compression that also handles the strip (and is convenient to test on a single file), the image compressor and format converter both run client-side and produce output without the original EXIF, because they round-trip through the canvas the same way the snippet above does.

Verifying the strip actually worked

The silent failure mode of metadata stripping is "I thought I removed it". Common cases where partial metadata survives:

• A tool removes EXIF but preserves IPTC and XMP, which can carry the same data (location, author, copyright) in a different block. exiftool -all= removes all three; -exif:all= alone does not.
• The image has an embedded thumbnail that carries its own (smaller, but still identifying) EXIF block. Some libraries strip the main EXIF and leave the thumbnail intact.
• PNG files have a tEXtchunk that can store arbitrary key-value pairs, including software-injected location data. A JPEG-targeted strip won't touch it.
• HEIC containers can store multiple representations of the same image; tools that understand HEIC partially may strip the primary block but miss alternates.

The verification step is to open the stripped file in a tool that reads every metadata block, not just EXIF, and confirm it is empty. exiftool -a -u -g1 stripped.jpg dumps everything including unknown tags grouped by family; anything sensitive that comes back means the strip missed a layer.

BeautiCode's EXIF viewer is the quick sanity check on a single file: drag the stripped version in and confirm the fields you cared about are gone. The check runs locally, so the file does not round-trip through any server during verification.

A default policy for user-uploaded photos

For a web app that accepts photos from users and serves them back publicly, a reasonable default looks like this:

• Strip on the upload path by default.The user's reasonable expectation is that you handle this; the cost of stripping is a few milliseconds; the cost of not stripping is a doxing incident.
• Keep orientation correct. Bake the EXIF orientation flag into the pixel data before stripping, so the photo displays right-side up.
• Keep ICC color profile. For photo-quality output, removing the color profile shifts colours noticeably on wide-gamut displays. Strip everything except this and orientation.
• Offer an opt-in to keep metadatafor users who explicitly want it (photo communities, contest submissions). A "keep camera info" toggle is fine; a "keep GPS" toggle should be a separate, clearly-labelled option.
• Verify in tests. An integration test that uploads a known-EXIF photo and asserts the served version has no GPS is the only way to catch a regression in your image pipeline before users do.

Wrap up

EXIF is one of those technologies that quietly grew into a privacy concern because the context around it changed. In 1995 it was a way for a camera to label its own photos; in 2026 it is a piece of metadata that travels with every casual phone snap. The fix is not to ban it — there are perfectly good reasons to keep it for personal archives — but to make stripping the default for shared copies, and to verify the strip actually worked rather than assuming.

Inspect any file you are about to share with the EXIF viewer first. Strip the metadata at the boundary where the file leaves your control. Keep the original for yourself when you want the camera data later.