How to troubleshooting batch extractor
- Step 1Read the error text — it names the cause — The tool throws specific messages: "Drop at least one archive", "Archive contains encrypted entries ... Provide a password", or "Could not detect or extract archive format for <name>". Match the message to the matrix below before changing anything.
- Step 2Check the file against your tier's size cap — Each source must fit
fileBytes: Free 50 MB, Pro 500 MB, Pro-media / Developer 2 GB. An oversized file is refused before extraction. Shrink, split, or upgrade. - Step 3Check the per-archive entry count — Separately from size, each archive is capped at
entryLimit: Free 500, Pro 50,000, top tiers 500,000 entries. An archive of many tiny files can hit this while staying small in bytes. - Step 4Rule out encrypted entries — If the message mentions encrypted entries, the archive is password-protected and this tool has no password field. Decrypt it elsewhere, then batch the cleartext. Don't keep retrying — the result won't change.
- Step 5Reconcile a low Total-entries count — If the result panel shows fewer entries than you expect, suspect a stem collision (two sources with the same filename) or a
.tar.gzthat came out as a single.tar. Rename collisions; send tarballs to the nested extractor. - Step 6If it stalls, reduce the batch or check WASM — A long pause on a big batch is the in-memory zip step working — split into smaller groups. A failure specifically on 7z/RAR/bz2/xz/ISO points at the browser blocking WebAssembly; allow WASM or use a CLI for those.
Symptom to cause to fix
Each row maps a real symptom to the implementation behaviour behind it and the concrete fix.
| Symptom | Real cause | Fix |
|---|---|---|
| "Drop at least one archive to batch-extract." | No file was provided | Add at least one archive (Pro+ for more than one) |
| File refused before processing | Over the tier fileBytes cap | Shrink/split the file, or upgrade tier |
| Large-but-tiny-files archive refused | Over the per-archive entryLimit | Split the archive or move to a higher tier |
| "Archive contains encrypted entries ..." | Password-protected entry; no password field | Decrypt elsewhere, then batch the cleartext |
| "Could not detect or extract archive format" | Magic-byte detection failed; not a known archive | Confirm it's a real archive, not a renamed file |
| Output has fewer files than expected | Stem collision — same-name sources overwrite | Rename sources to unique stems and re-run |
A .tar.gz came out as one .tar | One-level rule; gz wraps a single stream | Run output through nested-archive-extractor |
| 7z/RAR fails but ZIP works | Browser blocking the libarchive WASM | Allow WebAssembly, or extract those via CLI |
Tier caps at a glance
Size and entry limits are enforced independently. minTier for this tool is Pro, so the Free single-file cap blocks real batching.
| Tier | Max file size | Max entries / archive | Max files / batch |
|---|---|---|---|
| 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
Diagnostic walk-throughs: the symptom, what it means in the code, and the exact resolution.
Diagnosing a low Total-entries count
You dropped two archives but the panel shows half the entries. The cause is a stem collision, not a bug.
Dropped: cache.zip (10 files), cache.zip (10 files) Result panel: Total entries 10 (expected 20) Cause: both map to cache/ ; second overwrote first. Fix: rename -> cache-a.zip, cache-b.zip ; re-run -> 20
The encrypted-entry stop
An AES-protected ZIP halts the whole batch with a clear message. There's no password field, so retrying won't help.
Dropped: secure.zip Error: "Archive contains encrypted entries (e.g. \"secrets.txt\"). Provide a password to extract." Fix: decrypt with a CLI (7z x / unzip -P), then batch the cleartext output.
Size cap vs entry cap
Two different rejections that look similar but have different causes. Match the right limit to the right file.
Case A (Pro): one 700 MB zip -> refused (over 500 MB size cap) -> split it, or upgrade to Pro-media (2 GB) Case B (Pro): a 40 MB zip with 80,000 tiny files -> refused (over 50,000 entry cap, though small in bytes) -> split into two archives, or upgrade tier
The packed-tar surprise
A backup.tar.gz comes out as a single .tar. Not an error — the documented one-level behaviour.
Dropped: backup.tar.gz Output: backup/backup.tar (one entry, still packed) Resolution: run the output ZIP through /archive-tools/nested-archive-extractor to unpack the tar.
Unrecognised format error
A file with no known magic signature can't be read; the tool tries ZIP as a last resort, then errors.
Dropped: report.pdf (renamed to report.zip) Error: "Could not detect or extract archive format for report.zip" Cause: it's a PDF, not an archive. Fix: drop an actual archive file.
Edge cases and what actually happens
Empty drop / no file selected
ErrorIf nothing is provided the tool throws "Drop at least one archive to batch-extract." Select at least one file (and remember Free tier accepts only one).
Password-protected archive
RejectedEncrypted entries throw "Archive contains encrypted entries ... Provide a password" — and there is no password field here. Decrypt elsewhere first. Use archive-password-tester to confirm a candidate password works.
File over the size cap
RejectedOver fileBytes (Free 50 MB, Pro 500 MB, top tiers 2 GB) the file is refused before any extraction. Split or upgrade. Check the size against your tier before re-trying.
Archive over the entry limit
RejectedThe per-archive entryLimit (Free 500, Pro 50,000, top tiers 500,000) is enforced separately from size, so a byte-small archive crammed with files can still be rejected. Split the archive.
Unrecognised file format
InvalidIf magic-byte detection fails, the tool tries to read it as a ZIP and, on failure, throws "Could not detect or extract archive format". Verify it's a genuine archive and not a renamed document.
Fewer output files than expected
OverwriteSubfolders are named by filename stem with no uniqueness counter, so same-stem sources overwrite each other and Total entries drops. Rename to unique stems and re-run.
tar.gz came out as a single tar
By designNot a bug — gz wraps one stream and the tool extracts one level. Run the output through nested-archive-extractor to unpack the tar's contents.
7z/RAR fails while ZIP succeeds
FailedThose formats need the libarchive WASM bridge. A browser or policy blocking WebAssembly fails them while fflate-handled ZIP/GZIP/TAR still work. Allow WASM, switch browsers, or use a CLI for those formats.
Long pause / appears stuck
ExpectedA big batch holds all uncompressed bytes in memory and re-zips in one pass — that pause is work, not a hang. Split into smaller groups, or run on a machine with more RAM. A true out-of-memory crash means the batch is too large for the tab.
Nested archive not unpacked
Not recursedAn archive inside one of your sources is written out as a packed file because extraction is one level only. Use nested-archive-extractor for recursion.
Frequently asked questions
Why does the tool say my archive has encrypted entries?
It's password-protected, and the Batch Extractor has no password field — batchExtract passes no password, so encrypted entries can't be opened. Decrypt with a CLI (7z x -p, unzip -P) and then batch the cleartext. Retrying won't change the result.
My file was rejected but it's not that big — why?
You probably hit the per-archive entry limit, which is separate from size: Free 500, Pro 50,000, top tiers 500,000 entries. An archive with thousands of tiny files trips this even when its bytes are small. Split the archive.
Why are some files missing from the output?
Almost always a stem collision. Subfolders are named by filename stem with no counter, so two sources named the same overwrite each other and the result panel's Total entries drops. Rename to unique names and re-run.
Why did my .tar.gz come out as a single .tar?
GZIP holds one stream and the tool extracts one level, so it gunzips to the inner .tar and stops. That's expected behaviour, not an error. Run the output through nested-archive-extractor.
The tool seems stuck on a big batch — is it frozen?
Probably not. It holds all uncompressed bytes in memory and re-zips them in a single pass, which takes time on a large batch. If the tab actually crashes, the batch exceeded available memory — process fewer archives at a time.
Why does 7z fail when ZIP works fine?
7z, RAR, bz2, xz, and ISO are read through the libarchive WASM bridge. If your browser or an enterprise policy blocks WebAssembly, those formats fail while fflate-handled ZIP/GZIP/TAR still work. Allow WASM or extract those formats with a CLI.
I'm on Free and can only add one file — is that a bug?
No. The Free archive tier caps a batch at one file and this tool's minTier is Pro, so true batching needs at least Pro (20 files). For a single archive on any tier, use multi-format-extractor.
What does "Could not detect or extract archive format" mean?
The file's magic bytes matched no known archive, and a last-resort ZIP read also failed. The file is probably not an archive (e.g. a renamed PDF or image). Drop a genuine archive.
Can I recover a partially extracted batch if one file errors?
No — the batch loop processes files in sequence and an error (e.g. an encrypted entry) throws and stops the whole run. Remove the offending file and re-run the rest.
Does the order I drop files in matter?
Only for collisions: if two sources share a stem, the one processed later wins. Since order isn't something you control precisely, the real fix is unique filenames, not reordering.
Is there an API I can hit to debug this in a script?
No — archive tools are browser-only with no public HTTP endpoint. Debugging happens interactively in the browser. On Pro+ the @jadapps/runner executes the tool in headless Chromium, but it isn't a file-accepting API you can script against.
How do I check what's inside an archive before unpacking the whole batch?
Use archive-previewer or file-listing-generator on a single archive to see its entries and spot problems (encryption, huge file counts) before committing to a full batch.
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.