Compression ratio or space saving?
Two ways to say how much smaller a file got

Ratio and saving: two views of one result

When a tool says it compressed a file, it may report a ratio such as 4:1 or a saving such as 75 percent. They convey the same information from different angles. The ratio compares the original with the result, and the saving states what share of the original disappeared.

Some tools and textbooks invert the ratio (12 ÷ 48 = 0.25, shown as 25 percent of original size). When reading a report, check which way round it is before comparing numbers.

Quick conversion between ratio and saving

The table shows diminishing returns. Going from 2:1 to 4:1 frees another quarter of the original, but going from 10:1 to 100:1 frees only 9 percentage points. That is why a spectacular-sounding ratio of 100:1 is often not worth much extra effort when 10:1 already removes nine tenths of the data.

What determines how well data compresses

Compressors find redundancy: repeated patterns, predictable sequences and unused precision. Text, logs, JSON and uncompressed images contain a great deal and often shrink to a quarter or less. Data that is already compressed or encrypted looks random, and there is little left to remove.

• Lossless methods (ZIP, gzip, PNG, FLAC) restore the exact original, so the ratio depends entirely on redundancy.
• Lossy methods (JPEG, MP3, H.264) discard detail people are unlikely to notice, and the ratio is a quality choice.
• Compressing a JPEG or an MP4 into a ZIP typically saves almost nothing.
• Level settings trade time for ratio: higher levels take longer for a small extra gain.

Compression in transit: does it save time?

Smaller is only faster if the saved transfer time outweighs the compression work. On a 20 Mbps link the 48 MB file takes 48 × 8 ÷ 20 = 19.2 seconds to send. At a 4:1 ratio the 12 MB version takes 4.8 seconds, and even if compressing and unpacking cost 2 seconds, the total of 6.8 seconds is far ahead.

The advantage shrinks on fast links or when the data is already compressed, where only CPU time is added. That is why web servers compress text such as HTML, CSS and JSON but leave images and video alone.

Using the number for planning

Ratio turns directly into storage and bandwidth. A 120 GB log archive at 5:1 needs 24 GB. Over a link, compressed transfers take proportionally less time, though compression costs CPU on both ends.

For web delivery, gzip or Brotli on text assets commonly reduces transfer size substantially, which is why servers enable it by default. The only way to know your own figure is to measure on your own files, since the ratio is entirely data-dependent.

Common reporting mistakes

• Quoting savings as a ratio: calling a 75 percent saving 75:1 instead of 4:1.
• Comparing results across different data, since a ratio only means something for the same input.
• Ignoring metadata and container overhead on very small files, where the compressed output can even be larger.
• Averaging ratios across files instead of totalling bytes first: the overall ratio is total original divided by total compressed.

Many files, levels and honest averages

Compressors usually offer levels from fast to maximum. Higher levels search harder for repeats and take more time, with the extra saving often a few percentage points. For routine work the default is the sensible pick, and maximum is for archives written once and read rarely.

When you report on a batch, total the bytes first. Suppose one file shrinks from 10 MB to 2 MB (5:1) and another from 90 MB to 60 MB (1.5:1). Averaging the two ratios gives 3.25:1, yet the batch went from 100 MB to 62 MB, a true ratio of about 1.61:1. The big file dominates, as it should.

• Solid archives compress files together and gain more across similar files, but make extracting one file slower.
• Deduplication finds identical blocks across files and complements compression.
• Check that tools report the same way round before comparing two products.

Reading ratios quoted by tools and vendors

Headline figures such as up to 90 percent smaller describe a best case on friendly data. They are real, but they say little about your files. Ask what the test set was, whether the format was lossless, and whether the baseline was a fair one, such as an already optimised file or a bloated original.

Media shows the gap well. A 24 MP photo is 72 MB as raw 8-bit RGB, and a JPEG of it might be around 6 MB. That is 12:1, a saving of about 92 percent, but it is lossy: the original cannot be restored exactly. A lossless PNG of the same image typically lands far higher than the JPEG, since lossless methods can only exploit redundancy.

Compare like with like: same input, same direction of ratio, and a note on whether quality was preserved.

A last practical point concerns decompression. Some methods compress slowly but unpack quickly, which suits data written once and read many times, while others favour speed in both directions and fit logs and live streams. Think about which side of the pipeline is the bottleneck, and about the memory a decompressor needs, before picking the format. A slightly lower ratio that your servers can unpack without strain is usually the better engineering choice.