How to troubleshooting the batch compression report
- Step 1First: is the data actually wrong, or just non-ZIP? — If a
.7z,.rar,.tar,.gz,.bz2, or.xzshows 0 entries and a—ratio, that's correct — entry stats come from the ZIP central directory only. The format and sizeBytes columns are still right. This isn't a failure. - Step 2Check the plan — If you see an upgrade prompt instead of a dropzone, you're on Free — the batch report requires Pro or higher. Upgrade, or for a free one-off, script the equivalent with fflate.
- Step 3Check the per-file size cap — A file over your tier's cap (500 MB Pro, 2 GB Pro-media/Developer) can't be processed. Split it (see /archive-tools/archive-splitter) or upgrade. The cap is per file, not per batch.
- Step 4Read the error column — If a row has
format=error, the reason is in theerrorcolumn — typically a truncated file or an unreadable central directory. The rest of the batch still completed; only that file failed. - Step 5Confirm the true format — If a file is detected as
unknownor surprises you, run /archive-tools/auto-format-detector — it reads magic bytes and reports the real type, catching renamed or non-archive files. - Step 6Route to the right repair / inspection tool — For a corrupt ZIP, try /archive-tools/corrupted-zip-repair. For per-entry ratios inside one archive, use /archive-tools/compression-ratio-calculator. The batch report is a summary, not a deep inspector.
Symptom → cause → fix
The most common things people report, what actually causes them, and what to do.
| Symptom | Cause | Fix |
|---|---|---|
7z/tar.gz shows 0 entries, — ratio | Entry stats are ZIP-central-directory only | Expected — use a CLI or the matching tool for those formats' internals |
| No dropzone, just an upgrade prompt | Tool requires a Pro plan | Upgrade to Pro or higher |
A row says format=error | File was corrupt/truncated/unreadable | Read the error column; try /archive-tools/corrupted-zip-repair |
| File rejected before processing | Over the per-file size cap | Split with /archive-tools/archive-splitter or upgrade tier |
ratioPercent is — | No uncompressed total to divide by | Expected for non-ZIP / empty ZIPs |
ratioPercent is ~0% or slightly negative | Already-compressed / stored entries | Expected — re-zipping won't help |
entryCount smaller than reality | ZIP64 / >65,535 entries (32-bit fields) | Verify with a ZIP64-aware tool |
File shown as unknown | Not a recognised archive (or wrong bytes) | Confirm with /archive-tools/auto-format-detector |
encrypted=true unexpectedly | An entry has GP flag bit 0 set | Check cipher with /archive-tools/encrypted-archive-detector |
Decoding each value
What a given column value means and whether it indicates a problem.
| Value you see | What it means | Problem? |
|---|---|---|
compressedSize = 0 on a 7z/tar.gz | No ZIP central directory to sum | No — by design |
largestEntry empty | No entries were parsed (non-ZIP or empty) | No |
ratioPercent = — | Uncompressed total was 0 | No |
sizeBytes > compressedSize | File overhead + payload vs payload only | No — normal for ZIPs |
format = error | The file threw while being read | Yes — see error column |
format = unknown | Bytes matched no known archive magic | Maybe — not an archive, or wrong file |
encrypted = false on a known-encrypted 7z | Encryption flag is read from ZIP entries only | No — limitation for non-ZIP |
Limits that cause rejections
Per-file and per-batch caps by plan. Hitting these is a real block, not a bug.
| Plan | Per-file cap | Files per batch |
|---|---|---|
| Free | Tool unavailable (Pro required) | — |
| Pro | 500 MB | 20 |
| Pro-media | 2 GB | 100 |
| Developer | 2 GB | Unlimited |
Cookbook
Walk-throughs for the symptoms support sees most, each tied to what the tool actually does.
"My 7z shows zero files inside"
The number one false alarm. The 7z is fine; the tool just doesn't enumerate non-ZIP entries.
Row you saw: vault.7z,7z,2097152,0,0,—,,0,false, Why: entryCount/compressedSize/ratio come from the ZIP central directory. 7z has no such structure, so those columns are empty. format=7z and sizeBytes=2097152 are correct. Fix: nothing to fix. For 7z internals, use a CLI (7z l).
"There's no dropzone"
On Free, the page shows an upgrade prompt where the dropzone would be.
What you see: 'This tool requires the Pro plan' instead of a dropzone. Why: batch-compression-report has minTier = pro. Free can't run it. Fix: upgrade to Pro (or higher). For a free, one-off equivalent, script it with fflate in Node — see the developer-workflow guide.
"One file became an error row"
A corrupt file doesn't crash the batch — it gets an error row and the run continues.
good.zip,zip,262144,200000,8,23.7%,data.csv,65536,false, broken.zip,error,131072,0,0,,,0,false,Invalid or truncated central directory next.zip,zip,393216,310000,10,21.2%,app.js,98304,false, Why: broken.zip threw while reading. The message is in the error column. Fix: try /archive-tools/corrupted-zip-repair on broken.zip; confirm its true type with /archive-tools/auto-format-detector if the format is odd.
"The file was rejected before it ran"
A file over the per-file cap can't be processed on your plan.
File: full-backup.zip — 1.8 GB, you're on Pro (500 MB cap). Result: rejected — exceeds the Pro per-file limit. Fix options: 1. Upgrade to Pro-media/Developer (2 GB cap), or 2. Split it first: /archive-tools/archive-splitter, then report the parts.
"The ratio looks wrong (0% or negative)"
Tiny or negative ratios are honest — the entries were already compressed or stored.
media.zip,zip,10485760,10480000,3,0.1%,clip.mp4,5242880,false, Why: clip.mp4 is already H.264-compressed; the ZIP can't shrink it, so compressedSize ≈ uncompressedSize → ~0% (can even go slightly negative for stored entries with overhead). Fix: nothing — this correctly tells you re-zipping won't help.
Edge cases and what actually happens
Non-ZIP archive shows 0 entries
By designgzip, tar, bzip2, xz, 7z, and rar are detected by magic bytes but not entry-parsed — only the ZIP central directory is read for per-entry stats. So those formats correctly show 0 entries, 0 compressed size, and a — ratio. The format and sizeBytes columns are still accurate. Not a bug.
Page shows an upgrade prompt, not a dropzone
Pro requiredThe batch report requires a Pro plan (minTier = pro). On Free the page renders an upgrade prompt in place of the dropzone. This is intended gating, not a load failure. Upgrade, or script the equivalent yourself with fflate for a free one-off.
A file becomes an `error` row
errorIf reading a file throws — truncated download, garbage bytes, unreadable central directory — that file gets format=error with the exception message in the error column, and the batch continues. Read the message, then try /archive-tools/corrupted-zip-repair and confirm the format with /archive-tools/auto-format-detector.
File over the per-file size cap
400 too largeEach file must fit your tier's per-file cap: 500 MB on Pro, 2 GB on Pro-media and Developer. A larger file is rejected before processing. Split it with /archive-tools/archive-splitter or move up a tier. The cap is per file; the batch total is limited by browser memory.
ratioPercent is `—`
By designratioPercent is — whenever the uncompressed total is 0 — i.e. for non-ZIP containers (no central directory parsed) or an empty ZIP. There's nothing to divide by, so the tool prints a dash rather than a misleading number.
ratioPercent is ~0% or slightly negative
ExpectedWhen entries are already compressed (JPEG, MP4, MP3, nested ZIPs) or stored without compression, compressed size can equal or exceed uncompressed size, giving a near-zero or slightly negative ratio. This is an honest reflection of the central-directory numbers — it tells you re-compressing won't help.
entryCount looks too small (ZIP64)
PartialThe parser reads the standard 32-bit End-Of-Central-Directory fields. Archives with more than 65,535 entries, or sizes over 4 GB, that rely on the ZIP64 extension may report a truncated entryCount or size. For those archives, verify with a fully ZIP64-aware tool.
File detected as `unknown`
Maybe a problemunknown means the first bytes matched no recognised archive magic (ZIP, gzip, 7z, rar, bzip2, xz, tar). Either the file isn't an archive, or it's a format the detector doesn't cover. Confirm with /archive-tools/auto-format-detector; if it really isn't an archive, the row is simply telling you so.
encrypted=false on a known-encrypted non-ZIP
LimitationThe encrypted flag is derived from the ZIP central directory's general-purpose flag. For non-ZIP formats (e.g. an encrypted 7z), there's no ZIP central directory to read, so the column shows false even if the archive is encrypted. Check encrypted 7z/rar with the matching CLI; for ZIPs, /archive-tools/encrypted-archive-detector gives the cipher.
Stuck on processing with a very large batch
Memory boundEach file's index is read in turn, which is light, but holding many large File objects in a single tab can pressure browser memory. If a big batch stalls, process in smaller groups (well within your tier's batch count) and close other heavy tabs. The per-file cap (2 GB) still applies to each item.
Output is CSV when you wanted JSON
CSV onlyThe tool emits CSV only — there is no JSON option. The downloaded file is batch-compression-report.csv with a fixed 10-column header. If you need JSON, convert the CSV downstream; the report itself won't produce it.
Frequently asked questions
Why does my 7z / tar.gz show 0 entries and a — ratio?
Because per-entry stats are read only from the ZIP central directory. Those formats are correctly detected (format=7z / gz) and their sizeBytes is right, but they have no ZIP central directory, so entryCount, compressedSize, ratioPercent, and largestEntry are empty. It's by design, not a failure.
Why is there no dropzone — just an upgrade message?
The batch report requires a Pro plan. On Free, the page shows an upgrade prompt instead of the dropzone. Upgrade to Pro or higher to use it. For a free, one-off equivalent, script it with fflate in Node.
One of my files shows format=error — what now?
That file threw while being read (corrupt, truncated, or unreadable central directory); the reason is in the error column. The rest of the batch still completed. Try /archive-tools/corrupted-zip-repair to recover it, and /archive-tools/auto-format-detector to confirm its true type.
Why was my file rejected before processing?
It's over your tier's per-file cap — 500 MB on Pro, 2 GB on Pro-media/Developer. Split it with /archive-tools/archive-splitter or upgrade. This cap is per file; the batch total is limited only by browser memory.
Why is ratioPercent showing a dash?
ratioPercent is — whenever there's no uncompressed total to divide by: non-ZIP containers (no central directory parsed) and empty ZIPs. Rather than print a misleading 0, the tool shows a dash.
Why is the ratio near 0% or negative?
The entries were already compressed (JPEG/MP4/MP3, or nested ZIPs) or stored uncompressed, so compressed size ≈ or > uncompressed size. That's correct — it's telling you re-zipping that content won't save space.
The entry count seems too low for a huge archive — why?
The parser reads 32-bit central-directory fields. Archives above 65,535 entries or 4 GB that depend on the ZIP64 extension can report short counts or sizes. Verify those with a ZIP64-aware tool; for everyday archives the count is exact.
Why is a file listed as unknown?
Its leading bytes didn't match any recognised archive magic (ZIP, gzip, 7z, rar, bzip2, xz, tar). It's either not an archive or a format outside the detector's set. Confirm with /archive-tools/auto-format-detector.
Why does encrypted say false on my encrypted 7z?
The encrypted flag comes from the ZIP central directory's general-purpose flag. Non-ZIP formats have no such structure here, so the column reads false even for an encrypted 7z. For ZIPs, /archive-tools/encrypted-archive-detector also tells you the cipher.
It seems stuck on a big batch — what should I do?
Reading each index is light, but holding many large files in one tab uses memory. Process fewer files per run (within your plan's batch count), close other heavy tabs, and keep each file under the 2 GB cap. The tool reads indexes only, so genuine hangs are usually memory pressure.
Can I get JSON instead of CSV?
No — the tool outputs CSV only, as batch-compression-report.csv with a fixed 10-column header. Convert it downstream if you need JSON; there's no built-in JSON option.
Are my files uploaded when something goes wrong?
No. Everything runs in your browser via WebAssembly, success or failure. Even an error row is produced locally — file bytes never leave your machine. You can confirm with DevTools → Network.
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.