You select 200 holiday photos totalling 800 MB, compress them, and get a 797 MB zip. Nothing malfunctioned. ZIP did exactly what it does, and there was nothing there for it to do.
What compression actually removes
Lossless compression works by finding repetition. The Deflate algorithm that ZIP uses does two things: it replaces repeated byte sequences with a reference to the earlier occurrence, and it gives the most frequent bytes shorter codes.
Both need patterns. Feed it English text, where the appears constantly and only a few dozen byte values are ever used, and it has enormous room to work. Feed it data that has already had its patterns removed, and there is nothing to find.
That is the whole explanation, and it predicts everything:
| File type | Typical saving | Why |
|---|---|---|
| Text, CSV, logs, code | 70-90% | Hugely repetitive |
| XML, JSON, SVG | 70-85% | Repeated tags and keys |
| BMP, WAV, uncompressed TIFF | 50-80% | Raw, no compression yet |
| PDF with text | 5-20% | Streams already deflated |
| DOCX, XLSX, PPTX | 0-3% | Already zip files |
| JPEG, PNG, GIF, WebP | 0-3% | Already compressed |
| MP3, MP4, AAC | 0-2% | Already compressed |
A .docx compressing by nothing surprises people until you remember it already is a zip archive. Zipping it is asking Deflate to compress its own output.
So why zip photos at all
Because size is not the only reason, and for photos it is not the reason at all.
One thing instead of many. A single 200 MB attachment is manageable. Two hundred separate files is not, for you or the recipient.
Structure survives. Folder hierarchy and filenames are preserved. Email attachments and many upload forms flatten everything otherwise.
Integrity checking. Every entry carries a CRC-32 checksum, so extraction fails loudly if the archive was damaged in transit rather than producing quietly corrupt files.
Encoding is preserved. Text files keep their bytes exactly, instead of being helpfully converted by something in the middle.
So creating a zip of a photo set is still the right move. Just do not expect the size to change, and do not waste time trying "maximum" compression on it.
The encryption is two different things
ZIP supports encryption, and the format has two schemes with very different properties.
ZipCrypto, the original, is cryptographically broken. It is vulnerable to a known-plaintext attack, which is easy to mount because archives often contain predictable content. Treat it as no protection at all.
AES-256, added later, is strong. But support is inconsistent: Windows Explorer's built-in zip handling cannot open AES-encrypted archives, so your recipient may need a separate tool.
If the contents are sensitive, name the files neutrally, use AES-256, and send the password through a different channel than the archive.
A sensible default
- Ask what you are optimising. Fewer files, or fewer bytes? They need different actions.
- If it is bytes and the content is media, resize and re-encode rather than zip.
- If it is bytes and the content is text, zip it and enjoy the 80%.
- If it is convenience, zip it regardless of what happens to the size.
- If the folder is mostly CSV exports, consider whether merging them into one file is what the recipient actually wants. Twelve monthly exports in an archive is usually a worse answer than one file with a month column.
Point five is the one worth pausing on, because sending an archive is frequently a way of passing an unfinished job along.
In practice: zip folders of documents, code and spreadsheets to save space, zip photos and videos only to bundle them into one download, and unzip an archive before judging its size, because what is inside usually explains it.