Reduce ZIP File Size

This tool targets a narrow but common problem: a ZIP that is larger than it needs to be because of weak compression and operating-system clutter. It fits best for archives of text, code, CSV, logs, SVGs, office documents (the XML inside DOCX/XLSX), and other uncompressed content that DEFLATE can still squeeze. If your archive was created by a tool that stored files without compression, or assembled on a Mac that scattered metadata throughout, recompressing at maximum level often trims a meaningful slice off the total.

Practical situations where it helps: getting a project archive under an email attachment ceiling, fitting a ZIP inside a web form's upload limit, tidying a build or source bundle before distribution, and cleaning a folder export before handing it to a colleague. The before-and-after breakdown also answers a separate question many people have when a ZIP feels too big: which files are actually driving the size, so you know whether the problem is the compression or one large asset.

It is not the right tool for media-heavy archives. A ZIP full of photos, video, or MP3s is already near its floor, and you should expect single-digit-percent savings at most. For those, the realistic path is compressing the source files first with a dedicated image or video tool, then re-zipping.

You drop or select a single .zip file (up to 300 MB). The tool reads it in your browser, scans the contents, and shows the current size along with a count of files that are already compressed and therefore unlikely to shrink. Nothing is sent anywhere — the archive is parsed locally with JSZip, and it leaves no trace once the tab closes. You then press Reduce, watch a recompression progress bar, and the optimized archive downloads automatically as <name>-optimized.zip.

Two things happen during processing. First, recognized system junk is stripped out: .DS_Store, the __MACOSX folder, Thumbs.db, and desktop.ini. Second, every remaining file is re-stored with DEFLATE at maximum level (9), so anything previously stored uncompressed or weakly compressed gets a fresh pass. The result panel reports before size, after size, and a saved percentage, plus how many junk files were removed.

What it deliberately does not do: it does not transcode or re-encode the contents of images, audio, video, or PDFs — it only repacks them. It does not remove duplicate files automatically (it surfaces them, but cleanup is a separate step), does not repair damaged archives, does not split large output, and does not add or change passwords. File and folder structure inside the archive is preserved exactly.

The most common disappointment is expecting a media archive to shrink. JPG, PNG, GIF, WebP, HEIC, MP4, MOV, MP3, AAC, FLAC, PDF, and nested ZIP/RAR/7z files are already compressed internally; recompressing them in a ZIP container yields little or nothing, and the saved figure may read under 1 percent. The pre-scan warning about already-compressed files is your signal that this is happening — treat it as guidance, not a defect.

A second pitfall is assuming the tool deduplicates or repairs. Identical copies of a file will each be recompressed and kept; you will need a duplicate-finder or a remove-files step to drop them. Likewise, a corrupted ZIP that will not open elsewhere may simply fail to load here rather than being healed. Maximum-level recompression of a large archive is also CPU-bound and runs entirely on your machine, so a 300 MB archive will take noticeably longer than a small one, especially on a phone or older laptop.

Finally, remember the output is a new file with an -optimized suffix; it does not overwrite your original. If your real goal was removing a specific big file rather than shaving compression, the size breakdown tells you what to target with a different tool instead of optimizing repeatedly for diminishing returns.

Start with the numbers the tool shows: confirm the after size and saved percentage are what you expected, and read the saved figure against the already-compressed warning — a small saving on a media archive is normal, while a tiny saving on a text or code archive suggests the source was already well compressed. Verify the junk-removal count matches what you intended to drop, then open the downloaded -optimized.zip and confirm it extracts cleanly with your usual archive tool, with the folder structure and file count intact.

Spot-check a few files after extraction, particularly anything important: open a document or image to confirm it is byte-for-byte the same content, since the tool repacks rather than alters files. If your reason for shrinking was a specific limit — an email cap or a form's maximum upload size — measure the new file against that limit directly rather than assuming the percentage cleared it.

For archives tied to official, financial, or legal use, do a manual verification pass: extract the optimized ZIP in a clean location, compare the file list and sizes against the original, and open the key documents yourself to confirm completeness and integrity before submitting or distributing. Automated recompression should make a file smaller, not change its meaning, and a brief manual check is the only way to be sure nothing essential was among the removed junk or affected by the repack.