What a ZIP of photos reveals even when the photos are clean
Nearly every page on this site works on one unit: the picture. Clean the picture, verify the picture, send the picture. This page is about the thing you wrap around forty of them when you actually deliver a batch — the archive. A ZIP is not a neutral envelope. In order to rebuild your folder on someone else's machine it has to write down a name, a path, a date and a set of attributes for every single item inside, and it writes them in the clear. You can strip every photo in the set perfectly and still hand over a file whose first line of output reads Client Shoot - Jane Doe/.
MetadataWipe rebuilds one JPEG or PNG at a time from decoded pixels, in your browser — no account and no server transfer, and the file never leaves this device.
Open MetadataWipe toolTwo neighbouring pages make it easier to see where this one sits. Photo metadata stored outside the image file covers the information your own operating system keeps about a photo — named streams, extended attributes, sidecars, library catalogues — and makes the point that because it lives outside the image bytes, it does not travel when you send the image. Archiving is the mechanism that breaks that rule. An archive is precisely a way of serialising filesystem facts so they survive a journey, and some archivers go out of their way to carry the attributes too. The second neighbour, why a set of photos leaks more than one photo alone, is about what the pictures in a batch reveal collectively. That is about the contents. This is about the wrapper.
What a ZIP writes down about every file you put in it
The structure is documented and old, and nothing about it is sinister — the format needs this information to work. It is just worth knowing what you are signing.
- The name, as a path. Each entry is introduced by a local file header containing the file name and sizes, and the same details are repeated in a central directory at the end of the archive so a listing can be produced quickly without reading everything. The name is stored as a relative path, and directories themselves usually get entries, so the shape of your folder tree travels intact.
- A timestamp with a quirk. The built-in modification time uses the old MS-DOS representation. The FAT filesystem had a two-second resolution and ZIP records mimic it, and the format has no notion of time zone at all — so a date in an archive is only meaningful if you know where it was made.
- A checksum and two sizes. A CRC-32 of the uncompressed data plus the compressed and uncompressed lengths. Harmless in themselves, but they make the listing a quantitative description of files nobody has extracted yet.
- The host operating system and the archiver. The central directory carries a version made by field identifying the system of origin, and tools report the version of the encoding software alongside it.
- File attributes. Internal and external attribute fields travel with each entry. On an archive built under Unix that includes the permission bits, printed by a verbose listing in the familiar
-rw-r--r--form. - Optional extra fields, which is where it gets personal. The format's extra-field mechanism lets archivers attach higher-resolution timestamps and OS-specific attributes. Two are extremely common in practice: subfield
0x5455, which carries UTC modification and access times and so quietly fixes the time-zone ambiguity in the recipient's favour, and subfield0x7875, which carries the numeric user and group IDs of the account that created the archive. - Comments. Both the archive as a whole and each individual entry can carry a free-text comment. Most people never set one; some tools and workflows do.
It is instructive to build a throwaway archive of a folder called something like Client Shoot - Jane Doe and ask a verbose listing what is in it. You get an entry for the folder itself, an entry for the subfolder, the operating system of origin, the version of the archiving software, a DOS date and time alongside a second, more precise UTC time from the extra field, the Unix permission bits, and a line reporting a UID/GID subfield with the raw numbers spelled out in hex. Not one of those came from a photograph. All of them came from the act of packaging.
The password does not cover the list
This is the single most common surprise. With ordinary ZIP encryption the file contents are encrypted and the directory of entries is not. Ask any standard tool to list a password-protected archive and it prints the names, the paths, the sizes and the dates without ever asking for the password — the encryption guards the pictures, not the fact that a file called injury-left-hand-2026-03-14.jpg exists in a folder named after a case.
The specification does define a central directory encryption feature, added in version 6.2, which encrypts the metadata held in the central directory. Even there the specification is explicit that local header sections remain unencrypted, and it is not a feature the built-in archiver on a typical desktop produces. Unless you have verified otherwise with the exact tool you used, assume the list is readable by anyone who holds the archive, including anyone it gets forwarded to later.
The macOS extras you did not ask for
If the archive is made on a Mac with the Finder's Compress command or the ditto utility, there is a documented additional behaviour: metadata that the destination filesystem cannot represent — resource forks, Finder information and extended attributes — is split off into AppleDouble format and stored as a parallel set of files in a __MACOSX directory inside the archive, with each companion named by prefixing ._ to the original file name. Recipients on Windows and Linux see that folder appear when they extract, which is how most people learn it exists.
The privacy-relevant part is what extended attributes can hold. They are the same channel the operating system uses for things like where a downloaded file came from, which is exactly the category covered on the off-file metadata page linked above. Whether any particular attribute ends up in a particular archive depends on the file and the tool, so this is a thing to check rather than to assume in either direction. The cheap habit is to look: if a listing of your archive shows __MACOSX entries, you are shipping more than your pictures.
Zipping is not stripping
Worth stating bluntly because the intuition runs the other way — compression feels like it must scramble or discard something. It does not. Compression is reversible by definition, and you can prove it to yourself in two commands: hash a photo, archive it, extract it somewhere else and hash the extracted copy. The digests match. Every EXIF tag, GPS coordinate, XMP packet and embedded preview that was in the file is still in the file.
So the order of operations matters and only runs one way. Clean each image first, then package. The tool on this page works on one JPEG or PNG at a time and rebuilds the picture from decoded pixels onto a canvas, which is why nothing from the original container survives into the output. It will not accept an archive: hand it a .zip and it answers that the file type is unsupported and that JPEG and PNG are what it handles. That is a structural limit of doing the work in a browser on a single image, not an oversight — and it means the batch discipline is yours to supply.
A packaging checklist
- Clean the images before they go anywhere near the archive. Produce the cleaned copies first and keep them separate from the originals, so there is no chance of sweeping an untouched file into the folder at the last minute.
- Make a fresh folder with a name you would be happy to read aloud. The folder name becomes an entry in the archive.
photosis fine. A client's full name, a case reference, an address or a project codename is a disclosure. - Rename the files. Camera originals are usually harmless, but exported names frequently carry dates, locations, sequence numbers, app names or subject names. Names are stored in the clear, so rename at this step rather than hoping nobody reads them.
- Flatten the structure. Nested folders are recorded as their own entries and reveal how you organise your work. One level is enough for almost every delivery.
- Archive from inside the clean folder. That way the stored paths begin at the neutral folder rather than at wherever it lived on your disk.
- Use the flags your tool gives you. With the Info-ZIP command-line
zipfound on most Linux systems and on macOS,-jstores the files without any directory prefix and-Xstrips most extra fields — in a before-and-after test the UID/GID and UTC subfields disappear and the extra-field length drops to zero. Both are worth using, and neither is a wipe: the names, the DOS timestamps and the permission bits are still there afterwards. - Consider the clock. If every entry carries today's date and your covering note says the photos were taken last spring, that is a discrepancy someone may notice. It usually reflects when you cleaned and packaged rather than anything meaningful, but decide whether you want to explain it, normalise the file times before archiving, or leave it alone.
- Read the listing before you send. List the finished archive and look at the output the way the recipient will. This takes seconds and catches nearly everything above.
Common mistakes and misconceptions
"I cleaned all the photos, so the delivery is clean." The photos are clean. The envelope you put them in was created after the cleaning step and has had no scrutiny at all. Two different objects, two different checks.
"Compressing it must have mangled the metadata." Compression is lossless and reversible; that is the entire point of an archive. A photo that goes in with GPS comes out with GPS.
"The archive has a password, so nobody can see anything." Ordinary ZIP encryption leaves the entry list readable. Names, paths, sizes and dates are all visible without the password.
"I will just drop the whole folder into an online cleaner." Leaving aside what that does to your confidentiality obligations, a browser-based image tool works on image files. This one takes a single JPEG or PNG and tells you plainly when a file is not one.
"Only the file names matter." Names are the loudest part, but the folder entries, the host OS, the account IDs in the extra fields and the timestamps are all in there too, and they are the sort of detail that corroborates other things rather than standing alone.
"This only applies to ZIP." Every archive format has the same job and therefore the same category of problem. A tar archive conventionally records ownership and permissions as well; other formats differ in the details. If you switch formats to dodge this, check what the new one writes rather than assuming it writes less.
"A shared cloud folder avoids the issue." It avoids the ZIP-specific fields and replaces them with its own: the folder name, the file names, upload times and, often, your account identity attached to each item. The wrapper changed. There is still a wrapper.
Related guides
See also:
Frequently asked questions
Does zipping photos remove their metadata?
No. A ZIP is a container, not a filter. Compression is reversible by definition: whatever goes in comes back out byte for byte, which you can confirm yourself by hashing a photo, adding it to an archive, extracting it again and hashing the extracted copy — the two digests match. Every EXIF field, every GPS coordinate, every XMP packet and every embedded thumbnail that was in the photo before you archived it is in the photo after someone extracts it. Zipping changes how many files the recipient downloads and how big the download is. It changes nothing at all about what is inside each file. Worse, archiving adds a second layer of information that was not there before, because the archive has to record a name, a path, a timestamp and a set of attributes for every entry in order to be able to put the folder back together.
What exactly does a ZIP archive record about my files?
More than most people expect. Each entry is introduced by a local file header carrying the file name, the sizes and a CRC-32 of the uncompressed data, and the same information is repeated in a central directory at the end of the archive so a listing can be produced without reading the whole file. The central directory additionally records a version made by field identifying the host operating system, the version of the archiving software, and internal and external file attributes — on a Unix-made archive that includes the permission bits. Names are stored as full relative paths, and folders usually get entries of their own, so the directory structure travels with the data. Timestamps are stored in the old MS-DOS format, which mimics the FAT filesystem's two-second resolution and has no notion of time zone. Optional extra fields can add more precise information: a universal time subfield (0x5455) carrying UTC timestamps and an Info-ZIP subfield (0x7875) carrying the numeric user and group IDs of the account that created the archive are both routinely written by the common command-line tool.
Does putting a password on the ZIP hide the file names?
Usually not. With ordinary ZIP encryption the entry data is encrypted but the directory of entries is not, so anyone holding the archive can list the file names, paths, sizes and modification dates without knowing the password — a standard unzip listing prints all of it. The format does define a central directory encryption feature, introduced in version 6.2 of the specification, which encrypts the metadata held in the central directory, but the specification itself notes that local header sections remain unencrypted, and the feature is not something the built-in archiver on a typical desktop produces. Treat the file list as public unless you have specifically verified otherwise, and assume that a password protects the pictures rather than their names. If the names themselves are sensitive, rename before packaging rather than relying on encryption.
How do I package a set of cleaned photos without adding new metadata?
Build the archive from a purpose-made folder rather than from wherever the photos happen to live. Clean each image first — this site's tool handles one JPEG or PNG at a time and will reject anything else, including a ZIP, with an unsupported file type message, because it rebuilds a picture from decoded pixels rather than editing a container. Then create a new folder whose name you are happy for the recipient to read, copy the cleaned files into it, and rename them to something neutral, since the names are stored in the clear. Flatten the structure so no client, project or user directories are recorded as entries. Archive from inside that folder so the stored paths start there, and if your tool offers flags to drop paths and strip extra attribute fields, use them — on the Info-ZIP command line those are -j and -X, which remove the directory prefixes and the UID/GID and UTC extra fields respectively, though the names, the DOS timestamps and the permission bits still remain. Finally, list the finished archive and read the output as the recipient would. If a name, a folder or a date in that listing tells a story you did not intend to tell, fix it and rebuild.
Remove EXIF data, GPS location and common photo metadata from a JPEG or PNG in your browser.
Try MetadataWipe free