What a compressor is really doing
General-purpose compression — the DEFLATE algorithm inside ZIP and gzip — works on repetition. It replaces a sequence it has seen before with a short back-reference, then assigns shorter codes to more common bytes. Text is full of repeated words and predictable letter frequencies, so it collapses dramatically.
Now consider a JPEG. Its whole purpose was to remove that predictability: the encoder already found the redundancy and packed the result into something close to random bytes. Handing it to ZIP leaves nothing to find. This is not a limitation of ZIP specifically; it is a consequence of what compression is.
Which files shrink, and roughly how much
Approximate figures from ordinary content — your files will vary, which is exactly why a tool should measure rather than estimate:
- Plain text, logs, CSV, JSON, XML: 70–95% smaller. Highly repetitive and the best case for ZIP.
- SVG, HTML, CSS, source code: 60–85% smaller.
- BMP, TIFF, WAV: 50–80% smaller. These store raw samples with no compression of their own.
- PDF: 0–20%. Text-only PDFs may give a little; image-heavy ones give nothing.
- DOCX, XLSX, PPTX, HWPX: 0–5%. These are already ZIP archives. Renaming one to
.zipand opening it shows the XML parts inside. - JPEG, PNG, WebP, GIF, MP3, MP4, MOV: 0–2%. Already compressed. Any tool promising "50% off your MP4 by zipping" is not telling the truth.
ZIP is still worth using on that last group for a different reason: bundling. One archive is easier to send, preserves file names, and avoids the recipient losing the third of five attachments.
Find the real cause before compressing
A large file almost always has one dominant cause, and the fix depends on which:
- Look at what is inside. For an Office or HWPX document, copy it, rename the copy to
.zip, and open it. The media folder usually holds the answer: a 20 MB report is normally 19 MB of screenshots. - If it is images: compress or resize them before inserting, or re-insert them at display size. See the image compression guide. This is the single most common cause of oversized documents.
- If it is a PDF: the usual culprit is a scan stored as full-resolution images. Scanning at 200–300 dpi in greyscale instead of 600 dpi colour typically cuts the file by an order of magnitude.
- If it is video: resolution and bitrate dominate. Re-encoding 4K to 1080p is the real fix; nothing else will matter.
- If it is a database dump, log, or export: this is the ideal ZIP case. Expect a very large saving.
The email-attachment problem
Most mail providers cap attachments around 25 MB, and the encoding used for attachments inflates a file by roughly a third on the way — so a 20 MB file can be refused. Compressing a folder of already-compressed media will not rescue you. The reliable options are to reduce the source material (resize the images, lower the scan resolution), split the archive, or send a link instead of a file.
Things that do not work
Zipping twice. The second pass has nothing left to find and adds a container, so the file usually grows slightly.
Renaming an extension. Changing .png to .jpg changes nothing about the bytes; it only misleads whatever opens it.
Trusting a claimed ratio. A tool that shows a percentage before it has processed your specific file is showing you a marketing number. Ratios depend entirely on content.
How this site's tool behaves
The file tool builds a genuine ZIP archive in your browser using the platform's own compression, computing a CRC-32 for every entry. It deflates each file, then keeps the deflated version only if it is actually smaller; otherwise the file is stored uncompressed, which is what a correct ZIP writer does and what prevents an archive from being larger than its contents.
The percentage shown is measured from the finished archive, and the status line reports how many files were already compressed and stored as-is. When the saving is under 1% it says so plainly instead of dressing up a rounding error. Nothing is uploaded — the archive is assembled from bytes that never leave the page.