How to troubleshooting the nested archive extractor
- Step 1Check you can run it at all — If you see an overlay reading
Nested Archive Extractor requires the Pro plan.instead of a dropzone, your account is below Pro. Upgrade to Pro, Pro-media, or Developer — this tool is gated and free cannot run it. - Step 2Verify the input is within limits — A
File "<name>" exceeds the <tier> tier per-job limiterror means the input archive is over your byte cap (Pro 500 MB, Pro-media/Developer 2 GB). The check is on the dropped file size, before decompression. - Step 3Confirm what actually unpacked — Read the metrics: Archives unpacked should equal the number of nested archives present. If it is lower, a member was encrypted or corrupt and got preserved raw. Entries is the leaf count — compare against your entry cap (50k Pro / 500k higher).
- Step 4Diagnose an unextracted inner archive — If an inner archive appears as a leaf in the output, either raise maxDepth (it was past the limit) or check its extension — only
.zip/.gz/.tar/.tgz/.bz2/.7z/.rar/.xzmembers are recursed. - Step 5Check the WASM path for 7z/rar — If 7z/rar members are preserved raw but you expected them unpacked, a browser extension or CSP may be blocking WebAssembly. Disable content blockers for the tab and retry; ZIP/GZIP/TAR via fflate are unaffected.
- Step 6Pick the right tool if nesting is not the goal — Need a single flat layer? Use multi-format-extractor. Many archives at once? batch-extraction-manager. Just inspect without extracting? archive-previewer.
Symptom to cause to fix
The common Nested Extractor symptoms mapped to their real cause in the code and the action that resolves them.
| Symptom | Cause | Fix |
|---|---|---|
| Upgrade overlay, no dropzone | Account below Pro (tool minTier is Pro) | Upgrade to Pro/Pro-media/Developer |
exceeds the <tier> tier per-job limit | Input archive over byte cap | Use a higher tier (up to 2 GB) or split the input |
| Output is short on files | Entry count hit the tier cap | Lower maxDepth or process a sub-archive |
| Inner archive not unpacked | maxDepth reached | Raise maxDepth (max 10) |
| Inner archive not unpacked | Member lacks an archive extension | Rename to .zip/.tar/etc, or extract that layer first |
| Member sits in output as raw bytes | Encrypted (no password field) or corrupt | Decrypt with multi-format-extractor; corrupt is preserved by design |
| 7z/rar preserved, not extracted | WASM blocked by extension/CSP | Allow WebAssembly for the tab; retry |
| Output is a ZIP, not a 7z | Output is always ZIP | Expected — libarchive is read-only here |
Error and message reference
Where each message comes from and what it means.
| Message / behaviour | Trigger | Meaning |
|---|---|---|
Nested Archive Extractor requires the Pro plan. | Free tier opens the page | Tier gate (ProOverlay); upgrade required |
Drop an archive file to process. | Process clicked with no file | Add an input archive first |
File "<name>" exceeds the <tier> tier per-job limit (<size>). | Input over byte cap | Use a larger tier or smaller input |
Could not detect or extract archive format for <name> | Outer file is not a recognised archive | Confirm it is a real archive; libarchive covers 7z/rar/bz2/xz/iso |
| Member preserved as raw bytes (no error) | Inner member encrypted/corrupt/over-depth | By design — the rest still extract |
Cookbook
Each symptom with the diagnostic you run and the result that confirms the cause.
Stuck on 'Processing…' for a long time
Usually not stuck — a deep tree or a large input is decompressing every layer in memory. Confirm by lowering depth on a copy.
Symptom: Process spins on a 5-level, 400 MB archive. Diagnostic: rerun a copy with maxDepth: 2. Result: completes fast -> it was depth/memory, not a hang. Fix: use the lowest depth that reaches the files you need.
An inner ZIP came out unextracted
Decide between the two causes: depth or extension.
Output: report-flattened.zip data/inner.zip <- still zipped Check 1: was maxDepth high enough? (default 3) -> raise to 4 and rerun. Check 2: is it really named .zip? -> 'inner.bin' would never recurse; rename to .zip.
A file shows up as raw bytes
Encrypted or corrupt members are preserved, not lost. Verify which.
Output: bundle-flattened.zip secure.zip <- raw, not unpacked Metric: Archives unpacked = N-1 If secure.zip is password-protected: -> multi-format-extractor (enter password), then re-nest. If it is truncated/corrupt: -> preserved by design; try corrupted-zip-repair.
7z/rar members are not extracting
Confirm the libarchive WASM path is loading.
Output: drop-flattened.zip vendor.7z <- raw Diagnostic: open DevTools -> Console for WASM/CSP errors. Fix: disable content blockers / allow wasm for the tab; retry. (ZIP/GZIP/TAR via fflate are unaffected by this.)
Tier-limit rejection on a big artifact
The size check fires before any work, on the input file size.
Drop: huge.zip (1.2 GB) on a Pro account (500 MB cap) Error: File "huge.zip" exceeds the pro tier per-job limit (500.0 MB). Fix: upgrade to Pro-media/Developer (2 GB) or split with archive-splitter, then nest the parts.
Edge cases and what actually happens
Free tier cannot open the tool
Pro requiredThe tool's minimum tier is Pro. Free accounts see Nested Archive Extractor requires the Pro plan. and no dropzone. This is the most common 'not working' report — it is a deliberate gate, not a bug.
Input over the per-job size cap
Rejected (limit)Inputs above the byte cap (Pro 500 MB, Pro-media/Developer 2 GB) are blocked with File "<name>" exceeds the <tier> tier per-job limit before any decompression. Upgrade tier, or split the archive with archive-splitter and nest the parts.
Output entry count hit the cap
Limit reachedFlattening multiplies entries; if the output looks short, you may have hit the entry cap (50,000 Pro / 500,000 higher). Lower maxDepth or process a sub-archive separately.
Inner archive over maxDepth
By designA member deeper than maxDepth is written to the output unexpanded — not an error. Raise maxDepth (up to 10) to reach it; mind that deeper means more memory.
Member lacks an archive extension
Not recursedRecursion is by file extension. A real archive named payload.bin is treated as a leaf and copied through. Rename it to a recognised extension, or extract that one layer with multi-format-extractor first.
Encrypted inner archive
Preserved (raw)This tool has no password field, so encrypted members cannot be opened and are preserved as raw bytes. Decrypt with multi-format-extractor (password supported), then re-run nesting.
Corrupt inner archive
Preserved (raw)A member that fails to open is caught and kept as raw bytes; the job does not abort. For a damaged ZIP you want to recover, try corrupted-zip-repair on that member, then re-nest.
7z/rar not extracting
WASM blockedlibarchive runs as WASM; a content blocker or strict CSP can stop it loading, leaving 7z/rar/bz2/xz members preserved raw. Check DevTools → Console, allow WebAssembly for the tab, and retry. ZIP/GZIP/TAR (fflate) are unaffected.
Outer file is not a real archive
ErrorIf the dropped file is not a recognised archive in any engine, you get Could not detect or extract archive format for <name>. Confirm it is genuinely an archive — detection covers zip/gz/tar plus 7z/rar/bz2/xz/iso via libarchive.
Expecting a 7z output
By designThe output is always a flattened ZIP, never a 7z/rar (libarchive is read-only here). This is not a failure — if you need a different container, post-process with a tool that writes it.
Frequently asked questions
Why do I see an upgrade prompt instead of the tool?
Nested Archive Extractor has a minimum tier of Pro, so free accounts get a requires the Pro plan overlay rather than the dropzone. Upgrade to Pro, Pro-media, or Developer to run it.
Why does it stay on 'Processing…'?
Usually it is not stuck — a deep or large archive decompresses every layer in memory, which takes time. Rerun a copy with a lower maxDepth; if that finishes quickly, it was depth/memory load, not a hang. Keep maxDepth as low as the job needs.
Why did an inner archive not get extracted?
Two causes. Either it was deeper than maxDepth (raise it, up to 10), or its filename lacks a recognised archive extension — recursion only re-opens .zip/.gz/.tar/.tgz/.bz2/.7z/.rar/.xz members. Rename the member or extract that layer first.
Why is a file in the output as raw bytes instead of being unpacked?
It was encrypted or corrupt. This tool has no password field, so encrypted members cannot be opened, and corrupt members fail to open — in both cases they are preserved as raw bytes rather than aborting the job. Decrypt with multi-format-extractor or repair with corrupted-zip-repair, then re-nest.
Why is the output smaller or larger than I expected?
Smaller: members may be preserved raw (encrypted/corrupt) or you hit the entry/depth limit. Larger: the output is re-compressed at DEFLATE level 6, and already-compressed inner content (e.g. media) can grow slightly when re-zipped. Check the metrics for Archives unpacked and Entries.
What error codes might I see?
Plain-text messages, not codes: Nested Archive Extractor requires the Pro plan. (tier gate), Drop an archive file to process. (no input), File "<name>" exceeds the <tier> tier per-job limit (size cap), and Could not detect or extract archive format for <name> (unrecognised outer file).
Why are my 7z or rar files not unpacking?
Those go through libarchive WASM. If a browser extension or CSP blocks WebAssembly, that path fails and the members are preserved raw. Allow WebAssembly for the tab and retry — ZIP/GZIP/TAR via fflate are unaffected.
Why is the output a ZIP and not a 7z?
By design — the tool always writes a single flattened ZIP regardless of input formats. libarchive reads 7z/rar but does not write them in the browser. This is expected behaviour, not an error.
Why does the entry count look wrong?
Entries counts every leaf file in the flattened output. If it stalls below what you expect, you likely hit the tier entry cap (50,000 Pro / 500,000 Pro-media/Developer) or members were preserved raw. Lower maxDepth or process sub-archives.
Can I extract several archives to fix this faster?
Not with this tool — it takes one file. For many archives in one go use batch-extraction-manager; to just inspect contents without extracting use archive-previewer.
Is a blank or stale page a tool bug?
A hard refresh clears a stale cached page. If the dropzone still does not appear, confirm you are on Pro or higher (the gate) and that WebAssembly is allowed for the origin.
When should I use a different tool instead?
Single flat layer → multi-format-extractor. Only some files by pattern → selective-extractor. Inspect without extracting → archive-previewer. Many archives at once → batch-extraction-manager.
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.