What you lose when you strip photo metadata

Why this is a different question from the rest of the site

Most privacy pages reason about exposure: if this field escapes, who can use it against me. That reasoning only ever points one way, which is why a site full of such pages can leave you with the impression that metadata is pure downside. A cost question behaves differently. It asks what reads this file after you, and what that reader will do when the field it wanted is missing. The answer is sometimes nothing and sometimes a broken workflow you will not notice for a year.

It is also a different question from whether stripping damages the picture. That one has a narrow technical answer — tags live outside the pixel data, so deleting them does not soften or blockify anything, and visible degradation comes from a re-encode rather than from the deletion. The costs on this page are not about pixels at all. They are about the instructions, labels and evidence that travel with the file, and about the fact that deleting them is a one-way operation on that copy.

What is actually inside the block you are about to delete

It helps to see the inventory, because "metadata" is a single word covering at least six unrelated kinds of information:

• When. The capture date and time, often with sub-second precision and a time-zone offset. This is what photo libraries sort by.
• Where. Latitude, longitude, sometimes altitude and a compass bearing. This is what puts a photo on a map and what most people are trying to delete.
• Display instructions. The orientation flag that tells a viewer to rotate a sideways frame upright, the embedded colour profile that says what the numbers in the pixels mean, and a resolution or density value that print software reads as a default print size.
• How it was made. Camera body, lens, focal length, aperture, shutter, ISO, plus a manufacturer-specific block that can carry lens-correction hints and shooting-mode details the maker's own software knows how to use.
• Who and what. IPTC and XMP fields for creator, credit, copyright notice, usage terms, caption, keywords and region tags naming the people in the frame.
• History and companions. Editing software and edit history, provenance assertions, and references that tie an image to a depth map, a burst, a motion clip or a bracketed set.

One thing to be clear about before the list below: a tool that strips by rebuilding the image — which is how this site's tool works, and how screenshotting and most gallery re-saves work too — removes all six categories at once. There is no setting that keeps the credit line and drops the coordinates. That is a feature for simplicity and a limitation for anyone who wanted surgery rather than amputation.

The seven things that actually stop working

1. Chronology, and therefore every album you ever sort by date. Photo libraries read the embedded capture time first. Strip it and most of them fall back to file system dates, which are not a record of when the picture was taken — they change when the file is copied, synced, restored from a backup or re-saved. A folder of cleaned holiday photos can arrive in your library dated the afternoon you cleaned them, interleaved in the wrong year, and putting that right usually means editing dates by hand, one file at a time.
2. Maps and location features — while not actually guaranteeing the service has no location for the photo. This one cuts in two directions at once. Losing the coordinates means losing the map view and place-based search for your own archive. But stripping them does not necessarily leave the platform ignorant: Google's own documentation for Photos says a photo may have a location if the camera saved one or you added one, and that Photos "also estimates your location from information such as landmarks and locations in your other photos". The same page says you can only change or remove estimated locations and ones you added manually — a location that a camera wrote in cannot be edited or removed inside Photos. So the field you wanted gone may be inferred back for your eyes, and the field you wanted to keep may be impossible to remove later. Strip before the file reaches the service, not after.
3. Print size and colour fidelity, when the strip is a rebuild. The HTML specification requires that when a canvas is serialised to a file, resolution metadata — where the format supports it — "must be given as 96dpi (one image pixel per CSS pixel)". A camera or editor may have written a different density, and a print service reading it will now see the generic one, so the default print dimensions it offers can change even though the pixel count has not. The same specification defaults a 2D canvas to the sRGB colour space and notes that round-tripping through it can clip colours "to a more narrow gamut", which is the mechanism behind a wide-gamut original looking a little flatter after a browser-side clean. The display-instruction side of this, including sideways photos and missing profiles, is covered in detail in does stripping EXIF affect photo orientation or color profile.
4. Your credit line, and your ability to object when it is missing. If you licence or sell images, the creator, copyright and usage-terms fields are the machine-readable version of your name on the work. Strip them from your own delivery files and you have removed the thing that travels with the picture when somebody re-posts it. There is a second, sharper version of this for files that are not yours. In United States copyright law, 17 U.S.C. 1202(b) says that no person shall, without the authority of the copyright owner or the law, "intentionally remove or alter any copyright management information", or distribute works knowing that such information has been removed, where they know or have reasonable grounds to know that it will "induce, enable, facilitate, or conceal an infringement". Section 1202(c) defines that information to include the title, the author's name and identifying information, the copyright owner, and "terms and conditions for use of the work" — in other words, the contents of a typical rights block. Cleaning your own photos is not what that provision is aimed at; routinely scrubbing other people's before republishing them is a different matter, and a question for a lawyer rather than a tool.
5. Proof of when and where, exactly when you need it most. Warranty claims, insurance claims, damage disputes, rental deposits, contest entries and anything that becomes evidence all benefit from a file whose own header says when the shutter fired. Metadata is not proof — it is editable, and a careful reader treats it as a claim rather than a fact — but an empty header invites the question of what else was changed, and a blanket strip-everything rule can destroy information you were obliged to preserve. Anything that has become evidence should be copied out of the routine cleaning path and left alone.
6. Editing features that read the header rather than the pixels. Raw and hybrid workflows lean on metadata more than people realise: lens-correction and develop settings, the pairing between a still and its motion clip, the depth or portrait data behind a background blur, and the grouping of a bracketed or panoramic set. Rebuild the file and you get a flat bitmap, correctly, which is the point — but the non-destructive edit you were planning to revisit next month is no longer attached to anything.
7. Platforms and projects that expect the fields to be there. Nature and field-observation sites, mapping projects, some stock agencies, some news desks and plenty of internal document workflows read the embedded date, coordinates, caption or keywords when you submit a file, and treat a bare header as an incomplete submission. Behaviour varies by platform and changes without notice, so check what the recipient reads before you clean a batch for them rather than after.

The rule that makes the trade-off disappear

Nearly every conflict above dissolves once you stop treating "the photo" as one file. The costs land on you only when the stripped copy is the only copy.

1. Name the recipient before you clean anything. A stranger on a forum, a client, a print lab, an insurer and your own archive want different files. "Clean everything by default" is a policy for outbound copies, not for masters.
2. Ask what reads this file next. If the answer involves a date, a place, a credit or a colour-managed print, the field in question is not overhead.
3. Keep one untouched master outside the cleaning path. A separate folder, drive or album that your cleaning and sharing habits never touch. This is the entire backup for every field you are about to delete.
4. Strip the derivative, not the original. Export or copy first, clean the copy, send the copy. The tool here helps with this by writing its output to a new file with -metadatawipe appended and leaving the file you selected alone.
5. Re-attach what the recipient legitimately needs in the message, not the header. A caption, a credit line, a date and a licence note in the email or the listing body give the reader the facts without re-attaching a device serial and a house location.
6. Quarantine anything that has become evidence. If a file might matter in a claim or a dispute, preserve it as received and take advice before cleaning it.
7. Verify, then delete nothing. Check that the copy you are sending is as clean as you think, and keep the master anyway. The asymmetry is brutal: keeping it costs a few megabytes, and not keeping it is unrecoverable.

When the file is going to a person rather than a platform, the conversation is usually the harder part, and that is its own problem — covered in what to do when someone asks for the original, unedited photo.

Common mistakes and misconceptions

"I can always put the metadata back." You can type a date into a library, and you cannot restore a lens profile, a provenance assertion, a sub-second timestamp or a camera serial you no longer have a record of. Treat the strip as final for that copy.

"I'll just remove the GPS." Only with a field-level editor. A rebuild-based cleaner deletes the whole header, including the parts you wanted.

"Stripping GPS means no location gets attached anywhere." A cleaned file carries no coordinates, which is not the same as a service having no idea where the photo was taken. Google documents that Photos estimates missing locations from landmarks and from your other photos, and the estimate lives in the service rather than in your file. Removing a field is not the same as suppressing an inference.

"Stripping will ruin the quality." Different axis. Tags are separate from pixel data, and the visible cost comes from re-encoding, not deletion. What this page is about is lost information, not lost sharpness.

"Keeping metadata proves the photo is genuine." It does not. Every field in the block can be written by software, so a rich header is evidence of a plausible story rather than a verified one. Keep it because downstream tools need it, not because it authenticates anything.

"The platform strips it on upload anyway, so my own copy does not matter." What a given platform does varies, changes and applies only to the copy it serves. Your archive is a separate decision, and it is the one you will still be living with in five years.

"My raw files are at risk." Not from a tool that only handles JPEG and PNG. The right pattern for a raw workflow is unchanged: keep the raw master, clean the delivery file.

Where this site's tool fits, and where it does not

Stated plainly, because this page is about knowing the cost. MetadataWipe accepts image/jpeg and image/png only, one file at a time. It decodes the image, draws it to a canvas at the original pixel dimensions and exports a new file from that canvas — a fresh lossy encode for JPEG at a quality fixed in the code, a fresh PNG otherwise — then appends -metadatawipe to the name and leaves your original exactly as it was. All of that runs inside the page on your own device; nothing is sent anywhere.

So it is a good fit for the outbound copy in the workflow above, and a poor fit for three of the jobs on this page. It has no field-level control, so it cannot keep a credit line while dropping coordinates. It has no batch mode, so it is not the way to process a four-year archive. And its built-in check reports presence rather than values — for a JPEG it looks near the start of the file for an APP1 segment carrying the Exif identifier and for the literal text GPS; for a PNG it walks chunk types looking for eXIf, tEXt, iTXt, zTXt, tIME and iCCP — so when you need to read what a field actually says before deciding whether you can afford to lose it, open the file in a full metadata reader first.

Related guides

See also:

• Does stripping EXIF affect photo orientation or color profile?
• What to do when someone asks you for the original, unedited photo