How to compress a ZIP file to a specific size (2 MB, 25 MB, 100 KB)
Last reviewed 2026-05-05. "Compress this ZIP to under 25 MB so I can email it" sounds like one operation, but it is three. The output size of a ZIP archive is decided by what is inside the archive, by how compressible those bytes are, and by the deflate level chosen at write time. None of those is dialled to "exactly N MB". This guide names what actually controls ZIP output size, and the order to apply the tools on this site so you hit a target cap (2 MB, 25 MB Gmail / Outlook attachment cap, 100 KB upload limit) on the first or second try.
Why ZIP output size is non-deterministic
A ZIP archive is a container format with per-file deflate compression. Three things decide the byte count you get out, and you control only the first two:
- What is in the archive. If you put a 10 MB JPG into ZIP, you get something close to 10 MB out. JPG is already compressed; deflate cannot meaningfully shrink already-compressed bytes. The same is true of MP4, HEIC, PNG, MP3, ODT, DOCX, XLSX, modern PDF - all of these store their data in a compressed inner format. ZIP wrapping them barely reduces size.
- How compressible the bytes actually are. Plain text, CSV, raw logs, BMP, WAV, uncompressed TIFF, source code - these are highly compressible. A 10 MB text log can land near 1 MB after deflate. So the same archive can shrink 10x or 1.05x depending on what is inside it; there is no single "ZIP ratio".
- The deflate level. Most online ZIP tools and the OS-level "Send to compressed folder" use level 6 (default). Level 9 (maximum) takes longer to compute and gives you a few percent more shrink on compressible content - never more than 5-10%. Level 1 (fastest) gives you back almost the same size as no compression at all. The level slider does NOT magically hit a target cap.
Putting it together: a folder of JPG photos will not meaningfully shrink no matter what deflate level you pick, because the bytes are already compressed. A folder of CSV exports might shrink 8x at level 9 vs 7x at level 6. Your "compress to under 25 MB" task therefore is not a deflate-level choice - it is a question of what content you put in.
The two-step workflow that actually hits a cap
For 90% of "I need this under N MB for email / upload / a portal" cases, the path is: shrink the largest contributors before you ZIP, then ZIP the smaller versions. The order matters - ZIPing first and then trying to shrink the ZIP is the slow path because it loses you the per-file optimization that compress-image and heic-to-jpg can deliver.
Step 1: identify and shrink the largest contributors
Open the folder. Sort by size, descending. The top three files almost always account for >80% of the total. They are usually photos, scanned PDFs, video, or HEIC source from an iPhone. Apply the right tool per file type:
- JPG / PNG photos. Run Compress Image. The quality slider goes from 1 to 100; for "good enough to email" the 60-75 band drops a 4 MB JPG to 600-900 KB without visible quality loss. Read Compress JPEG without losing quality - quality vs size for the slider behaviour.
- HEIC photos from iPhone. Run HEIC to JPG. HEIC is already efficient, but most email clients reject .heic attachments outright; converting to JPG at quality 75 trades 5-15% size growth for universal openability. Read How to convert HEIC to JPG step by step for the per-file flow.
- Scanned / image-heavy PDFs. A scanned PDF is photos in a PDF wrapper. Re-export at lower DPI or recompress images first. The site's PDF tools cover how to flatten a PDF and the PDF editing ladder for the right tool order.
- Video. ZIPing video does almost nothing. Re-encode through Video Converter with a lower bitrate first; MP4 vs WebM for web covers the codec trade-off.
- Plain text / CSV / logs. No pre-step needed; these compress 5-10x inside ZIP at level 6 already.
Step 2: ZIP the smaller files
Open ZIP File, drag in the shrunken files, and download the archive. The default level (6) is the right choice for almost all cases - level 9 gains you 1-3% more on compressible content and adds CPU time you do not get back. Read How to choose a compression level if you have a specific reason to push level 9.
Now check the archive size against your cap.
If the archive is still over the cap: split, do not retry
If your two-step workflow puts the archive at, say, 32 MB but Gmail caps at 25 MB, do NOT keep raising the deflate level - you are at most 1-2 MB shy and level 9 will not save you. Two paths from here:
- Split the archive into multi-volume parts. Most desktop archivers (7-Zip, WinRAR, Keka) write multi-volume ZIP / 7z that the recipient reassembles automatically. For pure ZIP, set the volume size to your cap (25 MB for Gmail / Outlook attachments, 10 MB for older mail relays, 4 GB for FAT32 thumb drives). The online zip vs 7z vs rar guide names which format the recipient is most likely to support out of the box.
- Drop the largest remaining contributor. Sort the archive content by size again - if one file is 60% of the bytes, send it via a link (Drive, Dropbox, WeTransfer) and ZIP only the rest.
Either path is faster and more reliable than retrying compression. Read How to compress a folder for email for the full per-mailbox-cap reference.
Specific-cap recipes
Cap = 100 KB. Almost certainly an upload form (government portal, school assignment, job application). At this size, you are not compressing - you are choosing one or two photos and resizing them. Use Photo Editor to resize to 1200-1600 px wide, save as JPG quality 60, and ZIP only if the form requires .zip. A single resized JPG is usually under 100 KB on its own; ZIP wrapping adds 30 bytes of header.
Cap = 2 MB. Common for portal uploads, light email attachments. Run Compress Image at quality 70 on JPG, convert HEIC to JPG at quality 70, then ZIP. For 5-10 photos, the result almost always lands at 1.4-1.8 MB.
Cap = 25 MB. Gmail and Outlook default attachment limit. Run the two-step workflow at quality 75-80 (less aggressive). For folders of mixed photos and a few documents, this lands under 25 MB on the first try in most cases. If the source folder is >500 MB of HEIC, expect to split into volumes.
Cap = 10 MB. Some corporate / legacy mail relays. Same as 25 MB but quality 65 on photos and consider dropping non-essentials before the ZIP step.
What does NOT work and why
- "Just zip it twice." ZIPing a ZIP gains zero shrink - the inner ZIP is already deflate-compressed, and deflate cannot compress already-compressed bytes. The outer ZIP adds ~30 bytes of header and that is it.
- "Pick a higher compression level and retry." Going from level 6 to level 9 saves 1-5% on compressible content and 0% on already-compressed content. If you are 30% over the cap, level 9 will not get you there.
- "Use a different archive format - 7z is smaller." 7z (LZMA2) is genuinely smaller than ZIP (deflate) on compressible content - sometimes 30-50% smaller on text. But on photos / video / already-compressed content, 7z saves nothing either, and your recipient may not be able to open .7z without a third-party reader. The online zip vs 7z vs rar guide covers when the format swap is worth it.
- "Encrypt with a password to make it smaller." Encryption does not change file size - in fact it adds ~30 bytes of overhead per file. A password-protected ZIP is the same size as the unprotected one (modulo the header bytes).
FAQ
Why does the same folder zip to 18 MB on my laptop and 22 MB online?
Different deflate implementations make slightly different choices at the same level. macOS Finder, Windows Explorer, 7-Zip, and online tools each have a deflate library that picks slightly different match-finder parameters. The difference is rarely more than ±5%. If your online ZIP is materially larger, the online tool may be forcing level 1 (fastest) or repacking on a per-file basis.
Can I tell the ZIP tool "stop at 25 MB"?
No standard ZIP tool exposes a target-size flag - the format does not support it. What you can do is ask the tool to split the output into 25 MB volumes (multi-volume ZIP). Most desktop archivers expose this; many online tools do not.
The folder is 1.2 GB of HEIC photos. Can I email it as one ZIP?
Not under any cap. ZIP it after converting HEIC to JPG at quality 60-70 and you may land near 200-400 MB. That still needs a link share, not an email attachment. Use Drive / Dropbox / WeTransfer.
If I delete files from the ZIP after creating it, does the size shrink?
Yes. ZIP supports per-file delete. Most archivers (7-Zip, WinRAR, Keka, online ZIP File tool) let you remove individual files from an existing archive; the archive is rewritten without them and the size drops accordingly. This is the fastest fix when you are 1-2 MB over a cap and one file is non-essential.
Why is "compress zip file to 100kb" a thing if it almost never works?
The query reflects real upload-form limits (e-government portals, university applications, some corporate intake forms still cap attachments at 100-200 KB). The realistic answer is that you are not compressing - you are picking one or two files and resizing them down to that size. The ZIP wrapper is a packaging step, not a shrink step.
Related
- ZIP File (compress / create) - the tool referenced as Step 2 throughout this guide.
- Compress Image - the tool referenced as Step 1 for JPG / PNG photos.
- HEIC to JPG - the tool referenced as Step 1 for iPhone-source photos.
- How to compress a folder for email - per-mailbox-cap reference.
- How to choose a compression level - level 1 vs 6 vs 9 trade-offs.
- File compressor vs ZIP - what to pick - tool-class disambiguation.
- File compressor online - when to ZIP vs when to compress image - the order-of-operations decision.
- Compress JPEG without losing quality - quality vs size - how the JPG quality slider behaves.
- Online ZIP vs 7z vs RAR - which to pick - format choice for the recipient.
Why trust these tools
- Ten-plus years of web tooling. The freetoolonline editorial team has shipped browser-based utilities since 2015. The goal has never changed: get you to a working output fast, without an install.
- Truly in-browser - no upload. Every file-processing tool on this site runs in your browser through modern Web APIs (File, FileReader, Canvas, Web Audio, WebGL, Web Workers). Your photo, PDF, audio, or text never leaves your device.
- No tracking during tool use. Analytics ends at the page view. The actual input you paste, drop, or capture is never sent to any server and never written to any log.
- Open-source core components. The processing engines underneath (libheif, libde265, pdf-lib, terser, clean-css, ffmpeg.wasm, and others) are public and audit-able. We link to each one in its tool page's footer.
- Free, with or without ads. All tools are fully functional without sign-up. The Disable Ads button in the header is always available if you need a distraction-free run.