What EXIF Data Reveals, and How to Strip It Properly

What is actually in the block

A JPEG stores metadata in APPn marker segments that sit before the compressed image data. The Exif block is a small TIFF structure with several directories. The first holds the device — make, model, orientation, the software that last wrote the file, sometimes an artist and a copyright line. A sub-directory holds the capture: DateTimeOriginal to the second, an offset field giving the time zone, a sub-second field, exposure time, aperture, ISO, focal length, lens make and model. Several manufacturers add a body or lens serial number, and almost all of them add a proprietary MakerNote blob whose contents are undocumented and can be substantial.

If location services were on, a third directory holds the GPS data: latitude and longitude with their hemisphere references, altitude, a UTC timestamp, often a compass bearing for the direction the lens was pointing, and on many phones a positioning-error field giving the device's own estimate of how far off it might be. Alongside all of that sits an XMP packet — an XML block that can carry keywords, ratings, an editing history, region tags naming faces, and the creator's contact details — plus a legacy IPTC block with caption, byline and place names, an ICC colour profile, and a small JPEG thumbnail in a directory of its own.

How precise the coordinates really are

Exif stores latitude and longitude as degrees, minutes and seconds, each written as a fraction. One degree of latitude is about 69.17 miles, so one arcminute is about 6,087 ft and one arcsecond about 101 ft. Because the seconds field is a fraction, the stored resolution depends on the denominator the device chose: a denominator of 100 records to roughly 12 in, a denominator of 1,000 to roughly 1.2 in. Longitude behaves the same way but shrinks with the cosine of the latitude — at 40 degrees north, one arcsecond of longitude spans about 78 ft rather than 101.

Do not confuse that stored resolution with accuracy. The file can hold a number precise to a fraction of an inch while the underlying satellite fix is several times coarser, and it is the fix that determines whether the coordinates point at a house or at the road outside it. That is exactly why the specification includes a positioning-error field, and why a responsible reading of a coordinate pair treats it as an area rather than a point. It remains specific enough to be a privacy question. A single holiday photo posted publicly rarely matters; a run of photos from one address, all carrying coordinates and timestamps, describes a routine.

Who strips it on upload, and why you should test rather than trust

Large platforms generally re-encode uploaded photographs, and re-encoding drops most metadata as a side effect rather than as a privacy feature. But behaviour varies by platform, and more importantly by the path the file takes within a single platform. The same messaging app that re-encodes a photo sent as a photo will transmit the original bytes untouched when the same file is sent as a document or a file attachment, because that path is explicitly designed to preserve the file exactly. Cloud storage links serve the original by definition. A content management system typically keeps the uploaded original alongside its resized derivatives, and while the derivatives are re-encoded, the original often remains reachable at its own URL.

Because these behaviours change without announcement, no published list stays correct for long, and this page is not going to give you one. The reliable procedure is a round trip: clean the file, upload it exactly as you normally would, download the copy the platform serves, and inspect that copy. Five minutes of testing on the path you actually use beats any table of platform behaviour, including a recent one.

What stripping does not do

Stripping metadata edits the header. It does not touch the picture, so everything visible in the picture survives it intact: a watermark, a face, a house number, a school badge on a jumper, a name on a delivery label, a distinctive skyline through a window. If the photograph itself identifies a person or a place, the fix is an edit to the pixels — a crop, a blur or a solid block — not a metadata operation. The two are often confused because both are offered as privacy features, and they solve entirely different problems.

The screenshot case illustrates this exactly. Photographing a screen, or taking a screenshot of a photo, produces a new file with no camera metadata at all — no coordinates, no capture timestamp, no device. It also reproduces every pixel of the original. The location data is gone; the recognisable street corner is not. A screenshot is a fine way to hand someone an image without its history, and a poor way to hide what the image shows.

Removal that only pretends to remove

Not every tool labelled as a metadata remover rewrites the file. Some blank the values of the tags they recognise and leave the directory structure in place, which defeats a casual viewer and nothing else. Some handle the standard Exif tags and skip the proprietary MakerNote or the XMP packet entirely, so the block that most reliably identifies a specific camera body is the one left behind. Some operate on a copy and leave the original in the same folder under a similar name, which is how a cleaned file and its uncleaned twin end up attached to the same message.

Conversion is not stripping either, and can work the other way. Converting a PNG that carried no camera metadata at all into a JPEG with a standard system tool produced an output file containing a brand-new 124-byte Exif block: five tags in the primary directory and three in the sub-directory, written by the converter itself. Nothing sensitive in that particular case, but it is a useful reminder that every tool in a pipeline gets to add its own annotations, and that the only way to know what a file carries is to open it and look.

Keeping metadata is often the right call

This is not an argument for deleting everything by reflex. Metadata is what lets a photo library sort by date, what makes a picture appear the right way up, what carries a photographer's copyright line, and what keeps a family archive legible in thirty years. Orientation in particular is worth protecting: strip it from a file whose pixels are stored rotated and the image will display on its side in anything that respects the tag.

The workable habit is therefore two files, not one blanket policy. Keep the original with its full metadata in your own storage, and produce a cleaned export for anything that leaves your control — a public post, a marketplace listing, a forum, an attachment to someone you do not know well. That way you never have to choose between a searchable archive and a photo you can publish without thinking about it.

Frequently asked questions

Does removing EXIF make the file noticeably smaller?

Hardly at all. Removing every metadata marker from our 5,617,703-byte test JPEG took out 1,344 bytes — 0.0239% of the file. Metadata cleaning is a privacy operation, not a compression one. If a tool claims a large size reduction while removing metadata, it is re-encoding the image as well, which is a different decision and costs image quality.

Does cropping a photo remove the location data?

Not by itself. Most editors carry the metadata across into the cropped file, coordinates included, because photographers expect it to survive editing. Worse, if the editor does not regenerate the embedded thumbnail, the cropped file can still contain a small copy of the uncropped picture. Crop, then strip, then re-inspect — in that order.

Can I turn off location tagging at the source instead?

Yes, and it is the cleaner solution for photos you already know you will share. Every current phone lets you deny the camera app access to location, and most share sheets also offer a per-share option to leave location out. Doing it at capture time means no coordinates ever exist in the file, so there is nothing to forget to remove later. The trade-off is that your own library loses its map.

Do PNG, WebP and HEIC carry metadata too?

Yes. PNG has an eXIf chunk plus textual chunks; WebP and AVIF have their own EXIF and XMP chunks inside the container; HEIC files from phones carry the same Exif structure a JPEG would, and often a burst of extra images besides. The habit of checking only JPEGs is a leftover from when JPEG was the only format anyone shared. Inspect whatever you are about to send, regardless of extension.

If a platform strips metadata anyway, why bother cleaning first?

Because the platform receives the original before it strips anything, because the stripping is a by-product of its processing rather than a promise, because you may forward the same file elsewhere later, and because the behaviour can change with the next release. Cleaning before you upload costs seconds and does not depend on anyone else's implementation staying the same.

Is there any legitimate reason to keep GPS data?

Several. A travel archive that can be browsed on a map is genuinely useful, field documentation and survey work depend on it, journalism and insurance claims often need it as evidence of where a picture was taken, and scientific photography treats it as part of the record. The judgement is contextual: keep it in your own storage, and decide deliberately for each file that leaves your control.