Compression Ratio Calculator
Compute the compression ratio, space saving, and compression factor from any two of the three quantities. Supports both lossless and lossy workflows, with reference values from real codecs and file formats.
Lossless vs. lossy compression
Lossless codecs (ZIP, gzip, PNG, FLAC) reconstruct the original data bit-for-bit. Their ratios are limited by the data's inherent redundancy — typically 2–5× on text, 1.5–3× on source code, 2–3× on binaries. Lossy codecs (JPEG, MP3, H.264) throw away information the human eye or ear cannot perceive, achieving ratios of 10–100× at the cost of perfect reconstruction. The same calculator handles both — the ratio is just a number.
Compressing already-compressed data fails
ZIP a JPEG and the "compressed" file will typically be larger than the original — CR < 1. High-entropy data (encrypted files, already-compressed video, random bytes) has no exploitable redundancy, so the codec's framing overhead adds bytes instead of removing them. This is why you should never zip a zip file, and why PNG is a poor choice for photographic images (the underlying data is already high-entropy).
Ratio is meaningless without quality
A lossless ratio of 3× and a lossy ratio of 30× are not comparable — the lossy one discarded information to get there. When comparing codecs, always ask "at what quality?". JPEG can hit a ratio of 50× at quality 30 with visible artifacts, or 8× at quality 95 with no perceptible loss. The published "10× compression" for MP3 is meaningless without knowing the bitrate. Our calculator gives the pure ratio; the codec and quality settings are the context.
Theoretical limits — Shannon entropy
No lossless algorithm can compress below the Shannon entropy of the source. For a truly random file, that limit is exactly 1× — you cannot compress it at all. For English text the entropy is about 1.5 bits per character vs. 8 bits stored, so the theoretical maximum ratio is roughly 5×. Real-world gzip achieves 2–3× on English text; PPM and modern context-mixing compressors get closer to 4×. The gap between theoretical and practical is the room left for better algorithms.
How to Use This Calculator
Pick what you want to solve for, then enter the other two quantities. The calculator keeps everything in sync via CR = Original / Compressed.
1. Choose what to solve for
Ratio (CR), compressed size, or original size. The field being solved becomes read-only and shows the computed value; the other two stay editable.
2. Enter values or drag sliders
Type any number or drag the slider. Both work — the calculator updates on every input. Values are in the currently selected unit.
3. Pick the display unit
B, KB, MB, GB, or TB. The ratio is unitless and unaffected; the unit only changes how the two sizes are labelled and displayed.
4. Read the result and verdict
The result card shows the solved value plus a quality badge, from "expansion" (CR < 1, bad) through "modest", "good" (ZIP-class), "high" (JPEG-class), "very high" (video-class), and "extreme" (raw video).
5. Check the visual comparison
The bar chart shows original and compressed sizes side by side, with the saved space marked. In Advanced mode you also get a chart of saved percentage vs. ratio, showing the diminishing returns as CR grows.
6. Switch to Advanced for depth
Advanced mode adds the saved-percentage chart, a sensitivity check, and companion metrics including compression factor, uncompressed bits per compressed byte, and entropy-equivalent checks.
What This Tool Offers
Built around the definition CR = Original / Compressed — the standard measure of how much a codec reduced the input.
Three-way solving
Solve for ratio, compressed size, or original size. The calculator rearranges the formula based on whichever you pick.
Unit selection
Express both sizes in B, KB, MB, GB, or TB. The ratio itself is unitless and never changes with the unit selection.
Compression-quality verdict
Classifies the ratio from "expansion" through "modest", "good", "high", "very high", and "extreme", with reference to real codec families.
Visual size comparison
A bar chart of original vs. compressed sizes with the saved space highlighted, plus an Advanced chart of saved percentage vs. ratio.
Companion metrics
Compression factor, space saved percentage, uncompressed bits per compressed byte, ratio of remaining data, and comparison to common codec benchmarks.
Reference tables
Typical ratios for common codecs and formats, a saved-percentage lookup for common ratios, and a full variable reference.
Reference Tables & Conversions
A saved-percentage lookup for common ratios, typical ratios for real codecs, and a full variable reference.
Ratio ↔ saved % lookup
Typical Compression Ratios by Format
Representative ratios for common codecs. Lossy ratios are for "visually or audibly transparent" settings; higher ratios are achievable at the cost of quality.
| Format / Codec | Type | Typical CR | Space saved | Notes |
|---|---|---|---|---|
| gzip (text) | Lossless | 2 – 4× | 50 – 75% | General-purpose; fast; the default for HTTP transfer |
| bzip2 (text) | Lossless | 3 – 5× | 67 – 80% | Slower than gzip but stronger compression |
| xz / LZMA | Lossless | 4 – 8× | 75 – 87% | Very strong; used for software distribution |
| Zstandard (zstd) | Lossless | 2 – 6× | 50 – 83% | Adjustable speed/ratio trade-off; used by Facebook |
| ZIP (mixed files) | Lossless | 2 – 4× | 50 – 75% | Depends heavily on content; already-compressed files barely shrink |
| PNG (images) | Lossless | 2 – 3× | 50 – 67% | Good for screenshots and graphics; poor for photos |
| FLAC (audio) | Lossless | 1.5 – 2× | 33 – 50% | Perfect reconstruction of CD-quality audio |
| JPEG (photographs) | Lossy | 8 – 20× | 87 – 95% | Quality-dependent; typical q=85 gives ~10× |
| MP3 (audio) | Lossy | 8 – 12× | 87 – 92% | 320 kbps MP3 vs. 1411 kbps CD audio → 4.4×; lower bitrates go much further |
| Opus (audio) | Lossy | 10 – 20× | 90 – 95% | Better than MP3 at the same bitrate |
| WebP (images) | Lossy/Lossless | 8 – 30× | 87 – 97% | 25–35% smaller than JPEG at the same quality |
| H.264 / MP4 (video) | Lossy | 50 – 200× | 98 – 99.5% | Compared to raw uncompressed video frames |
| H.265 / HEVC (video) | Lossy | 100 – 400× | 99 – 99.75% | Roughly 50% better than H.264 at the same quality |
| AV1 (video) | Lossy | 120 – 500× | 99.2 – 99.8% | Royalty-free successor to HEVC; best current ratio |
| Encrypted / random data | — | < 1× | Negative | Compression makes it larger due to framing overhead |
Space Saved by Ratio
Quick lookup table: saved % = (1 − 1/CR) × 100.
| Compression Ratio | Space Saved | Compressed Size (fraction of original) | Typical use |
|---|---|---|---|
| 1 : 1 | 0.00% | 100% | No compression |
| 1.5 : 1 | 33.33% | 66.67% | FLAC audio |
| 2 : 1 | 50.00% | 50.00% | PNG, light gzip |
| 3 : 1 | 66.67% | 33.33% | gzip on text |
| 5 : 1 | 80.00% | 20.00% | Strong gzip, light JPEG |
| 10 : 1 | 90.00% | 10.00% | JPEG q=85, MP3 128 kbps |
| 20 : 1 | 95.00% | 5.00% | JPEG q=60, high-quality MP3 |
| 50 : 1 | 98.00% | 2.00% | Low-bitrate video |
| 100 : 1 | 99.00% | 1.00% | Standard H.264 video |
| 200 : 1 | 99.50% | 0.50% | High-efficiency HEVC / AV1 |
| 1,000 : 1 | 99.90% | 0.10% | Very aggressive video compression |
Variable Reference
| Symbol | Meaning | Typical range | Formula |
|---|---|---|---|
| O | Original (uncompressed) size | > 0 | input |
| C | Compressed size | > 0 | input |
| CR | Compression ratio | 0.5 – 1000 | O / C |
| saved | Space saved percentage | −100% – 99.9% | (1 − 1/CR) × 100 |
| factor | Compression factor (X : 1) | 0.5 : 1 – 1000 : 1 | CR : 1 |
| bits/byte | Uncompressed bits per compressed byte | 0 – 8 | 8 / CR |
What Does the Compression Ratio Measure?
The compression ratio quantifies how much a codec reduced the size of its input. It is the single most common metric for comparing compression algorithms and settings: gzip achieves 3× on English text, JPEG achieves 10× at visually transparent settings, H.264 achieves 100× on video compared to raw frames. Ratio alone does not tell the whole story — you also need to know whether the compression was lossless or lossy, and at what quality setting — but it is the starting point for every discussion of compression performance.
The Compression Ratio Formula
The defining relationship is straightforward:
Rearranging to solve for the other quantities:
Original Size = Compressed Size × CR
Space Saved (%) = (1 − 1/CR) × 100
Compression Factor = CR : 1
A ratio of 5 means the compressed file is one-fifth the size of the original — equivalently, you saved 80% of the space. A ratio of 0.9 means the "compressed" file is actually larger, which happens on already-compressed or high-entropy data.
Compression Ratio Variables
| Symbol | Meaning | Notes |
|---|---|---|
| O | Original size | Raw input before any compression |
| C | Compressed size | What gets stored or transmitted |
| CR | Compression ratio | O / C — dimensionless, unit-independent |
| saved | Space saved % | (1 − 1/CR) × 100 |
| factor | Ratio notation | e.g., "5:1" or "5×" |
Lossless vs. Lossy Compression
Every compression algorithm falls into one of two categories, and the ratio means very different things for each. Lossless codecs (ZIP, gzip, PNG, FLAC, Bzip2, LZMA, Zstandard) guarantee that decompressing the output gives back exactly the original bytes. Their ratios are bounded by the source's Shannon entropy — a truly random file cannot be compressed at all, while English text can typically reach 3–5×. Lossy codecs (JPEG, MP3, H.264, Opus, WebP-lossy) discard information that human perception will not miss, achieving ratios that are far higher (10–100×+) but at the cost of a decompressed output that is only an approximation.
The distinction matters because a lossless 3× and a lossy 3× are not comparable achievements. The lossy codec "paid" for its ratio with perceptual quality — if it had been constrained to reconstruct perfectly, it would achieve far less. When you compare two lossy codecs by ratio, you must always ask "at what quality?" — an MP3 at 64 kbps compresses to 22× but sounds terrible; at 320 kbps it compresses to 4.4× and sounds indistinguishable from CD.
Why Compression Fails on Already-Compressed Data
If you try to compress a JPEG with gzip, the "compressed" output will typically be larger than the original — a ratio below 1. The reason is that the JPEG has already had its redundancy removed by the JPEG codec; what remains is close to the entropy limit of the image. gzip can only find patterns that are actually present in the byte stream, and a JPEG's bytes look almost random. The same applies to encrypted files, hash digests, and — famously — the output of any good compression algorithm. This is why layered compression (zip-a-zip) never works, and why well-designed backup tools skip compression on file types that are already compressed.
There is an information-theoretic floor on how small a file can get. Shannon's source coding theorem states that the minimum expected length of a lossless encoding is the source's entropy. For a file containing n bytes of true randomness, that entropy is exactly n × 8 bits — no algorithm can represent it in fewer bits. The corollary is that a codec can only win by exploiting redundancy: statistical patterns, repeated substrings, or structure in the data. When there is no structure, there is no win.
Compression Ratio Calculation Examples
CR = 100 / 20 = 5.00 : 1
Saved = (1 − 1/5) × 100 = 80.00%
C = O / CR = 1,000 / 10 = 100 MB
Saved = (1 − 1/10) × 100 = 90.00%
O = C × CR = 5 × 50 = 250 MB
Saved = (1 − 1/50) × 100 = 98.00%
CR = 5 / 6 = 0.833 : 1
Saved = (1 − 1/0.833) × 100 = −20.00% (expansion!)
Frequently Asked Questions
It depends entirely on the data type and whether lossy compression is acceptable. For lossless compression of English text, 3–4× is very good (PPM, LZMA). For source code, 4–6× is achievable. For binaries and executables, 2–3× is typical. For photographic images, lossless PNG gets 1.5–2.5×, but lossy JPEG at visually transparent settings gets 8–15×. For video, 100× or more is standard. There is no single "good" number — the right question is "compared to what alternative?" For a given codec and data type, comparing against typical published ratios tells you if your results are expected or anomalous.
Because the input was already compressed or had no exploitable redundancy. When you ZIP a JPEG, MP3, MP4, or encrypted file, the codec finds no patterns it can exploit and has to add its own framing overhead (headers, checksums, metadata), making the result larger. This is exactly what a compression ratio below 1.0 represents. The general rule: only compress data that has not been compressed before. If you are not sure, try it — but be prepared for the output to be slightly larger than the input on high-entropy files.
No. The compression ratio is unitless, because it is a ratio of two quantities in the same unit. If you halve a 100 MB file down to 50 MB, the ratio is 2. If you express the same file as 100,000 KB and 50,000 KB, the ratio is still 2. If you express it as 104,857,600 bytes and 52,428,800 bytes, still 2. This is why the unit selector only changes the display labels — the ratio is invariant. The space-saved percentage is also unit-independent.
Yes, unambiguously — but only if both actually deliver 10:1 on the same input. In practice, a lossless codec cannot usually reach 10:1 on real-world data (its ratio is bounded by the source entropy). A lossy codec that achieves 10:1 has discarded information to get there. So the comparison "10:1 lossless vs. 10:1 lossy" is almost never a fair fight — the lossless ratio simply won't reach that number on most inputs. When it does — say, on highly redundant data like a bitmap of a solid color — it is strictly better, because the reconstruction is exact and cannot be improved upon.
They mean the same thing, just written differently. A "compression factor of 5" and a "compression ratio of 5:1" both mean the compressed output is one-fifth the size of the input. "Ratio" is typically written as a fraction with a colon (5:1) while "factor" is written as a single number or with a multiplication sign (5× or "5-fold"). The two are interchangeable. Our calculator uses "ratio" for the primary value and shows the factor form alongside it.
Space saved = (1 − 1/CR) × 100%. For CR = 2, saved = (1 − 0.5) × 100 = 50%. For CR = 5, saved = (1 − 0.2) × 100 = 80%. For CR = 10, saved = (1 − 0.1) × 100 = 90%. As the ratio grows, saved percentage approaches 100% asymptotically — CR = 100 gives 99% saved, CR = 1,000 gives 99.9%. This is why doubling the ratio from 10 to 20 does not double the perceived improvement: it goes from 90% saved to 95%, only 5 percentage points better. The "space saved" metric flattens out quickly, which is why engineers usually compare ratios directly.
Yes — compressed size = original size / ratio. This is one of the three solve directions the calculator supports: switch the "Solve for" toggle to "Compressed size", enter the original size and ratio, and the compressed size is computed. Similarly, switch to "Original size" and enter the compressed size and ratio to get the original. All three permutations are supported and stay in sync as you edit any field.
Variables
| Symbol | Quantity | Unit |
|---|---|---|
| Ratio | Compression ratio | |
| Original Size | Size before compression | bytes |
| Compressed Size | Size after compression | bytes |
What it means
The compression ratio measures the effectiveness of a data compression algorithm. It is defined as the size of the original data divided by the size of the compressed data. A ratio of 2:1 means the compressed data is half the original size. Higher ratios indicate better compression, but they depend on the data type and the algorithm (lossy vs. lossless). For example, text files often achieve ratios of 3:1 to 5:1, while images can be compressed much more (e.g., JPEG). The ratio is used to compare compression methods and to estimate storage savings. However, it is not the only metric; compression speed, memory usage, and quality (for lossy) are also important. In practice, compression ratios are often expressed as percentages (e.g., 25% of original size). Understanding the ratio helps in choosing the right compression for given data, balancing bandwidth and storage costs. It is also used in networking to assess the impact of compression on transmission time.
Worked example
Compression Ratio – Two Examples
Real‑World| Parameter | Value |
|---|---|
| Original size | 10 MB |
| Compressed size | 2 MB |
| Parameter | Value |
|---|---|
| Original size | 1 MB = 1024 KB |
| Compressed size | 200 KB |
Common mistakes
- Original vs. compressed size: Put original size in the numerator, compressed in the denominator.
- Ratio notation: Often expressed as “original:compressed” (e.g., 4:1).
- Lossy vs. lossless: Compression ratio for lossy (e.g., JPEG) may not reflect quality degradation.
- Size units: Both sizes must be in the same unit (e.g., bytes, KB).
- Reversibility: A high compression ratio may indicate a lossy algorithm if the original cannot be exactly reconstructed.
Applications
Compression ratio is the ratio of the original file size to the compressed file size, indicating how much data reduction has been achieved. It is a key metric in data storage, transmission, and archiving. Engineers use compression ratio to evaluate different compression algorithms (e.g., ZIP, JPEG, MP3), to select appropriate settings for a given dataset, and to balance quality against size. In web development, it influences page load times and bandwidth usage. In multimedia, it affects storage requirements and streaming quality. Understanding compression ratio helps in optimising storage costs, in reducing network traffic, and in designing efficient file formats.
- Evaluation of compression algorithms and settings
- File archiving and backup optimisation
- Web performance optimisation (image, text compression)
- Multimedia encoding (audio, video, images)
- Storage cost reduction and bandwidth saving
Related calculators · Data Encoding & Conversion
Recently updated formulas
Suggest an improvement
Found a mistake? Have a better example? Let us know.
You may send up to 3 suggestions per 24 hours.