What your filename and file dates reveal after you strip metadata

Think about what actually travels when you send someone a photo. Most privacy advice — nearly all of this site included — treats the image as a single object with a hidden compartment in it. Strip the compartment, and the object is safe. That model is good enough for GPS coordinates and camera serials, and it is exactly wrong for the layer this page is about.

A file has at least three distinct layers of identifying information, and they behave completely differently:

1. Inside the bytes. EXIF, XMP, IPTC, embedded thumbnails, colour profiles. These are part of the image. Re-encoding the picture rewrites them, which is what a metadata wipe does.
2. The filename. Not inside the image at all. It is a label attached to the bytes, carried alongside them by email clients, chat apps, archives, and cloud storage. A wipe cannot touch it, because a wipe operates on the bytes.
3. File-system dates. Created, modified, accessed. These are held by your operating system about the file rather than stored within it. They are not part of the image either, and they are rewritten constantly by ordinary handling.

Layer one has a tool. Layers two and three have a habit, and almost nobody has it. That is the gap worth closing, because a filename is the single most quotable piece of identifying data a file carries — it shows up as plain text in an inbox, in a shared folder listing, in a chat thread, in a support ticket, in a download bar. Nobody needs a forensic tool to read it.

What MetadataWipe actually does to your filename — and what it deliberately does not

Worth being precise here, because the honest answer is a limitation. When you clean an image, the tool takes your original name, drops the extension, and appends -metadatawipe before writing the new one. beach-house-key-under-mat.jpg comes back as beach-house-key-under-mat-metadatawipe.jpg. The base name is preserved in full, character for character.

That is a design choice, not an oversight, and there is a decent argument for it: the suffix is how you tell the cleaned export apart from the original in a folder, which is the mistake that ruins more wipes than any software bug. The verification guide leans on that suffix for exactly this reason — you need to be certain you are checking and sending the cleaned copy rather than the camera-roll master sitting next to it.

But the consequence is unambiguous. If your filename gives something away, cleaning the photo does not fix it. The tool hands the name straight back to you, plus four extra syllables. Renaming is a manual step and it will always be a manual step, so it belongs on your checklist rather than in your assumptions.

What a filename actually gives away

Three broad categories, roughly in order of how often they bite.

Names you typed yourself. This is the dangerous one, because you wrote it while thinking about organisation rather than disclosure. rental-inspection-unit-4b-tenant-complaint.jpg. offer-letter-screenshot-do-not-send-to-dave.png. mri-results-second-opinion.jpg. You named it for your own filing system, months ago, and now it is going out as an attachment with the name intact. Filenames written for private folders leak precisely because they were written honestly.

Names your camera generated. Default camera naming varies widely by device and app, but a common pattern on many Android phones encodes the capture date and time directly in the filename — something in the shape of IMG_20260914_112233.jpg. If that is what your device does, the date you just stripped from EXIF is still sitting in plain sight in the name. Sequential names like DSC_0412.JPG or IMG_4417.HEIC are less revealing individually, but across a set they expose shot order and rough counts. Check what your own device produces rather than assuming; conventions differ between manufacturers and change between OS versions.

Names an app or workflow generated. Scanners, screenshot tools, document exporters, and download managers all impose their own naming, and those names routinely embed dates, document titles, ticket numbers, account references, or the source application. A screenshot named after the window it captured can announce the software you run and the file you had open.

Why file dates are a different problem from capture timestamps

A capture timestamp such as DateTimeOriginal lives inside the image and a wipe removes it. The dates your operating system shows in Finder's Get Info or the Windows Properties dialog are separate — they are file-system bookkeeping, not image content. Browsers expose the same distinction: when a page reads a file you selected, the last-modified value it sees comes from your file system, not from anything inside the picture.

Two practical consequences follow.

First, stripping metadata will never clear a file date, because there is nothing inside the file to clear. Seeing a normal modified date on a cleaned export is not evidence the wipe failed. That confusion is common enough that it is worth naming explicitly.

Second, file dates are unreliable in both directions. Copying, downloading, syncing, unzipping, or restoring from backup can each reset them. The cleaned image you download is a genuinely new file assembled in your browser, so it gets stamped with the moment your browser wrote it to disk — today's date on a photo from three summers ago. Do not read a file date as a fact about when a photo was taken, and do not expect anyone else to either.

Where file dates do still leak is inside containers. Archive formats and some sync systems preserve per-entry names and modification times, so zipping a folder of cleaned photos can carry forward a timeline you thought you had removed. If a batch is going out as an archive, the archive itself is worth a look.

A workflow that closes the gap

1. Clean the image first. Strip metadata from the JPEG or PNG and download the export, so the byte-level layer is settled before you touch anything else.
2. Read the filename out loud. Genuinely. If you would not be comfortable reading it to the recipient over the phone, it needs changing. This one test catches most of it.
3. Rename to something deliberately boring. A neutral descriptor plus a number is ideal: photo-01.jpg, listing-image-3.jpg, attachment-2.png. Boring names carry no information, which is the entire point.
4. Strip dates out of generated names. If your device writes the capture date into the filename, removing it from the name is as much a part of the job as removing it from the header.
5. Rename the whole set consistently. Sequential names across a batch reveal ordering and gaps. If you renamed four of six, the remaining two stand out.
6. Check the folder and archive names too. A perfectly anonymous photo inside a folder called divorce-evidence-2026 has achieved nothing.
7. Verify the image itself separately. Renaming is not cleaning. Confirm the header is actually empty on the file you are about to send.

Common mistakes and misconceptions

"I renamed it, so the metadata is gone." Renaming changes a label and touches none of the image bytes. GPS, camera model, and capture time all survive a rename completely intact. This is one of the most persistent false beliefs in the whole subject.

"I stripped the metadata, so the name doesn't matter." The mirror image of the same error, and more common among people who have read a few guides. The wipe handled layer one and left layers two and three exactly as they were.

"The platform will rename it anyway." Some services do assign their own identifiers on upload; others preserve or display the name you supplied, and behaviour differs between the same company's web uploader, mobile app, and direct-message path. Treating renaming as someone else's job means it gets skipped on whichever path does not do it. Rename before sending and the question stops mattering. Separately, when a filename does survive into a published page it can become part of what search engines index about an image — the guide to EXIF removal and search engines covers why stripping a file's header does nothing to what is already indexed elsewhere.

"The modified date proves when I took it." It does not. It records when the file was last written on that particular device, which is often just when it was copied or downloaded.

"A cleaned file with today's date means the wipe failed." It means the export is new. That is the expected result.

Cleaning the image and then sending the original by mistake. Worth repeating because the suffix exists to prevent it. Send the file with -metadatawipe in the name, or the one you renamed from it — never the neighbour in the same folder.

Related guides

See also:

• How to verify metadata was removed
• Does removing EXIF data remove a photo from search engines?