How to troubleshooting the compression ratio calculator
- Step 1Read the exact error — Two messages cover most failures.
Not a valid ZIP archive.means no readable ZIP central directory was found. A message endingexceeds the <tier> tier per-job limit (<size>). Upgrade for larger files.means the file is over your size cap. - Step 2Confirm it's really a ZIP — If you see
Not a valid ZIP archive., run auto-format-detector on the file. It reads the magic bytes and tells you the true format — a.zipthat's actually a RAR is a common culprit. - Step 3Check the size against your tier — Free caps at 50 MB, Pro at 500 MB, Pro-media/Developer at 2 GB. Over the cap, the job is blocked before processing. Upgrade, or split the archive with archive-splitter.
- Step 4Sanity-check surprising ratios — 0% usually means the entry is Stored or already-compressed (JPEG/MP4/nested ZIP) — that's correct.
—means a zero-byte entry. A wildly wrong huge size points to ZIP64 (see below). - Step 5Suspect ZIP64 for giant archives — If an entry shows an absurd uncompressed size (around 4 GB exactly) or the file count looks capped, the archive likely uses ZIP64, which this reader doesn't decode. Verify per-entry sizes with a CLI lister for those files.
- Step 6Try repair for corrupt directories — If the archive is partly listed or rejected and you suspect corruption, run corrupted-zip-repair first, then re-run the calculator on the repaired file.
Symptom → cause → fix
The full decision table for Ratio Calculator failures and surprises.
| Symptom | Cause | Fix |
|---|---|---|
Not a valid ZIP archive. | Input isn't a ZIP (7z/rar/tar/gz), or has no readable central directory | Detect format, then convert to ZIP |
...exceeds the <tier> tier per-job limit... | File larger than your tier's size cap | Upgrade or split the archive |
Drop an archive file to process. | Processed with no file selected | Drop a single ZIP first |
| Some entries show 0% | Stored method, or already-compressed content | Expected — not an error |
An entry shows — | Zero uncompressed size (empty file) | Expected — no ratio to compute |
| A huge entry's size looks wrong | ZIP64 entry > 4 GB (sentinel size) | Verify with a CLI lister |
| Fewer rows than expected | Folders skipped, or truncated directory | Folders are excluded by design; else repair |
| Overall ratio surprisingly low | Big Stored / already-compressed entries dominate | Check per-entry methods |
Tier size caps (what triggers the limit error)
The size cap enforced per job. The entry-count column is the documented per-archive cap for the archive family.
| Tier | Max ZIP size | Max entries | 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 |
Cookbook
Each problem as you'd actually meet it, with the message and the fix.
A renamed RAR rejected as not-a-ZIP
Someone renamed backup.rar to backup.zip. The tool reads bytes, not extensions, so it fails the central-directory check.
Input: backup.zip (actually a RAR) Result: Error "Not a valid ZIP archive." Diagnose: /archive-tools/auto-format-detector -> reports: RAR Fix: use a RAR tool, or convert to ZIP, then re-run.
Oversized file blocked before processing
An 80 MB ZIP on the Free tier is stopped with the exact tier message — it never starts processing.
Input: dataset.zip (80 MB), Free tier Result: Error File "dataset.zip" exceeds the free tier per-job limit (50 MB). Upgrade for larger files. Fix: upgrade to Pro (500 MB), or split with /archive-tools/archive-splitter and run each part.
0% ratios that are actually correct
A media ZIP looks like it 'didn't compress'. The method column explains it — those entries are Stored or already-compressed.
name,uncompressedSize,compressedSize,ratio,method clip.mp4,52428800,52428800,0.0%,Stored photo.jpg,2048000,2041800,0.3%,Deflate SUMMARY,54476800,54470600,0.0%, Not a bug: video is Stored, JPEG is already compressed. Re-zipping them can't help. Expected.
A ZIP64 entry showing a sentinel size
A multi-GB entry reports an exactly-4 GB-ish size and a nonsense ratio because the reader uses 32-bit fields and doesn't decode ZIP64.
name,uncompressedSize,compressedSize,ratio,method big.iso,4294967295,3900000000,9.2%,Deflate 4294967295 = 0xFFFFFFFF (ZIP64 sentinel), not the real size. Ratio is unreliable for this entry. List with a CLI (unzip -v / 7z l) for accuracy.
Empty ZIP rejected
A valid but empty ZIP has no entries to measure, so the tool reports it as not valid for this purpose.
Input: empty.zip (valid EOCD, 0 entries) Result: Error "Not a valid ZIP archive." There's nothing to measure in an archive with no files. Add files, or pick a non-empty archive.
Edge cases and what actually happens
`Not a valid ZIP archive.` on a real ZIP
Invalid / not foundIf a genuine ZIP triggers this, the central directory is likely truncated or corrupt, or the file is empty (zero entries). Try corrupted-zip-repair to recover the directory, then re-run. If it's actually another format, auto-format-detector will say so.
Non-ZIP format (7z, RAR, tar, gzip)
Rejected: not a valid ZIPThe tool only parses the ZIP central directory; other formats don't have one, so they're rejected. Convert with archive-format-converter or tar-gz-to-zip, then measure the resulting ZIP.
File over the tier size cap
Rejected: tier limitThe exact message is File "name.zip" exceeds the <tier> tier per-job limit (<size>). Upgrade for larger files. It's enforced before any parsing. Upgrade for a higher cap, or split with archive-splitter and run each part.
Processed with no file selected
Rejected: no inputClicking Process before dropping a file yields Drop an archive file to process.. The tool needs exactly one ZIP — it has no generative/empty-input mode. Drop a ZIP and try again.
Entries reporting 0% / `—`
Expected0% means an entry is Stored or already-compressed (its compressed size equals or exceeds uncompressed); — means a zero-byte file where a percentage is undefined. Both are correct outputs, not failures. Check the method column to confirm.
Sizes/counts wrong on a ZIP64 archive
Sentinel sizesThe reader uses the standard 32-bit size fields and 16-bit entry count and doesn't parse ZIP64 extras, so entries over 4 GB show the 0xFFFFFFFF sentinel and counts wrap at 65,535. For such archives, verify per-entry sizes with a CLI lister (unzip -v, 7z l).
Fewer rows than the archive contains
By design / partialDirectory entries are deliberately excluded (zero size), so the row count is files-only. If real files are missing too, the central directory is likely truncated — the parser stops at the first bad record. Repair with corrupted-zip-repair and re-run.
Names with odd characters look garbled
PreservedEntry names are decoded as UTF-8 (non-fatal), so a name stored in a legacy code page may show replacement characters. The sizes and ratios are still correct — only the displayed name is affected. CSV-special characters in names are quoted automatically.
Encrypted ZIP — will it fail without a password?
SupportedNo. The calculator reads sizes and the AES method from the directory, so it reports ratios for encrypted archives without a password. It never tries to decrypt — so an encrypted archive isn't a failure case here.
Tab seems slow on a large archive
Expected on big filesThere's no decompression, so it doesn't 'stall mid-extract'. Reading a directory with tens of thousands of entries near the tier cap can take a moment in a busy tab. If it never finishes, the file is likely far over the cap (and should have been blocked) or corrupt — re-check the size and format.
Frequently asked questions
Why do I get 'Not a valid ZIP archive.'?
The tool finds no readable ZIP central directory. Causes: the file is a 7z/RAR/tar/gz (it's ZIP-only), it's a renamed non-ZIP, it's empty (zero entries), or its directory is corrupt/truncated. Run auto-format-detector to confirm the real format; convert or repair as needed.
What's the exact size-limit error?
File "name.zip" exceeds the <tier> tier per-job limit (<size>). Upgrade for larger files. The cap is 50 MB (Free), 500 MB (Pro), 2 GB (Pro-media/Developer), checked before processing. Upgrade or split the archive.
Why does an entry show 0%?
Either it's stored uncompressed (method Stored) or it's already-compressed content (JPEG, MP4, nested ZIP/gz) that Deflate can't shrink, so compressed ≈ uncompressed. That's the correct result — check the method column to see which.
Why does an entry show '—' instead of a number?
Its uncompressed size is zero (an empty file or placeholder). A percentage of zero bytes is undefined, so the tool prints — rather than 0% or an error. The entry still appears with its sizes.
An entry's size looks impossibly large — is that a bug?
Likely a ZIP64 archive. The reader uses 32-bit size fields and doesn't decode the ZIP64 extra field, so entries over 4 GB read the 0xFFFFFFFF sentinel and the ratio is unreliable. Verify with unzip -v or 7z l for those entries.
Why does it say the file count is lower than I expect?
Two reasons: folders are excluded (they have zero size), so the count is files-only; and an archive with more than 65,535 entries (ZIP64) has its count wrap because the standard 16-bit field is used. For very large archives, list with a ZIP64-aware CLI.
Does it ever get stuck decompressing?
No — it never decompresses. It reads central-directory metadata only. If it feels slow, it's a very large/near-cap file or a busy browser tab. A truly oversized file is blocked before processing with the limit error.
Can I process a password-protected ZIP?
Yes, for the ratio report — sizes and the AES method come from the directory without a password. The tool can't show file contents (it doesn't decrypt), but that's not what it does. So encryption is not a failure case here.
My .tar.gz fails — how do I measure it?
Convert it first. Use tar-gz-to-zip (or archive-format-converter) to produce a ZIP, then run the calculator. Re-compressing already-compressed tarball contents will show low ratios, which is expected.
Why is the overall ratio so low when I know the files are compressible?
A few large Stored or already-compressed entries dominate the totals. The SUMMARY is byte-weighted, so one big video at 0% drags the overall number down even if your text files compress to 80%. Sort the per-entry CSV to see the breakdown.
Are there settings I might have configured wrong?
No — there are no settings. The option schema is empty, so there's nothing to misconfigure. Output is deterministic from the archive's directory; if results look off, it's about the input file, not a setting.
Is there an API to call so I can avoid the UI entirely?
No public HTTP API — archive tools are browser-only. On Pro+ the same logic can run via the local @jadapps/runner (a headless browser), but there's no REST endpoint. For headless ZIP listing, a CLI like unzip -v is the better fit.
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.