In 2012, Vice published a photo of John McAfee, then on the run in Central America, under the headline "We Are with John McAfee Right Now, Suckers." The photo's EXIF data contained GPS coordinates. Within hours, the internet knew he was in Guatemala, and so did the authorities. The reporters hadn't leaked his location on purpose — the iPhone had, and nobody checked the file before it went live.
That story gets retold in every metadata explainer, and for good reason: it's the cleanest example of a category of failure that hasn't gone away. Newsrooms have gotten better. Press-freedom organizations and outlets like ProPublica have published detailed guidance on handling sensitive documents, and most large publications now have some kind of process. But the process only works if it's actually followed, file by file, on deadline. This checklist is the version I'd want taped next to the CMS login.
Start with the threat model, not the tools
Sanitization without a threat model is theater. Before you touch a single file, be clear about who you're protecting and from whom:
- The source. A leaked document or photo can identify who created it, whose account exported it, which office printer produced it, and when. For a source inside a government agency or company, any one of those can be the end of a career — or worse.
- The subject. A photo of a safe house, a shelter, or a witness can carry GPS coordinates accurate to a few meters.
- The newsroom. Internal author names, edit histories and file paths in published documents map your organization's people and workflow for anyone who's hostile to it.
The adversary matters too. A curious reader with a metadata viewer is a different problem than a state actor subpoenaing a platform, and an employer running a leak investigation is different again — employers can cross-reference document metadata against internal access logs. Assume the most motivated plausible adversary will download your published files and inspect every byte.
Publish the story, not the file's history. Every published file should carry exactly the information you decided to publish — and nothing you didn't.
The checklist
1. Inspect before you publish — every file, every time
You can't sanitize what you haven't seen. Before any file goes near the CMS, open it in a metadata viewer and read what's actually in it: EXIF fields, XMP blocks, GPS tags, embedded thumbnails, C2PA manifests. Do this on the original, and do it again on the final file after all your processing — pipelines have a way of re-introducing data, and some editing tools copy metadata forward from the source file. Two minutes, twice. It's the single highest-value step on this list, and it's the one most often skipped because someone assumed an earlier step "probably" handled it.
2. Strip images completely
For photographs, the default should be full removal: EXIF (camera make, model, serial number, timestamps), GPS, XMP, IPTC and any embedded provenance data. A camera serial number can tie a photo to a specific device; a timestamp can contradict — or confirm — where someone claims to have been. Run every image through a photo metadata remover and verify the output is clean. Watch the embedded thumbnail in particular: some tools historically rewrote the main image but left the original preview intact, cropped faces and all.
3. Handle GPS-only cases deliberately
Sometimes you want to keep the capture date or camera information — say, to support the photo's authenticity — but the location must go. That's a legitimate editorial call, and it needs a targeted tool rather than an all-or-nothing one. A GPS-only remover deletes the location block and leaves the rest. Make the choice consciously and note it in your story file, because "we kept the EXIF to prove when it was taken" is a decision an editor should be able to reconstruct later.
4. Don't forget video
Video files are routinely overlooked, and they're often worse than photos. Phone-shot MP4 and MOV files can carry GPS coordinates, device model, capture timestamps and software identifiers in their container atoms. A clip recieved from a source may also embed the editing software and project details used to trim it. Run video through a video metadata remover before publication, and if the footage is genuinely sensitive, consider re-encoding it entirely so nothing structural from the original container survives.
5. Treat PDFs as the minefield they are
PDFs are the most dangerous format on this list because they look like paper and behave like databases. The document information dictionary carries Author, Creator and Producer fields that frequently contain a real name or a username. XMP metadata can include document IDs that persist across edits. And Word documents exported to PDF have a long, ugly history of carrying tracked changes, comments and deleted text that the author believed was gone — there are well-known cases of organizations publishing "redacted" documents where the redactions were rectangles drawn over live, selectable text. Strip the metadata with a PDF metadata remover, but also open the file and check: select all, copy, paste into a text editor, and see what comes out. If the document came from a source, remember that its internal metadata may identify them, not you — which makes this step a source-protection obligation, not housekeeping.
6. Check AI-drafted text for invisible characters
If any part of your copy passed through an AI writing tool, be aware that some tools and pipelines leave fingerprints in the text itself: zero-width spaces, non-breaking spaces in odd positions, curly quotes and dashes in statistically unusual patterns, or special Unicode variants that are invisible on screen but trivially detectable in the raw bytes. Whether or not you consider that a problem editorially, you should at least know it's there. An AI text watermark remover normalizes the hidden characters so what you publish is exactly the visible text and nothing else. This matters most for quotes and statements you've been given in electronic form — hidden characters can survive copy-paste from the source's original file and end up identifying it.
7. Rename files and mind the upload platform
Metadata isn't only inside the file. whistleblower_meeting_jane_final2.jpg tells a story all by itself, and camera-default names like DSC_0041.NEF reveal device conventions and sequence numbers that can be correlated across published photos. Rename everything to something neutral before upload. Then think about what your publishing platform does: some CMSes and social platforms strip metadata on upload, others preserve it, and a few preserve it in the "download original" path while stripping it in the displayed version. Never outsource sanitization to the platform — as of mid-2026 the behavior varies wildly and changes without notice. The file should already be clean when it leaves your hands.
8. Keep sensitive files off other people's servers
This one is about the sanitization process itself. If your workflow for cleaning a sensitive photo involves uploading it to some free web service that processes it server-side, you've just sent an unpublished, unsanitized source document to an unknown third party — creating exactly the kind of copy a subpoena or a breach can surface later. For sensitive material, use tools that run entirely client-side, in the browser or on your machine, where the file never crosses the network. (That's the design principle behind all the tools linked in this checklist: the processing happens locally and nothing is uploaded.) The same logic is why press-freedom guidance consistently recommends air-gapped machines for the most sensitive documents; the browser-local version is the lightweight end of of that same spectrum.
9. When in doubt, re-create instead of sanitize
For the highest-stakes material, the safest version of a file is one that was never the original. Photograph the document instead of scanning it, then strip the photo. Retype the crucial passage instead of pasting it. Re-encode the video from a screen recording. Each of these breaks the chain between the published artifact and the source's copy far more thoroughly than any metadata tool can, because it discards the container entirely rather than cleaning it. You lose some fidelity and some evidentiary weight, and that's a real trade-off an editor should weigh — but when a source's safety is on the line, fidelity is usually the thing to sacrifice first.
The two-minute version, for deadline days
- View the file's metadata. Read all of it.
- Strip it — fully for images and video, targeted for GPS-only cases.
- For PDFs: strip, then select-all-copy-paste to hunt hidden text.
- For text: normalize invisible Unicode.
- Rename the file to something that says nothing.
- View the metadata again on the final file. Confirm it's empty.
- Only then, upload.
What this checklist can't do
Two honest limits. First, metadata hygiene doesn't defeat content-level identification: printer tracking dots, unique document formatting, distinctive camera sensor noise, or watermarks embedded in the pixels of AI-generated imagery all survive metadata stripping, because they aren't metadata. If the document itself is one of only three copies ever made, no tool fixes that — that's an editorial decision about what to publish and how much to paraphrase.
Second, a checklist is only as strong as its worst day. The failures that make headlines are almost never exotic; they're a skipped step at 11pm before a launch. Build the inspection habit into the publishing workflow itself — a required field in the CMS, a pre-publish hook, a second pair of eyes — so the check happens even when the person doing it is tired. Your sources are trusting you with exactly that.