Compression Ratio
The compression ratio describes how much smaller an archive is than the data it was built from. It is the single number most people reach for when asking "how much does zip compress" or comparing one format against another. A ratio of 3:1 (read "three to one") means the original input was three times the size of the compressed output; equivalently, the archive shrank the data to roughly 33% of its original size, a 67% reduction.
Be aware that the phrase is used loosely. The same ratio may be reported three ways: as a pure ratio like 3:1, as a percentage reduction like "67% smaller", or as the compressed size as a percentage of the original like "33% of original". These are arithmetically the same fact expressed differently, so always check which convention a tool is using before comparing numbers.
What actually determines the ratio
Compression works by finding and removing redundancy — repeated byte sequences, common words, long runs of the same value. Anything rich in repetition compresses well; anything already stripped of redundancy does not. The data itself matters far more than the tool you run it through.
- Compresses very well (often 3:1 to 10:1): plain text, source code, CSV, JSON, XML, HTML, spreadsheets, databases, and log files. These are full of repeated tokens, whitespace, and structural patterns that dictionary and entropy coders exploit.
- Compresses poorly, often not at all: JPEG, PNG, WebP, MP4, MP3, AAC, OGG, and any archive that is already compressed —
.zip,.7z,.gz,.xz,.bz2. The redundancy was removed when the file was first encoded, so a second pass finds almost nothing to squeeze out. This is exactly why "zipping a zip" does essentially nothing — the file is already near its entropy limit. - In between: executable binaries and some binary database formats compress moderately, typically 2:1 to 4:1, because they contain repeated structures and padding but also high-entropy sections.
Why ZIP has a "store" method
Every entry in a ZIP archive records the compression method used on it in its local header. The two you will almost always see are 1 for DEFLATE (actual compression) and 0 for store (the bytes are written verbatim, with no compression). Other method codes exist in the spec, but DEFLATE and store dominate in practice. ZIP tooling picks store automatically for entries that would not benefit from compression — typically already-compressed media — because running them through DEFLATE would waste CPU and risk *increasing* the size slightly (the compressor adds its own overhead when it finds nothing to compress). This per-entry choice is why a single ZIP can contain both tightly-squeezed text files and byte-identical media files. See DEFLATE for how the compressed entries are actually encoded.
Algorithm and level settings
Beyond the data type, two knobs change the ratio you get.
The algorithm matters. DEFLATE, defined in RFC 1951, combines LZ77 string matching with Huffman entropy coding and is the ZIP default and a decades-old baseline. Newer or more aggressive algorithms do better: LZMA as used in .7z routinely beats DEFLATE by 10–40% on text and code, and Zstandard and Brotli are competitive too. If you want the smallest archive and compatibility is not a concern, .7z or .tar.xz will usually win over .zip.
The compression level is a speed-versus-size tradeoff. DEFLATE levels run 1 (fastest, largest output) through 9 (slowest, smallest output); LZMA and others expose similar presets. Higher levels search harder for matches, so they shrink the output more at the cost of build time. The gain from level 1 to level 9 is real but modest — typically a few percent — while the time cost can be large. For interactive use, level 6 is a common default.
How to calculate it
The percentage reduction, the most common reporting style, is computed from the original (uncompressed) size and the compressed (archived) size of the same data:
**percentage reduction = (original - compressed) / original * 100**
For example, a 100 MB source folder that compresses to 25 MB gives (100 - 25) / 100 * 100 = 75% reduction. The ratio form is original / compressed = 100 / 25 = 4:1. The compressed-as-percentage form is compressed / original * 100 = 25 / 100 * 100 = 25% of original. All three describe the same archive.
When you measure, compare the uncompressed byte count of the source files against the stored size of the archive (including its headers and per-entry metadata). For a ZIP that contains many small files, the per-entry and central-directory overhead can add up, which is one reason an archive of thousands of tiny files shows a worse ratio than the same bytes packed as one large file. The archive-formats reference covers how ZIP, 7z, tar, and others lay out that metadata.
Frequently asked questions
What is a good compression ratio?
It depends entirely on the data. For text, source code, CSV, JSON, spreadsheets, and databases, a good result is anywhere from 3:1 to 10:1 (70–90% reduction). For already-compressed media like JPEG, MP4, or MP3, expect close to 1:1 — there is almost nothing left to remove. A ratio is only "good" or "bad" relative to the type of data you put in.
Why doesn't my zip get much smaller?
Almost always because the contents are already compressed. JPEG, PNG, MP4, MP3, and other .zip, .7z, or .gz files have had their redundancy removed at encode time, so a second compression pass finds little to squeeze. A second common cause is thousands of tiny files, where ZIP's per-entry and central-directory overhead offsets the gains. Check the mix of file types inside the archive.
What is the difference between DEFLATE and store?
They are the two method codes a ZIP entry most commonly carries. store (method 0) writes the bytes verbatim with no compression — used for files that won't shrink. DEFLATE (method 1), defined in RFC 1951, applies LZ77 plus Huffman coding to actually compress the data. ZIP tools normally pick store automatically for already-compressed entries, so a single archive can mix both methods. See DEFLATE for the algorithm details.
How is compression ratio calculated?
The percentage reduction is (original - compressed) / original * 100. Take a 100 MB source that compresses to 25 MB: (100 - 25) / 100 * 100 = 75% reduction. The same result can be expressed as a ratio (100 / 25 = 4:1) or as compressed size as a percentage of the original (25 / 100 * 100 = 25% of original). Always confirm which convention a tool is reporting before you compare two numbers.