Editorial & Review Policy
Metadata advice is only useful if it is accurate. This page explains exactly how we research, test, review and correct every tag reference entry and guide on this site.
Last updated October 20, 2026
Why this page exists
Most of what is published about EXIF is copied from one another. A claim about which tag holds the camera serial number gets repeated on ten blogs, each citing the other, and nobody notices when it is wrong. The same goes for privacy advice: a list of “dangerous tags” is published everywhere without anyone explaining how the ranking was decided.
We publish this policy so that you can judge our work rather than take it on trust. If we get something wrong, you should be able to see how it happened and how it will be fixed.
Our editorial principles
We test, we do not guess
Every claim about what a tag contains, what an operating system exposes, or what a platform strips is verified against a real file or a real screen. Where we could not verify something, we say so rather than presenting it as fact.
We separate the standard from the vendor
What the EXIF specification defines is labelled as such. What a particular camera maker writes inside a proprietary MakerNote is labelled as vendor behaviour, because the two behave very differently and readers need to know which they are looking at.
We state our sources
Specifications are named and linked. Our privacy ratings are clearly marked as editorial judgement rather than being passed off as part of any standard, because no standard assigns privacy risk levels to tags.
We correct in public
When something we published turns out to be wrong or out of date, we correct the page and note the change. We do not quietly rewrite content and leave the old claim in place.
We do not publish filler
Guides are written to answer a specific question that a person actually has. Pages that exist only to catch a keyword are not published, and pages that stop earning their place are merged or retired.
How we research
For every tag entry we start from the published specification and then confirm it against a real file. The specifications we work from are:
- CIPA DC-007-Translation (Exif 3.0) — the current EXIF specification, including the IFD0, Exif SubIFD and GPS IFD structures.
- ISO/IEC 21222-1 — the standard for registering metadata elements for photography.
- Adobe XMP Specification — the XMP packet format, its namespaces and the property names used in modern files.
- IPTC IIM 4.2 and the IPTC Photo Metadata Standard — the legacy news and agency fields still embedded by many editors.
Specification text tells us what a tag means. It does not tell us which cameras actually write it, what real values look like, or how a given editor populates it. For that we work from a test corpus: sample images produced by iPhones, Android devices, Canon, Nikon, Sony, Fujifilm and Panasonic bodies, and files saved out of Lightroom, Capture One, Photoshop and several smaller editors. Where a field is vendor-specific rather than standard, we say so.
How we rate privacy risk
No standard assigns privacy risk to metadata. The ratings in our EXIF tag reference are our own editorial judgement, and we apply them with one consistent question:how much does this field narrow down who, where or which device this photo came from?
- Critical — the field reveals an exact location, or uniquely identifies one specific physical device in the world.
- High — the field attributes the photo to a real person, pins it to a precise moment, or reveals a place someone lives.
- Medium — the field meaningfully narrows down a device, a workflow or an identity but is not identifying alone.
- Low — the field is a capture setting.
- None — the field is technical file information with no personal dimension.
A field can move between ratings over time. A tag that was innocuous in 2010 — a camera serial number, for example — is high risk today because serial numbers are now routinely used to link images to seized devices. We revisit ratings rather than treating them as permanent.
Review schedule
| Content | Cadence | What we check |
|---|---|---|
| EXIF tag reference entries | Reviewed every 3 months | Tag IDs and encodings are checked against the current published specifications. Ratings are revisited when a camera vendor changes what it writes. |
| Platform how-to guides | Reviewed every 6 months | Operating system interfaces change frequently. We re-verify every menu path against a current build before the guide is republished. |
| Social platform behaviour | Reviewed every 3 months | Whether a platform strips EXIF on upload is a moving target. We note the date of the last check on each guide. |
| Tool behaviour | Reviewed on every release | Format support, export modes and parsing coverage are re-tested against the test corpus whenever the tool changes. |
How we handle corrections
When a reader reports an error we reproduce it against the test corpus before changing anything. If the error is confirmed, the page is corrected and the change is noted with a new review date. If it is not confirmed, we explain why to the person who reported it, because a report that turns out to be wrong is often a sign that the behaviour is more nuanced than either of us assumed — and that nuance belongs in the guide.
Where a page is no longer the best answer to a question, we merge it into the page that is, and redirect the old URL, rather than leaving two thin pages competing with each other.
Found an error?
Send the page URL, the claim you believe is wrong, and the file or device that contradicts it. We read every report. Use the contact form or email [email protected].