Why archives, libraries and museums need you to keep photo metadata
Nearly every other page on this site starts from the same premise: a photo's header is a liability, and the safe move is to empty it before the file leaves your hands. If you are digitizing a box of family prints for a historical society, donating negatives to a library's special collections, or scanning slides for a small museum, that premise runs backwards. The institution on the other end does not want a blank header. It wants a filled-in one, built to a published standard, because the header is how the photo gets found, attributed, dated and licensed for the next fifty years. Running a whole donated batch through a privacy stripper before handing it over does not protect anyone — it deletes the catalog record before the catalog exists.
MetadataWipe removes EXIF, GPS and other header data from a single JPEG or PNG, entirely in your browser — the right tool for a photo you are sharing, not for a photo you are cataloging.
Open MetadataWipe toolWhy "clean it before you hand it over" breaks the archive's job
Every other scenario on this site has a single owner making a single decision about a single outbound file: you, deciding what a stranger, a platform or a recipient gets to see. A donation or a digitization project has a different shape entirely. The file is headed into a system — an archive, a library catalog, a museum's digital asset management database — whose whole purpose is to make that photo findable by people who were not there when it was taken and who will never meet you. That system runs on metadata the way a bookshop runs on a catalog number. A photo with an empty header is not a safer photo to that system; it is an unfindable one, indistinguishable from thousands of other unlabeled files, with no record of who took it, when, who appears in it, or what rights anyone holds to reproduce it. Two related pages on this site touch adjacent ground — publishing an image dataset covers what a researcher must document when releasing images for machine learning, and should you replace photo metadata instead of removing it covers deciding field by field whether to delete or overwrite — but neither is written for someone whose goal is long-term institutional preservation rather than a one-time release or a privacy cleanup.
The standard institutions actually catalog against
This is not an informal convention. The IPTC Photo Metadata standard describes itself as the industry standard for administrative, descriptive and copyright information about images, citing universal acceptance among photographers, distributors, news organizations, archivists and developers as the reason it is the one most cataloging software reads and writes. It defines two historical ways of storing that information in a file: the older IIM structure, and the current XMP structure, with the standard's own documentation set including a guide on IIM being deprecated inside IPTC Core — current practice is to write XMP. Within that structure, fields are grouped as Core (the long-established set) and Extension (added after 2005, available only in XMP). The Core fields that matter most to an archivist cataloging a donated photo include Creator (and a Creator's Job Title), Credit Line, Copyright Notice and Current Copyright Owner information, Headline, Caption/Description, Date Created, Location Created and Keywords. The newer Extension fields include Persons Shown, which names the people visible in the frame, and Digital Source Type, which the standard also provides guidance on using to flag AI-generated or AI-edited images. None of these fields are written by a camera automatically. They exist because someone — a photographer, an archivist, a cataloger — typed them in deliberately, and that act of typing is the entire value an archive is asking a donor or a digitizer to preserve.
This is not a hypothetical worry
The IPTC's own research gives a concrete, current illustration of what happens when nobody treats keeping that record as a requirement. The organization announced Metawatch, described in its release as a free, open monitor run monthly checking whether more than 500 news publishers in 122 countries keep the credit, caption and rights information embedded in the photographs they publish. Its own summary of the first results was that little has changed since a comparable study conducted in 2018. That is a pipeline problem rather than a privacy decision — nobody at those publishers is choosing to strip rights information to protect a subject's location. The fields are simply not built to survive whatever content-management or image-processing step the photo passes through on its way to publication. An archive accepting your donated or digitized photos sits at the far end of an equivalent pipe. The only difference is that you, not an anonymous CMS, are the step that decides whether the record survives.
A workflow that keeps the record and still respects privacy
- Digitize at full resolution and keep one untouched master. Do not run the raw scan through any cleaning tool first. Whatever the scanner or your phone's camera app wrote, and whatever you have not yet added, both need to still be there while you decide what belongs.
- Write the descriptive record deliberately, in cataloging software that understands the standard. Fill in Creator, Date Created (even if only approximate — the standard supports a circa qualifier for exactly this situation), Caption/Description, Credit Line and rights information using software built to write IPTC Core and XMP fields. A canvas-based privacy stripper, including this site's tool, has no concept of these fields and cannot write them.
- Separate the digitizing device's own noise from the subject's record. A GPS tag your phone wrote while photographing a print describes your location during digitization, not the depicted scene. That is the one category worth removing even in an archival context, because it answers a question nobody asked.
- Review privacy-sensitive fields about living people on their own terms, field by field. A home address visible as GPS on a personal snapshot, or a living private individual's full name in a caption, may warrant a documented redaction if the family or donor requests it. Redact that specific field deliberately and note that a redaction happened — do not reach for a tool that blanks the entire header to solve a problem in one field.
- Hand the institution the complete master, not a stripped copy. If a display or public-access copy needs different treatment than the preservation master — a lower resolution, a watermark, a field withheld from public view — make that a second, clearly labeled derivative. The master keeps the full record.
Where this site's tool fits, and where it does not
MetadataWipe's removal step decodes a JPEG or PNG onto a canvas and re-encodes it as a new file. That process is all-or-nothing by construction: it does not parse individual IIM, XMP or EXIF fields, so it cannot keep a Creator tag while deleting a GPS tag, and it has no interface for typing a caption or a credit line in. That is exactly right for its actual job — cleaning one personal photo in your browser before you post or send it — and exactly wrong for cataloging a donation, where the goal is a complete, standard-compliant record rather than an empty one. If you are digitizing for an institution, the tool you want is metadata-writing cataloging or digital-asset-management software, not a stripper, and the one case where this site's tool still has a place is the narrow one above: removing an incidental, digitizing-device GPS tag from a print photograph before the deliberate record goes on top of it.
Common mistakes and misconceptions
"A fresh scan starts metadata-free, so there's nothing to manage." A fresh scan starts information-poor, not clean in any useful sense — it is missing the record an archive needs, not free of a risk it had. Those are opposite problems that happen to look similar from a distance.
"Stripping everything before donating is always the safer choice." It is safer for exactly one category of field, location, and actively harmful to every other field an archive relies on — Creator, dates, captions, rights — none of which carry the privacy risk that motivates stripping on the rest of this site.
"If the family doesn't fill in the fields, the standard doesn't apply." Optional fields can stay empty under the standard, but an empty Creator or Credit Line field is a cost the archive pays later, every time someone tries to attribute or license that image, not a neutral default.
"Legacy IIM tags matter as much as XMP ones." The standard's own guidance treats IIM as deprecated inside IPTC Core; software written or used today should be writing and reading XMP, with IIM relevant mainly to very old files that predate the current practice.
"This is only a concern for professional archives." A family historian, a genealogy hobbyist, or a volunteer digitizing a local history society's shoebox of prints is doing the same cataloging work on a smaller scale, and the same standard applies whether or not anyone involved has a job title that says so.
Related guides
See also:
- Publishing an image dataset: what to strip and what to document
- Should you replace photo metadata instead of removing it?
Frequently asked questions
Does IPTC Photo Metadata replace EXIF?
No — they are different layers written for different jobs, and a single JPEG routinely carries both. EXIF is written by the camera at the moment of capture: lens settings, orientation, a timestamp, sometimes GPS. IPTC Photo Metadata is a separate, deliberately authored layer covering administrative, descriptive and copyright information — who made the image, what it shows, when it was created, who owns the rights, and under what terms it can be used. The standard recognizes two generations of storage: the older IIM format and the current XMP format, and the standard's own documentation set includes a guide titled "IIM metadata deprecated in IPTC Core" — current software is meant to write and read the XMP structure going forward. Some fields exist in both the IIM and XMP representations, such as Creator and Description; fields added to the specification's Extension Schema after 2005, such as Persons Shown and Digital Source Type, exist only in XMP. Removing one layer does not remove the other, and an archive typically wants EXIF's technical facts intact alongside a deliberately written IPTC Core record.
I'm digitizing old family photos for a historical society — should I remove the GPS data my phone added when I photographed a print?
Usually yes, but be precise about what you are removing. If you used a phone camera or a phone scanning app to digitize a physical print, the GPS tag your phone wrote describes where you were standing while digitizing — your living room, a storage unit, a relative's kitchen table. It says nothing about the person, place or event in the picture; it is noise added by the digitizing step, not anything original to the photograph. That incidental GPS is worth removing. What should not go with it is the Creator, Date Created, Caption/Description and Credit Line information you deliberately write afterward — who took the original photo, roughly when, who is in it, and under what rights the archive may use it. The digitizing device's own incidental location tag and the archive's descriptive record sit in the same file but answer completely different questions, and only one of them is yours to delete.
Can MetadataWipe write IPTC captions, creator names or keywords for me?
No. This site's tool goes one direction only: it decodes a JPEG or PNG onto a canvas and re-encodes it, which discards the entire header — EXIF, IIM and XMP alike — with no option to keep some fields and not others, and no interface for writing new ones in. That is the right behaviour for its actual job, cleaning a single personal photo in your browser before you share it, but it is the wrong instrument for building a catalog record. Writing Creator, Caption, Date Created, Credit Line, Rights Usage Terms and the rest of the IPTC Core fields needs dedicated cataloguing or digital-asset-management software built to read and write that structure, not a browser-based stripper that cannot tell one field from another.
What is IPTC's Metawatch, and why does it matter here?
Metawatch is a monitor the IPTC — the standards body that defines the Photo Metadata specification — announced it was launching, described in its own release as a free, open check run monthly on whether more than 500 news publishers in 122 countries keep the credit, caption and rights information embedded in the photographs they publish. The IPTC's own summary of the first results was that little has changed since a comparable study in 2018. It matters here because it documents, on an ongoing basis, exactly the failure mode this page is about: a photo moves through a publishing or distribution pipeline and loses the descriptive and rights layer a reader, researcher or licensing desk would need, not through anyone's deliberate privacy decision but because nothing in the pipeline was built to keep it. An archive accepting a donated or digitized photo sits at the other end of that same kind of pipe, and it only receives a complete record if someone upstream treats keeping that record as a requirement rather than an accident.
Remove EXIF data, GPS location and common photo metadata from a JPEG or PNG in your browser.
Try MetadataWipe free