How to ratio calculator vs unzip -v / 7z l
- Step 1Map the CLI command to the tool —
unzip -v archive.zipandzipinfo -v archive.zipprint length, size, ratio, and method per entry — that's exactly what the calculator's CSV columns are. The browser tool is the GUI equivalent with sortable output. - Step 2Note the format scope —
7z lhandles ZIP, 7z, RAR, tar, and more. The calculator handles ZIP only — it reads the ZIP central directory and rejects other formats withNot a valid ZIP archive.. For 7z/RAR ratios you need the CLI or a conversion step first. - Step 3Compare the ratio definition —
unzip -v's ratio is percent saved, same as the calculator's(1 − compressed/uncompressed) × 100.7z l's percentage in some views is compressed-as-percent-of-original (the inverse). Don't be surprised the two CLIs phrase it differently — the calculator matches the unzip convention. - Step 4Choose by machine constraints — On a corporate laptop with no shell access or no install rights, the browser tool just works. On a build server you already control,
unzip -vpiped into your script is faster for bulk runs. - Step 5Choose by output shape — Need a spreadsheet to hand to a colleague or attach to a ticket? Download the calculator's CSV. Need a value inside a shell pipeline?
unzip -v | awkkeeps you in the terminal. - Step 6Choose by volume — One or a few ZIPs: the browser tool is faster end-to-end (no scripting). Thousands of archives or files over 2 GB: stay with the CLI, or for many ZIPs at once use batch-compression-report on Pro+.
Ratio Calculator vs the common CLI listers
All three read ZIP central-directory sizes; they differ in format scope, output shape, and scriptability.
| Capability | JAD Ratio Calculator | unzip -v / zipinfo | 7z l |
|---|---|---|---|
| Formats | ZIP only | ZIP only | ZIP, 7z, RAR, tar, gz, xz… |
| Reads | Central directory (no decompress) | Central directory | Archive headers |
| Per-entry ratio | Yes (ratio column, % saved) | Yes (% saved) | Yes (varies by view) |
| Per-entry method | Yes (method column) | Method column | Method column |
| Output | CSV file + metric chips | Fixed-width terminal text | Fixed-width terminal text |
| Install required | None (browser) | Yes (unzip) | Yes (7-Zip / p7zip) |
| Upload | Never (client-side) | Local | Local |
| Scriptable / bulk | One file (Pro: 20) | Yes (shell) | Yes (shell) |
| Max size | 2 GB (paid tiers) | OS/disk limited | OS/disk limited |
When to pick which
A quick decision matrix by context.
| Your situation | Best choice | Why |
|---|---|---|
| Locked-down laptop, no install rights | JAD Ratio Calculator | Runs in the browser; nothing to install |
| One ZIP, want a sortable spreadsheet | JAD Ratio Calculator | CSV output, no awk needed |
| Need ratios for a .7z or .rar | 7z l | JAD is ZIP-only |
| Thousands of archives in a script | unzip -v / 7z l | Shell loops, no per-file UI |
| Many ZIPs at once, in-browser | batch-compression-report (Pro+) | Aggregates multiple ZIPs |
| Archive over 2 GB | CLI | JAD caps at 2 GB |
Cookbook
The same archive, measured both ways, so you can see the numbers line up.
Same archive, same numbers
unzip -v and the calculator read the same central-directory fields, so length, size, ratio, and method agree (modulo how each rounds and labels).
$ unzip -v project.zip Length Method Size Cmpr Name 104857 Defl:N 23110 78% src/app.js 51200 Defl:N 11008 79% src/util.js JAD CSV (project-ratios.csv): name,uncompressedSize,compressedSize,ratio,method src/app.js,104857,23110,78.0%,Deflate src/util.js,51200,11008,78.5%,Deflate
CLI ratio phrasing differs from the calculator
7z's default listing can show the compressed size as a percentage of the original (the inverse of 'percent saved'). The calculator always reports percent saved, matching unzip. Same bytes, different framing.
7z l style (compressed as % of original): 22% unzip -v / JAD (percent saved): 78% They describe the same entry: 104857 -> 23110 bytes 23110 / 104857 = 22% retained 1 - 0.22 = 78% saved <- JAD's column
A 7z file the calculator can't read
7z l handles native 7z; the calculator does not. Reach for the CLI or convert to ZIP first.
$ 7z l backup.7z # works, lists entries + ratios JAD calculator on backup.7z: Error: "Not a valid ZIP archive." If you must use JAD, convert first: /archive-tools/archive-format-converter -> .zip then drop the .zip onto the calculator.
Turning unzip -v into a CSV vs just using JAD
To get a spreadsheet from the CLI you post-process the fixed-width output. The browser tool skips that step entirely.
CLI route:
unzip -v a.zip | tail -n +4 | head -n -2 \
| awk '{print $8","$1","$3","$4}' > out.csv
# brittle: column positions, header/footer trimming
JAD route:
drop a.zip -> Download -> a-ratios.csv
# already CSV, already has method + SUMMARYBulk across an entire directory of ZIPs
For hundreds of archives, the shell loop is the right tool. In-browser, the closest equivalent is the batch report on Pro+.
CLI: for z in *.zip; do echo "== $z =="; unzip -v "$z"; done JAD (Pro+, multiple ZIPs at once): /archive-tools/batch-compression-report -> one combined report across all dropped ZIPs
Edge cases and what actually happens
You need ratios for a 7z / RAR / tar archive
Rejected: not a valid ZIPThe calculator is ZIP-only; 7z l is the right CLI for those formats. JAD rejects non-ZIP input with Not a valid ZIP archive.. Either use the CLI, or convert with archive-format-converter and run the calculator on the resulting ZIP.
7z's percentage looks inverted vs unzip
By designSome 7z listings show compressed size as a percentage of the original (22%), while unzip and the calculator show percent saved (78%). Both are correct; they're complements (saved = 100 − retained). The calculator follows the unzip 'percent saved' convention.
Archive over 2 GB
Rejected: tier limitThe calculator caps at 2 GB even on Developer, and enforces the cap before processing with a clear per-job error. The CLIs are limited only by disk. For huge archives, list with unzip -v / 7z l instead.
Thousands of archives to measure
By designThe calculator reads one ZIP per run (Pro allows 20 files). A shell loop around unzip -v scales to thousands. For many ZIPs in one browser pass, batch-compression-report on Pro+ aggregates them, but heavy automation is a CLI job.
Encrypted entries with no password to hand
SupportedBoth approaches read sizes from the directory without decrypting, so ratios appear for AES entries without a password. The calculator labels them method AES; unzip -v shows the method too. Neither needs the password just to list ratios.
Output needed inside a shell pipeline
By designIf the next step is grep/awk/jq, stay in the CLI — unzip -v | awk keeps the value in the pipe. The calculator's CSV is great for spreadsheets and tickets but isn't a stdin/stdout citizen.
ZIP64 archive (entries > 4 GB or > 65,535 entries)
Sentinel sizesThe calculator doesn't parse ZIP64 extra fields, so very large entries read as 0xFFFFFFFF sentinels and counts wrap at 65,535. unzip -v and 7z l handle ZIP64 correctly — prefer the CLI for such archives.
No CLI available on the machine at all
SupportedThis is exactly where the browser tool wins: a kiosk, a customer's laptop, a restricted VDI with no shell. Load the page, drop the ZIP, read the ratios — no install, no admin rights, no upload.
Frequently asked questions
Does the calculator give the same numbers as unzip -v?
Yes for ZIPs. Both read the same central-directory size fields, so length, compressed size, and percent saved match. Rounding to one decimal and the method label wording are the only cosmetic differences.
Why does 7z show a different percentage?
7z's listing often reports compressed size as a percentage of the original (e.g. 22%), the inverse of percent saved (78%). The calculator and unzip both report percent saved. Subtract one from 100 to convert.
Can the calculator read 7z, RAR, or tar like 7z l can?
No. It reads the ZIP central directory only and rejects other formats with Not a valid ZIP archive.. Use 7z l for those, or convert to ZIP with archive-format-converter first.
Is the browser tool slower than the CLI?
For a single ZIP, end-to-end it's often faster because there's no scripting — it reads directory metadata only (no decompression). For thousands of files in a loop, the CLI wins on raw throughput and automation.
Does either approach upload my archive?
No. The CLI runs locally; JAD's calculator runs in your browser and never uploads the file. Both keep the archive on your machine.
What's the file-size ceiling compared to the CLI?
The calculator caps at 50 MB (Free), 500 MB (Pro), or 2 GB (Pro-media/Developer), enforced before processing. CLI tools are limited only by disk and OS, so they win for very large archives.
Can I script the calculator like I script unzip?
There's no public HTTP API. On Pro+ the logic can run via the local @jadapps/runner (a headless browser), but for true scripting across many files, unzip -v/7z l in a shell loop is simpler.
How do I get a CSV from the CLI?
You'd post-process unzip -v output with awk/sed — brittle because of fixed-width columns and header/footer lines. The calculator gives you the CSV directly, already including the method column and a SUMMARY row.
What about measuring many ZIPs at once in the browser?
Use batch-compression-report on Pro+, which accepts multiple ZIPs and produces a combined report. The single-file Ratio Calculator handles one archive per run.
Do the tools agree on which entries are directories?
Yes in spirit: the calculator excludes directory entries (zero size) from rows and totals; unzip -v lists them with zero length. Neither lets folders skew the overall ratio in a meaningful way.
Which is better for sharing results with a teammate?
The browser tool — download the CSV and attach it. Terminal output needs copy-paste cleanup; the CSV opens straight into a spreadsheet for sorting and annotation.
If the CLI repairs and the calculator doesn't, what do I do with a corrupt ZIP?
Repair first, then measure. Use corrupted-zip-repair (or zip -FF on the CLI) to recover the central directory, then run the calculator on the repaired file.
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.