A ZIP file does two separate things, and almost all the confusion around it comes from treating them as one. It bundles many files into a single file, and it compresses them. The first always works. The second works only sometimes, and knowing when saves a lot of wasted effort.
ZIP’s standard method looks for repetition. When a sequence of bytes has appeared before, it stores a short reference — “the same 40 bytes that appeared 300 bytes ago” — instead of the bytes themselves.
It is lossless: unzip the file and every byte comes back identical. Nothing is approximated, which is why ZIP is safe for documents, spreadsheets and code in a way that image or audio compression is not.
And because it works on repetition, the savings depend entirely on how repetitive the content is.
Large savings — often 70% to 95%:
Almost nothing — 0% to 3%:
The reason is the same for the whole second list: those formats are already compressed. The repetition has been removed once, and there is nothing left for ZIP to find. Compressing already-compressed data occasionally produces a file very slightly larger than the original, because the archive adds its own bookkeeping.
This explains the most common disappointment with ZIP: you select 200 MB of holiday photos, zip them, and the archive is 199 MB. Nothing is broken. That is the correct result, and no setting will change it.
This is worth knowing because it explains several of the entries above at once.
A .docx, .xlsx or .pptx is a ZIP archive containing XML files. An EPUB is a ZIP archive containing HTML. In every case, rename the file to .zip and you can open it and look at the parts.
Zipping a folder of Word documents therefore bundles them usefully and compresses them hardly at all — you are zipping zips.
Even with no size reduction, the bundling has real value:
But if the goal is genuinely a smaller file and the contents are photos, video, audio or PDFs, zipping is the wrong tool. Compress the files themselves — that is where the size actually lives.
This matters and is widely misunderstood.
ZipCrypto is the original password method from 1989. It is thoroughly broken. Tools exist that recover the contents in seconds to minutes, and the attack does not need to guess your password. If a ZIP is protected this way, treat it as unprotected.
AES-256 is the modern method, and it is genuinely strong. But support is uneven: not every tool offers it when creating an archive, and some older tools cannot open one. If you are encrypting something that matters, confirm which method your tool used — many default to the weak one for compatibility.
And one thing neither method fixes by default: the list of filenames is usually visible without the password. Anyone holding the archive can see that it contains salary-review-2026.xlsx, even if they cannot open it. Some tools can encrypt the file list as well; most do not do it unless asked.
If you exchange archives between Windows and Mac with Chinese, Japanese or Korean filenames, you will meet this one.
The ZIP format has no reliable, universally-followed rule for which character encoding filenames use. A Windows tool may write them in the system’s local encoding; a Mac unzipping it assumes UTF-8 and produces unreadable garbage where the names should be. The files themselves are perfectly intact — only the names are mangled.
Practical mitigations: use a tool that explicitly writes UTF-8 filenames, or name files in ASCII when an archive will cross platforms, or use a format with a stricter encoding rule. It is not a bug in your copy — it is a gap in the format that has been there for decades.
Archives created on a Mac often contain a __MACOSX folder and scattered .DS_Store files. They hold Mac-specific metadata, they are harmless, and they look like clutter or an error to everyone on Windows. Most compression tools have an option to exclude them, which is worth switching on before sending an archive to someone else.