File Compression Ratio Calculator
Calculate compression ratio and space savings between original and compressed file sizes.
Inputs
Compression Ratio
3.33:1
Space Saved
70.00%
Compressed Size (MB)
300.00
Space Saved (MB)
700.00
Step by step
Values used
Original Size (MB) = 1,000; Input Mode = Estimate from content type; Content Type = Text / source code / logs (~70% savings); Compressed Size (MB) = 300
Compression ratio and space saved
ratio = original / compressed; space_saved% = (1 − compressed/original) × 100
Compression Ratio
= 3.33:1
Space Saved
= 70.00
Compressed Size (MB)
= 300.00
Space Saved (MB)
= 700.00
How it works
Compression ratio (original:compressed) and space-saved percentage describe the same result two ways. How much a file actually compresses depends heavily on its entropy: plain text, logs and source code compress very well (~70% smaller) because of high redundancy; generic binaries and database dumps compress moderately (~20%); and already-compressed media formats like JPEG, MP4 and MP3 barely shrink further (~5%) because their encoders already removed most redundancy — recompressing them mostly wastes CPU time.
Formula
Compression ratio and space saved
ratio = original / compressed; space_saved% = (1 − compressed/original) × 100
- S_orig
- original size
- S_comp
- compressed size
Frequently Asked Questions
Why doesn't gzip shrink my JPEG or MP4 files much?
JPEG, MP4 and MP3 already apply strong lossy/entropy compression internally, so there's little statistical redundancy left for gzip's algorithm to exploit. Compressing an already-compressed file typically saves only a few percent and can occasionally even increase size slightly due to format overhead.
What's a good compression ratio for log files?
Text-heavy logs typically compress 4:1 to 10:1 (70-90% space saved) with gzip, and even better with algorithms like zstd or xz at higher settings, because of repeated timestamps, field names and common message patterns.
Does a higher compression ratio always mean a better choice?
Not necessarily — higher-ratio algorithms (like xz -9) trade significantly more CPU time and memory for modest extra savings over faster options (like gzip or zstd). For frequently-accessed data, a faster algorithm with a slightly lower ratio is often the better overall trade-off.