Photo metadata in the data export you download from your account

People request an account export for ordinary reasons. They are leaving a service and want their pictures back. They are changing providers. They need to produce their own messages, photos or history for a lawyer, an insurer, an employer, a landlord, a benefits office or a counterparty. Or they simply want to see what a company has been keeping. The archive arrives as a large compressed file, they extract it, glance at the folders, and — because nothing in it belongs to anyone else — they hand the whole thing over to whoever asked.

That reflex is understandable and it is the wrong shape for the situation. An export is not a copy of the files you put in. It is a reconstruction of everything the service holds about the material, produced under a design brief that is the exact inverse of privacy: portability. A portable archive is meant to be complete enough that another service could rebuild your library from it, which means the exporter is actively trying to include context that was never in your files. That is a feature when you are migrating. It is a liability when you are disclosing.

Completeness is the point, and that is the problem

Every other privacy decision on this site is a minimisation decision: what is the least this recipient needs. An export is built by a system pursuing the opposite objective, and it has no idea who you are about to send it to. Nothing in the pipeline asks whether the recipient should see your album names, your activity history, or the twelve near-identical versions of the photo you eventually posted. The bundle is maximal by construction and stays maximal until a human narrows it.

This also means the usual mental model — a photo is a file, and a file has a header I can clean — under-describes what you are holding. An export is a small database in folder form. The images are only one of its layers, and on most bundles they are not the layer that gives away the most.

The three layers inside a bundle

It helps to sort an extracted export into three groups before touching anything, because each one behaves differently and only one of them is a photo-cleaning problem.

Layer one: the media files themselves. These carry the same embedded tag layer any image carries — capture time, device make and model, software strings, sometimes coordinates, sometimes an embedded thumbnail. Two things commonly surprise people here. The first is that an export may contain versions you did not know were retained, such as originals kept alongside edits, or duplicates that arrived from a second device. The second is that whether a service stores what you gave it byte for byte, or stores a processed derivative, varies by service, by plan and by setting — so the tags on a file that comes back out are not reliably the tags on the file that went in, in either direction.

Layer two: companion records. This is the layer that makes exports different from every other scenario on this site. Bundles routinely ship machine-readable files — JSON, CSV, HTML — sitting beside or above the media, describing it. Google's help documentation for downloading your Google data is explicit about this for its own service: it states that additional metadata which is not from the original file, such as comments within Google Photos, is downloaded to a secondary JSON file. Read that carefully, because the implication is larger than it first looks. Information the service derived or collected about your picture, which was never in your picture, is delivered to you as text next to your picture. A companion record can therefore describe an image whose own header is entirely empty. Cleaning the image accomplishes nothing about the text file beside it.

Layer three: account history. The part people forget entirely. Depending on what you asked for, an export can include material that has no relationship to any individual photo: login and activity logs, device and browser lists, address-book entries, search or viewing history, purchase records, saved locations, group and contact lists. This layer often reveals far more about your routine and your relationships than any geotag, and no amount of image cleaning touches it. It is also the layer most likely to be handed over by accident, because it lives in folders nobody opens.

What one provider documents about its own export

Because service behaviour changes and generalising is how people get burned, it is worth grounding this in something published rather than something assumed. Google's help documentation for downloading your Google data sets out several things about its own archives that are useful as a model for what to look for elsewhere.

It confirms the companion-record behaviour described above: metadata that is not from the original file, such as comments within Google Photos, comes down in a secondary JSON file. It describes the timestamp split directly — that based on the time the photo or video is downloaded, your operating system can assign a new timestamp to the file itself, while the photo or video metadata still has the original timestamp preserved in the metadata embedded within the files. It notes that the archive can be delivered as a download link by email or sent into a storage service, which is itself a disclosure decision worth thinking about before you choose. And it warns that your data file may not include changes made between when you request a download and when the archive is created, which is the reason an export should be treated as a snapshot with a date rather than as the current state of your account.

Those are statements about one company's product, made by that company. Do not extend them to any other service: whether a different provider writes companion records, what it puts in them, whether it returns originals or derivatives, and how long the snapshot lags all vary by provider and version. The transferable part is the checklist of questions, not the answers.

Why "I cleaned my photos before sharing them" does not settle it

Readers who already clean files before sending them often assume their export must be clean by extension. It is worth spelling out why that inference fails, because each failure is independent of the others.

An account accumulates history. Anything added before you adopted the habit is still in there in its original condition. Anything that arrived by a route that bypasses your habit — automatic backup from a phone, sync from a laptop, a shared album someone else contributed to, an import during a device migration — never passed through your cleaning step at all. This is the same mechanism that catches people when a tidied file appears tagged again after a sync, which our guide on whether cloud photo backups restore metadata you just stripped works through in detail: the account holds its own copy, and your local edit never reached it.

Then there is the direction of travel. Cleaning happens on the way out of your device; an export comes on the way in. Nothing you did at the exit applies to material the service already had, and the export will happily reunite you with a version you thought you had replaced. For how tagged copies propagate and persist across accounts and handsets in the first place, see how metadata survives cloud sync and device transfers.

And finally the companion layer sidesteps the question altogether. You can have stripped a photo perfectly, at the right moment, on the right device, and still hand over a text record that states when it was taken and which album it belonged to — because that record was written by the service, about the photo, and lives outside it.

A working order for an export you are about to hand over

1. Scope the request before you request the export. Most export interfaces let you pick products, date ranges or specific libraries. Narrowing at that stage is far more effective than deleting afterwards, and it means the surplus never exists on your disk to be forwarded by accident.
2. Decide where the archive is delivered. Sending it into a storage account is convenient and is also a disclosure to that account. A link by email puts the archive in your mailbox. Neither is wrong; both are choices, and they deserve a moment's thought rather than a default click.
3. Treat the delivered archive as read-only. Extract a copy and work on the copy. Keep the original bundle intact, unmodified, and where you can find it.
4. Inventory the folders before opening files. List the top-level directories and write down what each one is. This is where forgotten layer-three material shows up — history, device lists, contacts — and the whole point is to see it before the recipient does.
5. Separate media from records. Sort the extracted tree into images, companion text files, and everything else. The three layers need three different decisions and merging them is how bundles get forwarded whole.
6. Ask what the recipient actually needs. Usually it is a small number of specific items, not a library. An export is the raw material for an answer, not the answer.
7. Build a fresh folder, do not prune the old one. Copy only the items you have decided to send into a new, empty directory. Subtracting from a bundle leaves residue — stray records, empty structure, revealing folder names. Adding to an empty folder cannot.
8. Read one companion record before you decide about the rest. Open a single JSON or CSV file in a plain text editor and see what fields it holds. Five minutes here tells you more about your exposure than any amount of reasoning about what a service probably stores.
9. Clean the images you are sending, individually, at the end. By this point the list is short, which is exactly the scale a one-file-at-a-time browser tool suits. For a bulk pass over thousands of images, use a batch tool on your own machine instead.
10. Check the file rather than the folder view. Your file browser shows filesystem dates written when the archive was extracted. That display says nothing about what is inside the image, in either direction.

If the export was requested for something formal

There is a scenario that reverses much of the advice above, and it is common enough to state plainly. If you obtained the export in connection with a legal claim, a regulatory complaint, an employment process, an insurance matter or anything else where a third party may later care whether the record is complete, then editing it is a different kind of act. Handing over a modified archive while implying it is the full download is the problem — not the cleaning itself.

The safe pattern is the same one archivists use. Keep the delivered bundle exactly as it arrived. Produce a separate, clearly derived set for disclosure. Be explicit with the recipient that you are providing a selection, and be prepared to say what was excluded and on what basis. Where an obligation to preserve material may exist, that obligation generally attaches to the original, which is one more reason not to work in place. This page is a description of how the files behave and is not legal advice; if a preservation duty is genuinely in play, ask someone qualified in your jurisdiction before you alter anything.

What this tool can and cannot do with an export

Being precise about the limits matters more than usual here, because an export is close to the worst-case shape for a browser tool and pretending otherwise would be useless to you.

MetadataWipe accepts JPEG and PNG images only, one file at a time. It cannot open a compressed archive, cannot traverse a folder, and has no queue. When you select an image it runs a quick heuristic scan over roughly the first half-megabyte of the file, flagging whether EXIF-like markers, GPS-like markers or PNG metadata chunks appear to be present — that is a screen rather than an audit, and it reports presence only, never the values of any field. Cleaning works by redrawing the image onto a canvas at its original width and height and exporting that as a new JPEG or PNG, so the entire tag layer goes at once, with no field-level option and no way to keep the capture date. The clean copy is named with a -metadatawipe suffix added to the original base name, and the download is generated from data already held in the page — nothing is sent anywhere.

What follows from that is simple. The tool has no reach whatsoever into the companion records, the account history, the folder names, the archive itself, or anything else in the bundle that is not a single JPEG or PNG image you have chosen and opened. Those layers are handled by decisions, not by software. The place this tool fits is the last step of the workflow above: a short, deliberate list of images, each handed over as a freshly generated copy rather than as the file the service returned to you.

Mistakes and misconceptions

"It is my own data, so there is nothing to protect." The question is never whose data it is, it is who is about to receive it. An export bundles material from years of activity into a single object. Your own data, handed in full to a landlord, an insurer or an opposing party, is a disclosure like any other.

"I will just forward the zip, it is easier." It is easier, and it is the single most common way people over-disclose. Forwarding the archive means you have not read it, and you cannot be asked about contents you have never seen — right up until you are.

"The photos are clean, so the export is clean." Two separate layers. A clean image can arrive beside a text record that supplies the date, the place and the album name, because the service wrote that record about the photo rather than inside it.

"Everything shows today's date, so the metadata is gone." That is your operating system stamping files as they extract. The embedded capture information is unaffected by the download, which Google states directly for its own exports. File dates and capture dates are different facts and they diverge routinely.

"The export is a live copy of my account." It is a snapshot, and one that may not include changes made while the archive was being assembled. Treat it as dated material, and note the date, particularly if you are giving it to someone who will read it as current.

"I deleted those photos years ago, so they will not be in there." Deletion behaviour, retention windows and what counts as removed all vary by service and by product within a service. An export is the place you find out what your account actually still holds — which is a good reason to read it before anyone else does.

"I can clean the whole bundle in the browser." No browser tool of this kind can. One image at a time, JPEG and PNG, no archives and no folders. The scale mismatch is real and the honest answer is a local batch process for volume and a short curated list for the handover.

Related guides

See also:

• How metadata survives cloud sync and device transfers
• Do cloud photo backups restore metadata you just stripped?