Should you replace photo metadata instead of removing it?

This question comes up in a shape that most privacy guidance never addresses, because most privacy guidance assumes an adversary and a leak. Here the pressure often runs the other way. A stock agency wants a creator field populated. A newsroom wants a credit line. A rebranding business wants its company name on five hundred product shots instead of the name of a contractor who left in 2021. A photographer wants a licence URL to travel with every file. In all of those cases "delete everything" solves a problem nobody had and creates one they did. Meanwhile, someone else entirely is wondering whether to adjust a capture date on a photo they are about to submit as proof of something — and that is a question with a very different answer. Both arrive at the same technical fork, so it is worth taking the fork seriously.

Three outcomes, not two

For any individual field in a photo, there are exactly three things you can do, and it helps to name them before deciding anything.

• Leave it. The field keeps whatever the camera, phone or last editing application put there. You accept the exposure in exchange for the field's usefulness.
• Delete it. The field is gone. Nothing can be read out of it, and anyone inspecting the file learns one thing only: it is not there. The usefulness goes with it.
• Replace it. The field is present and populated, but with a value you chose rather than one a device recorded. The field stays useful and stays readable, and everything now depends on whether your value is defensible.

Deletion has one failure mode, and it is a loud one: a destination that needed the field does not get it, and you usually find out straight away because something rejects the file or a sort order collapses. That is the whole subject of what you lose when you strip photo metadata, and the reason deletion remains the sensible default — its downside announces itself.

Replacement has several failure modes and most of them are quiet. The file looks finished. The field you cared about reads exactly as intended. And somewhere else in the same file, a second copy of the same information still says what it always said. That is not a hypothetical; it is how image metadata is built.

Deleting and replacing are not the same mechanism

People talk about both as "editing the metadata," which hides the most important practical difference. They are performed by different machinery.

Replacing requires a writer. To set a field you have to understand the file's tag structure: find the right segment, work out whether the value belongs in EXIF, in the legacy IPTC block, in XMP or in several of those, write it in the correct type and length, and rewrite the surrounding offsets so the file is still valid. The compressed picture data is left completely alone. This is what desktop metadata utilities and metadata libraries do, and it is why they can change one field and leave forty others untouched.

Deletion by rebuild requires nothing of the kind. A browser-based strip decodes the picture into a bitmap, draws those pixels onto a blank canvas and exports a new file from scratch. It never parses a single tag. The old metadata is missing from the output not because it was found and erased but because the export had no mechanism for carrying it across. That is a blunt instrument with one genuine advantage — it cannot miss a field it does not know about — and one absolute limitation: a process that never looks at the tag structure cannot write into it either.

It is worth being precise about one thing here, because "rebuild" is often described as producing a file with no metadata at all, and that is slightly too strong. A rebuild does not produce pure absence; it produces whatever defaults the encoder supplies. MDN documents that an image created this way "will have a resolution of 96dpi for file formats that support encoding resolution metadata," and the same documentation notes that the quality setting falls back to the browser's own default value when none is given or when the number is out of range. So the output carries a small amount of information that the encoder decided, rather than anything your camera recorded. It is a new file written by the browser, which is a different thing from an empty one.

Why a half-replacement is worse than either option

This is the part that catches people, and it is a property of the standards rather than of any particular tool. The same piece of information very often exists in more than one place inside a single image.

The IPTC describes the history plainly: the original "legacy" IPTC-IIM schema came first, and today's IPTC Photo Metadata Standard consists of IPTC Core and IPTC Extension, built on the legacy of IIM and implemented using Adobe's XMP — now maintained as ISO 16684 — as an enriched alternative to the IIM format. Add EXIF, which carries its own creator, copyright, description, date and location tags, and a single photograph can hold three structurally independent statements about who took it and when.

Writers that handle this properly synchronise the copies. The ExifTool documentation notes that the Metadata Working Group "recommends techniques to keep the EXIF, IPTC and XMP metadata synchronized," and that by default, if a tag already exists in another group, that copy is updated too — otherwise, in its words, "inconsistent values for the same information would exist in different locations." It then adds the sentence that should be pinned above anyone's desk who is contemplating a manual edit: "Of course, you can always generate inconsistencies like this if you really want to by specifically writing contradictory information to different groups."

The consequences are concrete. The same documentation records that contradictory information across formats can cause a reader to ignore a whole block — for example, XMP is often ignored when IPTC exists and the stored IPTC digest does not agree with the IPTC content. So a partial replacement can fail in the most frustrating possible way: your new value is sitting correctly in one place, a reader is honouring a stale value from another, and nothing is broken enough to produce an error.

And the tag structure is not the only layer. A capture date can also be implied by the filename, by the filesystem's own created and modified stamps, and by an embedded preview thumbnail that was generated before your edit. A stripped file is silent about all of these in a coherent way. A file where the EXIF date has been changed to last March while the thumbnail, the filename and the file dates all point at a Tuesday in 2023 is not silent — it is talking, and what it is saying is that someone edited it. This is exactly the asymmetry described from the reader's side in can you trust the metadata in a photo someone sent you: a field is a claim written by the last software to save the file, and claims that disagree with each other are the most informative thing an examiner can find.

Where replacement stops being hygiene

Most of this page is a technical trade-off. This section is not, and it is the reason the page exists rather than just recommending substitution wherever a field is required.

Legitimate replacement is about coarsening or re-attributing information you are entitled to control: putting your business name in a creator field instead of your personal one, writing your own licence terms into a rights field, reducing a precise timestamp to a year, reducing coordinates to a city. The value is still true; it is simply less specific, or it names the right party. Nothing about it is designed to make a reader believe something false.

Falsification is different in kind. Writing a capture time that is not when the photo was taken, or coordinates that are not where it was taken, on a file that exists to establish when or where something happened, is not privacy work. The clearest statutory example is in United States copyright law, and the structure of it is instructive because false information and removed information are handled as separate wrongs. Section 1202(a) of title 17 provides that no person shall knowingly and with the intent to induce, enable, facilitate, or conceal infringement provide copyright management information that is false, or distribute or import for distribution copyright management information that is false. Section 1202(b) separately addresses intentionally removing or altering that information without the authority of the copyright owner or the law. Section 1202(c) defines the information in question to include the title, the author's name, the copyright owner's name, the terms and conditions for use of the work, and identifying numbers or symbols referring to that information. The intent element in (a) matters a great deal, and none of this is legal advice — rules differ by country and by use, and the point here is that the law already distinguishes between staying silent and asserting something untrue.

Outside copyright, the same distinction shows up without needing a statute. Insurance and warranty submissions, court exhibits, official applications, photography competitions and many stock and press workflows all have expectations about capture metadata, and those expectations vary enough that the only reliable move is to read the rules for the specific destination rather than generalise. But the underlying asymmetry is stable: a missing field invites a question, which you can answer. A false field invites a conclusion, which you cannot retract. If a photo might ever need to be defended, remove rather than rewrite, and keep the untouched original where you can find it.

A checklist for deciding field by field

1. Write down what the destination actually requires. Distinguish three things people collapse into one: fields that must be populated, fields that must be accurate, and fields that must be absent. Most requirements are the first kind, which replacement can satisfy, and almost everyone assumes they are the second kind, which it cannot.
2. Sort the fields into four groups. Identity (creator, author, copyright, contact), capture circumstance (date, time, GPS, altitude, direction), equipment (make, model, lens, serial numbers), and technical (dimensions, colour profile, orientation). The right action is almost always uniform within a group and different between groups.
3. Pick one of the three outcomes per group, deliberately. In practice: replace identity, delete capture circumstance, delete equipment, leave technical. That default fits a large share of real jobs, which is worth knowing before you spend an evening on it.
4. If you replace, prefer true-but-coarse over invented. The year instead of a fabricated second. The city or the region instead of coordinates you made up. A business name you actually trade under. Coarsening survives scrutiny; invention does not.
5. Avoid values that only look neutral. Latitude 0, longitude 0 is not "no location" — it is a real point in the Atlantic in the Gulf of Guinea, and it reads unmistakably as a placeholder. The same goes for a date at the start of the Unix epoch, or the word "Unknown" in a field that expects a name. These do not communicate "no answer"; they communicate "someone edited this and chose badly."
6. Write every copy of a concept, or none of them. If you set a creator field, set it in EXIF, in IPTC and in XMP, or use a writer that synchronises them for you. Leaving one stale is the single most common way a replacement becomes worse than a deletion.
7. Deal with the layers that are not fields. Regenerate or remove the embedded thumbnail, check the filename, and remember the filesystem keeps its own dates. A replacement that stops at the tag structure is only partly done.
8. Verify with a different tool than the one that wrote the file. A writer showing you its own intended output is not evidence. Read the finished copy back with something independent — and read the copy you are actually going to send, not the version open in the editor.
9. Keep the original. Replacement is the one metadata operation where you may later need to show what the file said before you touched it. Where it is lawful and appropriate for your situation, keep an untouched master separate from the copy you distribute.

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

Plainly: MetadataWipe removes, and that is all it does. Read from the script that runs on this site, the tool accepts a single image/jpeg or image/png file at a time, runs a presence-only check over the opening slice of the file — it reports that something looking like EXIF, GPS or PNG metadata chunks is present, never what any field says — and then produces a clean copy by decoding the image, redrawing it on a canvas at the original width and height, and exporting a new JPEG at quality 0.92 or a lossless PNG, saved alongside your original with -metadatawipe added to the filename. Nothing in it writes a tag. Nothing in it can keep one field and drop another. Nothing in it can show you a value to edit, because it never reads values at all.

So if the answer you reached above is "replace," this is the wrong instrument and you want a metadata editor. If the answer is "delete everything," a rebuild is a strong choice precisely because it is indiscriminate — it cannot overlook a proprietary block it has never heard of. And if you are doing both, the order is not optional: write your values with an editor and the rebuild will throw them away, so a rebuild has to be the step you do instead of writing, never the step you do after it.

Common mistakes and misconceptions

"Blanking a field is the same as deleting it." It is not. An empty field that is still present is a different artefact from an absent one, and some readers and validators treat them differently — one is "no value supplied," the other is "this file does not carry this kind of information." If you want the field gone, remove the field.

"I set the GPS to zero so there is no location in it." There is a location in it, and it is a specific point in the ocean off West Africa. Writing a coordinate pair is asserting a position. If you do not want to assert one, delete the tags rather than filling them in.

"I changed the date in my photo app, so the file's date changed." Frequently untrue. Many libraries record an adjusted date in their own database and leave the file alone, or apply it only on export, and the behaviour varies by app, platform and version. The only way to know is to read the exported file itself.

"Replacing is safer than removing because the file looks natural." Only if every copy of every concept agrees, including the thumbnail and the file dates. A fully synchronised replacement is indeed less conspicuous than a stripped file. A partial one is considerably more conspicuous than either, because self-contradiction is a signal that absence simply does not produce.

"Writing my own copyright string into someone else's photo protects me." It does the reverse of protecting you. Whatever the rules where you are, asserting authorship of a work that is not yours is the one direction in which substitution carries clearly more risk than removal, and in the US framework above it is addressed by its own subsection.

"A rebuild gives me a file with no metadata whatsoever." Close, but worth stating accurately: it gives you a file with none of the original metadata, carrying instead whatever minimal defaults the browser's encoder writes — the documented 96dpi resolution value being the clearest example. For privacy purposes that distinction rarely matters. For understanding what you are holding, it does.

"Strip it first, then write the fields I need." The right instinct, the wrong sequence for a browser tool, and the trap is specific to this combination. A canvas rebuild is destructive to everything in the header, so it has to come before any writing or not at all. If a job needs both, do the removal and the writing in the same metadata editor and verify the result once.

Related guides

See also:

• What you lose when you strip photo metadata
• Can you trust the metadata in a photo someone sent you?
• Why archives, libraries and museums need you to keep photo metadata