How to batch report vs shell loops over many archives
- Step 1Decide by format coverage — If your folder is all ZIPs, the browser tool gives you full per-entry stats. If it's 7z/rar/tar.gz and you need entry counts and internal sizes,
7z l/tar -tzvfin a loop is the better fit — JAD identifies those formats but won't enumerate their entries. - Step 2Decide by privacy and trust — Both run locally. Choose the browser tool when the archives are sensitive and you'd rather not pipe them through ad-hoc shell scripts, or when you're on a machine where you can't (or shouldn't) install CLI tools.
- Step 3Decide by output shape — Want a CSV you can open in Excel and sort by ratio? The browser tool emits exactly that. Want raw text to grep in a pipeline? The CLI is more composable. The browser CSV is itself pipe-friendly once downloaded.
- Step 4Decide by size and count — Per-file cap is 500 MB on Pro, 2 GB on Pro-media/Developer; batch count is 20 / 100 / unlimited. For thousands of archives or files larger than 2 GB, a CLI loop on a server is the right call.
- Step 5For ZIP audits, just drop the folder — Open /archive-tools/batch-compression-report on a Pro plan, drop the ZIPs, and download the CSV. No quoting, no escaping of spaces in filenames — the tool handles those and CSV-escapes the names for you.
- Step 6For deep or scripted needs, stay in the shell — Recursive scans, custom columns, archives over 2 GB, or wiring into CI all favour the CLI. The browser tool is a fast on-ramp, not a CI runner — there is no programmatic API for it today.
Browser Batch Report vs a shell loop
A like-for-like comparison for the task of summarising a folder of archives. "CLI loop" means a typical for-loop over unzip -l / zipinfo / 7z l with awk post-processing.
| Dimension | JAD Batch Report (browser) | Shell loop (unzip -l / 7z l) |
|---|---|---|
| Install required | None — just a browser | unzip, p7zip, tar, etc. on PATH |
| Output | One CSV, fixed 10-column schema | Free text you parse yourself |
| ZIP per-entry stats | Full (central directory) | Full |
| 7z / rar / tar entry stats | Format detected only, no entry list | Full (7z l, tar -t) |
| Format detection | Magic bytes, extension-independent | Depends on tool / file |
| Encrypted flag | Yes/no per archive (GP flag bit 0) | unzip -l hints; varies by tool |
| Privacy | Local, never uploaded | Local |
| Max file size | 500 MB Pro / 2 GB Pro-media+Dev | Disk/RAM bound — effectively unlimited |
| Best for | Ad-hoc audits, locked-down machines, ZIP folders | Recursive/CI/huge/non-ZIP at scale |
What each tool reports per archive
The browser report's columns versus what you'd typically scrape from CLI output.
| Metric | Batch Report column | CLI equivalent |
|---|---|---|
| Format | format (magic-byte sniff) | file archive.zip |
| On-disk size | sizeBytes | ls -l / stat |
| Compressed size | compressedSize (ZIP only) | sum of unzip -l compressed column |
| Entry count | entryCount (ZIP only) | unzip -l footer count |
| Ratio | ratioPercent (ZIP only) | computed from totals |
| Largest entry | largestEntry + largestEntrySize | unzip -l | sort -n | tail |
| Encryption | encrypted true/false | unzip -l / 7z l flags |
| Errors | error column, batch continues | non-zero exit; loop may abort |
Cookbook
Side-by-side: the same job done with a shell loop and with the browser tool, so you can see what each gives you.
Summarising a folder of ZIPs
The classic CLI loop versus one drop. For an all-ZIP folder the outputs are comparable in content; the browser tool just hands you a clean CSV.
Shell: for f in *.zip; do echo -n "$f,"; unzip -l "$f" | tail -1 done Browser Batch Report → batch-compression-report.csv: filename,format,sizeBytes,compressedSize,entryCount,ratioPercent,... a.zip,zip,262144,200000,8,23.7%,... b.zip,zip,524288,401408,12,23.4%,... The CSV is ready for Excel; the shell output needs awk to become a table.
A folder mixing ZIP and 7z
Where the CLI clearly wins: 7z internals. The browser tool identifies the 7z but leaves its entry columns empty.
Shell (full 7z entry list): 7z l vault.7z # lists every entry, sizes, ratios Browser Batch Report row for the same file: vault.7z,7z,2097152,0,0,—,,0,false, Takeaway: for 7z/rar/tar entry-level detail, use the CLI; for a ZIP-folder summary or just format+size of mixed files, use the browser tool.
Locked-down laptop, no install rights
The scenario the browser tool was built for: you can't apt/brew anything, but you have Chrome.
Constraint: corporate laptop, no admin, p7zip not installed. CLI path: blocked (can't install). Browser path: open /archive-tools/batch-compression-report, drop the ZIPs, download batch-compression-report.csv. Done. Nothing was uploaded; nothing was installed.
A corrupt archive mid-batch
Shell loops can abort on a non-zero exit unless you guard each iteration; the browser tool always finishes and marks the bad file.
Shell (naive — aborts on first failure if set -e): set -e for f in *.zip; do unzip -l "$f"; done # stops at the corrupt one Browser Batch Report (always completes): good.zip,zip,...,false, bad.zip,error,131072,0,0,,,0,false,Invalid central directory next.zip,zip,...,false, You see exactly which file failed, and the rest still got reported.
Too big for the browser tool
When an archive exceeds 2 GB, the browser path can't take it — this is where the CLI is the correct tool.
File: monolith-backup.zip — 4.6 GB Browser path: over the 2 GB per-file cap on every plan → can't process. CLI path: zipinfo -t monolith-backup.zip # works, disk-bound. Rule of thumb: under 2 GB and ZIP-heavy → browser; over 2 GB or thousands of files → shell loop on the box that holds them.
Edge cases and what actually happens
You expected 7z entry counts from the browser tool
By designThe browser report reads per-entry stats only from the ZIP central directory. A 7z, rar, or tar.gz is detected and named in the format column but shows 0 entries and a — ratio. If you need 7z internals, that's a job for 7z l — the CLI is genuinely better here, not a fallback.
Filenames with spaces or commas
PreservedA common shell footgun is unquoted filenames with spaces breaking a loop. The browser tool sidesteps this entirely — you drop files, and it CSV-escapes names containing commas or quotes so the output stays valid. No quoting discipline required.
Recursive scan of nested folders
ManualA shell find . -name '*.zip' recurses for free. The browser tool works on the files you drop. If your archives are spread across subfolders, gather them first, or use the CLI for recursive discovery. To peer inside archives-within-archives, the sibling /archive-tools/nested-archive-extractor flattens one ZIP at a time.
CI / scheduled pipeline integration
Not availableThere is no programmatic API for the batch report today — it's an interactive page. For CI, a shell loop over zipinfo/7z l (or a small Node script using fflate) is the right approach. The browser tool is for humans doing ad-hoc audits, not for cron jobs.
Free-tier user trying to compare
Pro requiredUnlike a CLI, which is free once installed, JAD's batch report requires a Pro plan. On Free you'll get an upgrade prompt. If cost is the deciding factor for a one-off, the CLI is free; if convenience and privacy on a no-install machine matter more, Pro pays for itself quickly.
Archives larger than 2 GB
400 too largePer-file caps are 500 MB (Pro) and 2 GB (Pro-media/Developer). Beyond 2 GB the browser path can't process the file at all, while a CLI loop is bounded only by disk and RAM. Choose the shell for multi-GB archives.
You want a non-CSV output (JSON for a tool)
CSV onlyThe browser tool emits CSV only. If your pipeline wants JSON, a small script around unzip -l/fflate gives you full control of the shape. The CSV is easy to convert, but the tool itself won't emit JSON.
Misnamed archive (extension lies)
SupportedWhere unzip may choke on a .zip that's really a 7z, the browser tool reads magic bytes and reports the true format, so a mislabelled file is still correctly identified in the report. This is one place the browser tool is more forgiving than a format-specific CLI command.
Encrypted archives
SupportedBoth approaches can list an encrypted ZIP's central directory without the password; the browser tool flags encrypted=true. Neither decrypts. To go further on cipher type, /archive-tools/encrypted-archive-detector identifies ZipCrypto vs AES, which raw unzip -l does not surface clearly.
ZIP64 / >65,535 entries
PartialModern CLI tools handle ZIP64 fully. The browser report reads 32-bit EOCD fields, so very large entry counts or sizes that rely on ZIP64 may be reported short. For archives in that territory, prefer the CLI.
Frequently asked questions
Is the browser tool faster than a shell loop?
For a modest folder of ZIPs, the difference is negligible — both just read indexes. The browser tool's real advantage is convenience (no install, clean CSV) and privacy assurance, not raw speed. For thousands of files, a server-side loop is faster because it isn't constrained by a browser tab.
Why would I use a browser tool when I have unzip?
Three reasons: you're on a machine where you can't install software; the archives are sensitive and you don't want them handled by ad-hoc scripts; or you want a spreadsheet-ready CSV without parsing unzip's text footer. If none of those apply and you're comfortable in the shell, the CLI is perfectly good.
Does the browser tool handle 7z and rar like 7z l does?
No. It detects 7z and rar by magic bytes and names them in the format column, but it does not enumerate their entries — those columns come back as 0 / —. For 7z/rar entry detail, 7z l and unrar l are the right tools.
Can I script the browser tool?
Not today — there's no programmatic API for the batch report. It's an interactive page. For automation, write a small Node script with fflate, or loop over zipinfo/7z l in the shell.
Is the CSV output the same as parsing unzip -l?
It captures the same essentials for ZIPs — sizes, entry count, ratio, largest entry, encryption — but in a fixed, machine-readable schema. With unzip -l you'd write awk to extract the footer totals and the largest entry; the browser tool gives you those directly.
What's the largest folder I can analyse in the browser?
Up to 20 files on Pro, 100 on Pro-media, unlimited count on Developer — each file capped at 500 MB (Pro) or 2 GB (Pro-media/Developer). The total is bounded by browser memory. A shell loop has no such caps beyond disk and RAM.
Does either approach upload my files anywhere?
No. The CLI is obviously local. The browser tool is also local — it runs in WebAssembly in your tab and never sends file bytes over the network. You can verify with DevTools → Network.
Which is better for a backup audit?
If the backups are ZIPs and under 2 GB each, the browser tool gives you a tidy CSV in seconds. If they're 7z/tar.gz, very large, spread across many folders, or you want it scheduled, a shell loop wins. Many teams use the browser tool for spot checks and the CLI for nightly automation.
Can the browser tool replace zipinfo entirely?
For per-archive summaries of ZIP folders, largely yes. For per-entry inspection inside one archive, zipinfo (or JAD's /archive-tools/compression-ratio-calculator and /archive-tools/archive-metadata-extractor) goes deeper than the summary row.
How does it decide the format if the extension is wrong?
It reads the first bytes — ZIP starts PK, gzip 1F 8B, 7z 37 7A BC AF 27 1C, rar Rar!, bzip2 BZh, xz FD 37 7A 58 5A 00, tar has 'ustar' at offset 257. The extension is ignored, so a renamed file is still correctly classified.
Is there a cost difference?
The CLI is free once installed. The browser batch report requires a Pro plan. For a single throwaway job, the CLI is cheaper; for ongoing convenience on no-install machines with privacy guarantees, Pro is the trade.
Will the browser tool's numbers match unzip -l exactly?
For standard 32-bit ZIPs, yes — both read the same central directory. Differences appear only with ZIP64 archives, where the browser tool reads 32-bit fields and may report short. For those, trust the CLI.
What if I just need format and size, not entry stats?
Then the browser tool is ideal even for mixed-format folders — format and sizeBytes are populated for every file regardless of type. The entry columns are the only ones that are ZIP-specific.
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.