Why Does My Compressed File Look the Same Size?

You compress a folder expecting a noticeably smaller file, and instead the resulting ZIP or 7Z comes out almost exactly the same size — sometimes even a touch larger than the original. This isn't a malfunction in your compression tool; it's a direct and predictable consequence of how compression mathematically works, and once you understand why, it becomes easy to predict in advance.

The short answer

This applies identically to every mainstream archive format — ZIP, RAR, and 7Z all rely on the same underlying principle, so switching formats won't rescue an already-compressed folder either. The behavior you're seeing is a property of the source data, not a limitation specific to whichever tool you happen to be using.

Compression algorithms work by finding and eliminating redundant data — repeated patterns, predictable structures, statistically likely sequences. Some file types are already heavily compressed at the format level by the time you're trying to compress them again, meaning there's little to no redundancy left over for a ZIP or 7Z compressor to find and remove. You can't meaningfully compress something that's already near its information-theoretic minimum size.

Which file types compress well

• Plain text files (.txt, .csv, .log) — highly repetitive at the character level, compresses extremely well
• Source code (.js, .py, .swift, etc.) — repeated keywords, whitespace, and patterns compress similarly well to plain text
• Uncompressed documents (.docx, .xlsx) — these are technically ZIP containers internally already, but often still have compressible slack left in them
• Uncompressed audio (.wav) and images (.bmp, .tiff, RAW camera formats) — these store raw, unprocessed data with significant redundancy
• Database dumps and other structured data files (.sql, .json, .xml) — highly repetitive structure compresses very effectively

Which file types barely compress at all

• JPEG images (.jpg) — already uses its own lossy compression internally, leaving almost nothing redundant behind
• MP4/MOV video files — heavily compressed already via codecs like H.264 or HEVC, which are specifically engineered to remove redundancy
• MP3/AAC audio files — compressed at the format level using algorithms designed for exactly this purpose
• Already-compressed archives (.zip, .7z, .rar) — compressing a ZIP again gains essentially nothing and can occasionally make the result slightly larger due to added overhead

If your folder is mostly photos and videos from your phone, expect the compressed archive to come out close to the original total size — and that's entirely correct, expected behavior, not a sign that the compression tool failed.

Why compress these files at all, then?

Even with little to no size reduction, archiving still has real, separate value. It bundles many individual files into a single transferable unit, which is far more convenient for emailing or uploading than dozens of loose files. It preserves the original folder structure and file metadata exactly. And — if you add a password — it adds a genuine layer of protection that a loose, unprotected folder of files simply doesn't have. Compression (smaller size) and bundling/securing (convenience and protection) are two entirely separate benefits, and the second one applies fully regardless of whether any size reduction happens at all.

Want to actually see compression work?

Try compressing a folder of plain text files, source code, or spreadsheets with a tool that supports 7Z at a high compression level — you'll typically see a real, visible difference, often 50% or more depending on the specific content. Unzipr supports adjustable compression levels for exactly this kind of comparison, free for ZIP and through PRO for 7Z's stronger LZMA2 algorithm, with instant preview so you can see exactly what went into an archive without waiting for a full extraction first.

The concept of entropy, explained simply

The underlying idea behind all of this has a formal name in information theory: entropy, a measure of how much genuinely unpredictable, non-redundant information a file contains. High-entropy data — already-compressed files, encrypted data, or truly random data — has little to no exploitable pattern left, since a compression algorithm's job is fundamentally about predicting and eliminating patterns. Low-entropy data — repetitive plain text, uncompressed images with large flat-color areas, structured data with repeated field names — has plenty of predictable pattern for an algorithm to exploit. This is precisely why a plain-text file with the word "the" appearing five hundred times compresses beautifully (the algorithm learns that pattern and encodes it far more efficiently than five hundred repeated instances of the full word), while an already-compressed JPEG has had exactly that kind of redundancy squeezed out of it already, during its own internal compression process, leaving nothing predictable behind for a second pass to find.

A simple test you can run yourself

To see this principle directly rather than just taking it on faith: create a plain text file containing the same sentence repeated a thousand times, and compress it. You'll likely see compression ratios of 90% or higher, since the redundancy is extreme and obvious. Now take a random JPEG photo of similar file size and compress it the same way — the result will barely shrink, often by only a percent or two. Both outcomes are the compression algorithm working exactly as designed; the difference lies entirely in how much genuine redundancy existed in the source data to begin with, not in any difference in how well the tool performed.

Troubleshooting

• Compressed file is actually larger than the original: normal for small files or already-compressed content, due to the fixed overhead every archive format adds for its internal structure (file headers, checksums, directory listings).
• Want to test compression but unsure what's "compressible": as a rule of thumb, if you can open a file in a plain text editor and it looks like readable text rather than gibberish, it will compress well. If it's already a media format (image, audio, video) or another archive, expect minimal gains.

A realistic scenario: compressing a photography portfolio for delivery

Picture a photographer delivering a client shoot as 200 edited JPEGs, and compressing the whole folder into one ZIP before uploading, expecting a meaningfully smaller file to speed up the client's download. In practice, the resulting ZIP will land close to the sum of the original JPEG sizes, sometimes even a touch larger due to archive overhead across two hundred separate files. This isn't a failure of the workflow — the ZIP still serves its real purpose here, bundling two hundred individual files into one manageable download and preserving folder structure and filenames exactly as organized, which matters far more to the client's experience than a modest size reduction that archive compression was never going to deliver on JPEGs in the first place.

Frequently asked questions

Is there a way to compress JPEGs or videos further without quality loss? Not through archive compression — any further size reduction on already-compressed media requires re-encoding at a lower quality setting (which is lossy and degrades the file) rather than lossless archive compression, which has nothing left to remove.

Does the compression level setting matter if my files don't compress well anyway? Not much in that case — a higher compression level mainly helps on genuinely compressible content. On already-compressed media, "Fast" and "Ultra" settings will produce nearly identical results, just at different speeds.

Why does a ZIP of mixed file types sometimes compress a bit even when most files are media? Because the small portion of compressible content in the mix (filenames, metadata, any accompanying text files) still gets compressed normally — you're seeing the aggregate result of a mostly-incompressible batch with a few compressible items pulling the average down slightly.

Why some tools claim better results on media files anyway

You may encounter software claiming to dramatically shrink photo or video libraries — worth being clear about what's actually happening in those cases, since it's not the same thing as archive compression. These tools typically re-encode the media itself at a different (usually lower) quality setting, or convert to a more efficient modern codec entirely, such as converting older JPEGs to the newer, more efficient AVIF or WebP formats, or re-encoding video with a more modern codec like HEVC. This genuinely can produce meaningfully smaller files, but it's a fundamentally different operation from archive compression — it involves re-processing the actual image or video data, which can introduce a real (if sometimes visually subtle) quality change, unlike the mathematically lossless guarantee that ZIP or 7Z compression provides. If a tool promises dramatic size reduction on photos or videos specifically, it's worth understanding whether it's doing lossless archiving (won't help much, as covered throughout this guide) or lossy re-encoding (will help, but changes the actual media data).

A practical takeaway

Before compressing a large folder expecting a dramatic size reduction, take thirty seconds to glance at what's actually in it. A folder of photos and videos will barely shrink no matter which tool or settings you use — that's expected, and worth knowing in advance so you're not left wondering if something went wrong. A folder of documents, code, or spreadsheets is exactly where compression earns its keep.