How to compression ratio calculator online for free
- Step 1Open the tool — Go to /archive-tools/compression-ratio-calculator. No account is needed for the free tier. The page loads a small JavaScript reader; nothing about your file is sent anywhere.
- Step 2Drop one ZIP file — Drag a single
.ziponto the dropzone (or click to pick one). This tool reads one archive at a time — it has no folder or batch mode. The file is read locally via the browser File API. - Step 3Confirm it is a ZIP — The calculator looks for a ZIP End-Of-Central-Directory record. A
.7z,.rar,.tar, or.tar.gzwill fail withNot a valid ZIP archive.— those formats have no ZIP central directory to read. Convert first with a sibling tool if needed. - Step 4Process — Click Process. There are no options to set — the schema for this tool is empty, so you will not see compression-level, password, or method controls. It walks the central directory and tallies sizes per entry.
- Step 5Read the metrics and CSV — The result panel shows four metric chips —
Files,Uncompressed total,Compressed total,Overall ratio— above a preview of the CSV. Skim the ratio column to find the entropy-dense files (ratios near 0%). - Step 6Copy or download the report — Use Copy to put the CSV on your clipboard, or Download to save
<archive>-ratios.csv. Open it in Excel, Numbers, or Google Sheets and sort byratioto rank files from best- to worst-compressing.
What the report contains
The CSV has one row per non-directory entry plus a trailing SUMMARY row. Directory entries are skipped because they carry zero size and would skew the totals.
| CSV column | Source in the ZIP central directory | Example value | Notes |
|---|---|---|---|
name | The entry path/filename field | src/app.js | Decoded as UTF-8 (non-fatal). Commas/quotes/newlines in a name are CSV-escaped automatically |
uncompressedSize | Uncompressed size (4-byte field) | 104857 | Bytes before compression. For ZIP64 entries over 4 GB this field is a sentinel — see the edge cases |
compressedSize | Compressed size (4-byte field) | 23110 | Bytes actually stored in the archive for this entry |
ratio | Computed: (1 − compressed/uncompressed) × 100 | 78.0% | Percent reduction, one decimal place. A zero-byte file (or zero uncompressed size) shows — |
method | Compression method code, mapped to a name | Deflate | Stored, Shrunk, Imploded, Deflate, Deflate64, BZIP2, LZMA, XZ, PPMd, or AES (encrypted) |
SUMMARY row | Totals across all non-directory entries | SUMMARY,12450003,3120441,74.9%, | name=SUMMARY, total uncompressed, total compressed, overall ratio, method blank |
Tier limits for the Ratio Calculator
Limits are enforced per job before processing. The per-archive entry limit is a documented cap for the archive tool family; the size limit is checked at run time and produces a clear error if exceeded.
| Tier | Max ZIP size | Max entries / archive | Files per job |
|---|---|---|---|
| Free | 50 MB | 500 | 1 |
| Pro | 500 MB | 50,000 | 20 |
| Pro-media | 2 GB | 500,000 | 100 |
| Developer | 2 GB | 500,000 | Unlimited |
| Enterprise | No limit | No limit | No limit |
Typical ratios you'll see (so the numbers make sense)
These are typical Deflate outcomes by content type. Use them to judge whether a low ratio is a problem or simply expected for already-compressed data.
| Content type | Typical ratio (percent reduction) | Why | What to do |
|---|---|---|---|
| Source code, logs, JSON, CSV | 60–85% | Highly repetitive text | Good — Deflate is working |
| HTML / CSS / SVG | 70–90% | Tag and whitespace redundancy | Good |
| Binary executables, .dll/.so | 30–60% | Mixed code and data | Expected |
| JPEG / PNG / GIF / WebP | 0–5% | Already entropy-coded | Store, don't re-deflate |
| MP3 / AAC / MP4 / H.264 | 0–3% | Already lossily compressed | Store, don't re-deflate |
| Nested .zip / .gz / .7z | 0–2% | Already compressed bytes | Re-zipping wastes CPU |
Cookbook
Real before/after the way the tool actually reports it — the CSV columns above, plus the metric chips. File names anonymised.
A mostly-text ZIP compresses well
A source-code archive. Deflate shrinks the text dramatically; the SUMMARY ratio is the number you quote.
Input: project-src.zip (Free tier, 4.1 MB) CSV output (project-src-ratios.csv): name,uncompressedSize,compressedSize,ratio,method src/app.js,104857,23110,78.0%,Deflate src/util.js,51200,11008,78.5%,Deflate README.md,8800,3520,60.0%,Deflate SUMMARY,164857,37638,77.2%, Metric chips: Files: 3 | Uncompressed total: 161.0 KB Compressed total: 36.8 KB | Overall ratio: 77.2%
Spotting an already-compressed file dragging the average down
A media-heavy ZIP. The JPEG was re-deflated for almost no gain; the calculator makes the wasted effort obvious so you can switch that entry to Stored on the next pack.
Input: assets.zip name,uncompressedSize,compressedSize,ratio,method logo.svg,18400,4600,75.0%,Deflate photo.jpg,2048000,2041800,0.3%,Deflate icons.css,9200,2300,75.0%,Deflate SUMMARY,2075600,2048700,1.3%, photo.jpg shows 0.3% — re-deflating an already- compressed JPEG gained ~6 KB for full CPU cost. Next pack: store JPEGs, deflate the text.
Stored entries report 0% by design
Entries written with method Stored are not compressed at all, so compressed == uncompressed and the ratio is 0%. That is correct, not a failure — common for already-compressed payloads.
name,uncompressedSize,compressedSize,ratio,method video.mp4,52428800,52428800,0.0%,Stored notes.txt,4096,1638,60.0%,Deflate SUMMARY,52432896,52430438,0.0%, The overall ratio is dominated by the huge Stored video. That's expected: the calculator reports the truth, it does not re-compress anything.
Sorting the CSV to rank worst-compressing files
Open the downloaded CSV in a spreadsheet and sort ascending by the ratio column to surface the entries that gained the least. Those are your candidates for Stored on the next archive build.
1. Download project-ratios.csv 2. Open in Excel / Sheets 3. Sort by `ratio` ascending (ignore the SUMMARY row) Worst compressors float to the top: photo.jpg 0.3% Deflate clip.mp4 0.0% Stored bundle.min.js 41.2% Deflate ... These are the files to mark Stored to save CPU.
A non-ZIP file is rejected, not mis-parsed
Hand it a .7z or .tar.gz and there is no ZIP central directory to read, so it fails fast with a clear message rather than returning garbage. Convert to ZIP first if you need ratios for those formats.
Input: backup.7z Result: Error "Not a valid ZIP archive." Fix: convert to ZIP first, then re-run. e.g. /archive-tools/archive-format-converter Then drop the resulting .zip onto the calculator.
Edge cases and what actually happens
Input is not a ZIP (7z, RAR, tar, gzip)
Rejected: not a valid ZIPThe calculator finds compression ratios by reading the ZIP central directory. A .7z, .rar, .tar, or .tar.gz has no such structure, so parsing returns zero entries and the tool throws Not a valid ZIP archive.. This is by design — it does not silently mis-read other formats. Convert to ZIP with archive-format-converter first, or check the real format with auto-format-detector.
A `.zip` that is actually a renamed file of another type
Rejected: not a valid ZIPRenaming backup.rar to backup.zip does not make it a ZIP. The calculator reads bytes, not the extension, so it still fails the central-directory check and reports Not a valid ZIP archive.. Run auto-format-detector to see the file's true format from its magic bytes.
Directory entries in the archive
By designFolder entries (names ending in /) carry zero size and are excluded from the CSV rows and from the SUMMARY totals so they don't skew the overall ratio. The Files metric chip therefore counts only real files, not folders.
Zero-byte file or zero uncompressed size
PreservedA file with zero uncompressed size cannot have a meaningful percentage (division by zero), so its ratio is reported as — rather than 0% or an error. It still appears as a row with its sizes; it simply has no ratio to show.
ZIP64 archive (entry over 4 GB, or over 65,535 entries)
Sentinel sizesThe reader uses the standard 32-bit central-directory size fields and 16-bit entry count; it does not parse the ZIP64 extra field. For an entry larger than 4 GB the size reads as the 0xFFFFFFFF sentinel and the ratio will be wrong, and an archive with more than 65,535 entries reports only the low 16 bits of the count. Such archives also exceed the per-archive entry cap on most tiers — keep individual entries under 4 GB for accurate ratios.
Encrypted / AES entries
SupportedBecause the tool reads only the central-directory sizes and method code, it reports ratios for encrypted entries without needing a password — the encrypted entry shows method AES (or its underlying method via the strong-encryption flag) and its stored vs uncompressed sizes. No decryption happens; only the directory metadata is read.
File larger than your tier's size cap
Rejected: tier limitEach job is size-checked before processing. Over the cap you get File "name.zip" exceeds the <tier> tier per-job limit (<size>). Upgrade for larger files. — 50 MB on Free, 500 MB on Pro, 2 GB on Pro-media/Developer. Upgrade or split the archive with archive-splitter.
Empty ZIP (valid EOCD, no entries)
Rejected: not a valid ZIPA ZIP with a valid End-Of-Central-Directory record but zero entries yields an empty entry list, and the tool throws Not a valid ZIP archive. because there is nothing to measure. There are no ratios to compute for an archive with no files.
Truncated or corrupt central directory
Invalid / partialIf the central directory is cut short or its signature is wrong mid-stream, the parser stops at the bad record. You may get fewer rows than the archive really contains, or a Not a valid ZIP archive. error if no EOCD is found. For recovery, try corrupted-zip-repair first, then re-run the calculator on the repaired file.
Self-extracting ZIP (.exe with a ZIP appended)
SupportedThe EOCD scan searches the last 64 KB of the file, so a ZIP appended after an executable stub is still found and measured. Sizes are read from the central directory regardless of the leading stub bytes.
Frequently asked questions
Does the Ratio Calculator upload my ZIP?
No. The file is read locally with the browser File API and parsed by JavaScript in the page; nothing about its contents is sent to a server. Open DevTools → Network while you process and you'll see no upload of the archive.
Which formats can it read?
ZIP only. It computes ratios by walking the ZIP central directory, which 7z, RAR, tar, and gzip don't have. Hand it any of those and it fails fast with Not a valid ZIP archive. rather than guessing. Convert to ZIP first if you need ratios for another format.
Does it decompress my files to measure them?
No. It reads the uncompressed and compressed size fields already stored in the central directory for each entry. That's why it's fast and why it works even on encrypted (AES) entries without a password — no data is decompressed or decrypted.
What's the maximum ZIP size and entry count?
Free: 50 MB and 500 entries, one file. Pro: 500 MB and 50,000 entries, up to 20 files. Pro-media: 2 GB and 500,000 entries, up to 100 files. Developer: 2 GB / 500,000 entries with unlimited files. The size cap is enforced before processing with a clear error.
How is the ratio calculated?
Per entry it's (1 − compressedSize / uncompressedSize) × 100, shown to one decimal as a percent (the percentage of bytes saved). The SUMMARY row applies the same formula to the totals across all non-directory entries. A zero uncompressed size shows —.
Why does a file show 0%?
Either it was written with method Stored (no compression — common for already-compressed payloads), or it's already entropy-dense (a JPEG, MP4, or nested ZIP) so Deflate couldn't shrink it. 0% is the truth about that entry, not a tool error.
Can I see the compression method per file?
Yes — the method column reports each entry's method: Stored, Shrunk, Imploded, Deflate, Deflate64, BZIP2, LZMA, XZ, PPMd, or AES for encrypted entries. Stored entries are uncompressed by design.
Are folders counted?
No. Directory entries have zero size and are skipped from both the CSV rows and the SUMMARY totals, so the overall ratio reflects actual files only. The Files metric counts files, not folders.
What output do I get, and can I open it in Excel?
A CSV named <archive>-ratios.csv with columns name,uncompressedSize,compressedSize,ratio,method plus a SUMMARY row. Use Copy to grab it or Download to save it, then open in Excel, Numbers, or Google Sheets and sort by ratio.
Are there any options or settings?
No. This tool's option schema is empty — there's no compression level, password field, or sort control in the UI. You drop a ZIP and press Process; the report is deterministic from the archive's directory.
Is there an API or CLI?
There's no public HTTP API for archive tools — they're browser-only. On Pro and higher tiers the same logic can run through the local @jadapps/runner (a headless browser the page auto-routes to), but there's no standalone REST endpoint to POST a ZIP to.
Which tool should I use to act on what the ratios reveal?
To re-pack media as Stored and text as Deflate automatically, use smart-archive-compressor. To compare levels and time cost, compression-level-optimizer. For a size breakdown by extension/folder, archive-size-analyzer; by type, file-type-breakdown.
Privacy first
Every JAD Archive tool runs entirely in your browser using fflate, @zip.js/zip.js, and the libarchive WASM bridge. Your archives never leave your device — verified by zero outbound network requests during processing.