How to batch extractor in developer workflows
- Step 1Collect the artifacts you want to inspect — Download the build outputs, dependency archives, or release bundles into one folder. They can be mixed formats — ZIP, 7z, RAR, TAR, GZ together in one batch.
- Step 2Drop them onto the Batch Extractor — Drag everything onto batch-extraction-manager. Each archive's format is detected from magic bytes, and the whole thing runs locally — no artifact leaves the browser.
- Step 3Expect npm/python tarballs to need a second pass — A package
.tgzor.tar.gzis detected as gz and emitted as a single.tar(one level only). To inspect its files, run the output through nested-archive-extractor. - Step 4Keep artifact names unique to avoid collisions — Subfolders are named by filename stem with no counter. Two
dist.zipfiles overwrite each other underdist/. Rename todist-jobA.zip,dist-jobB.zipbefore dropping so each lands under its own prefix. - Step 5Download and feed the tree into your scripts — You get
batch-extracted-N-archives.zip. Unpack it locally and point your diff/lint/inspection tooling at the per-artifact subfolders. The result panel'sTotal entriesconfirms nothing silently merged. - Step 6Reach for the CLI when you hit a boundary — Passwords, deep recursion, multi-GB artifacts, or unattended CI all sit outside this tool. For those, script
unzip/7z; the Batch Extractor stays the fast interactive option for ad-hoc inspection.
Developer artifacts: what to expect
Common dev-loop archives and how the one-level, browser-side extractor treats each.
| Artifact | Format | Result | Notes |
|---|---|---|---|
| CI build output | ZIP | Fully unpacked under <job>/ | Ideal use case |
| npm package | tgz (tar.gz) | Emitted as one .tar | Needs nested-archive-extractor pass |
| Python sdist | tar.gz | Emitted as one .tar | Same one-level rule |
| Python wheel | ZIP (.whl) | Fully unpacked | Wheels are ZIPs — read directly |
| Tooling release | 7z / RAR | Fully unpacked (libarchive WASM) | No p7zip/unrar install needed |
| Signed / encrypted release | AES ZIP | Rejected | No password field — decrypt via CLI |
Execution model and limits
Where the tool runs and the ceilings that apply. There is no public HTTP API for archive tools.
| Aspect | Reality | Implication for devs |
|---|---|---|
| Execution | Browser-only (browserOnly: true) | Interactive; not a curl-able endpoint |
| Public API | None (apiAvailable: false) | Can't wire into a CI step directly |
| Runner mode | headless Chromium (Pro+) | @jadapps/runner drives the UI, not a file API |
| Output format | Always a single ZIP (DEFLATE 6) | No tar/7z output choice here |
| Recursion | One level | Chain nested-archive-extractor for depth |
| Batch size (Pro / top tiers) | 20 / 100+ files, to 2 GB each | Big artifacts -> CLI |
Cookbook
Dev-loop recipes. Each shows the drop and the resulting tree, with the follow-up step where one is needed.
Compare two CI build artifacts
Drop both job outputs, get them side by side under distinct prefixes, then diff the trees locally.
Drop: build-main.zip build-pr-482.zip Download batch-extracted-2-archives.zip: build-main/dist/app.js, build-main/dist/app.css build-pr-482/dist/app.js, build-pr-482/dist/app.css Then: diff -r build-main/ build-pr-482/
Inspect a batch of npm tarballs
npm packs are tgz, so each comes out as a .tar. One nested pass finishes the unpack for inspection.
Drop: left-pad-1.3.0.tgz is-odd-3.0.1.tgz Download batch-extracted-2-archives.zip: left-pad-1.3.0/left-pad-1.3.0.tar (still packed) is-odd-3.0.1/is-odd-3.0.1.tar Next: /archive-tools/nested-archive-extractor -> package/package.json ...
Read python wheels directly
Wheels are ZIPs under the hood, so they unpack fully in one shot — no second pass.
Drop: requests-2.31.0-py3-none-any.whl urllib3-2.2.1-py3-none-any.whl Download batch-extracted-2-archives.zip: requests-2.31.0-py3-none-any/requests/__init__.py ... urllib3-2.2.1-py3-none-any/urllib3/__init__.py ...
Avoid the dist.zip collision
Two artifacts named dist.zip collapse to one dist/ folder. Rename before dropping so each job keeps its own tree.
Bad drop: dist.zip (job A), dist.zip (job B) -> only one dist/ in output; Total entries halved Good drop: dist-jobA.zip, dist-jobB.zip -> dist-jobA/..., dist-jobB/... (both preserved)
Why CI can't call it directly
Archive tools expose no HTTP API. A CI job must use a CLI; the Batch Extractor is the interactive counterpart for local inspection.
# This does NOT exist:
curl -F file=@a.zip https://.../api/batch-extraction-manager # 404
# In CI, use a CLI instead:
for f in *.zip; do unzip -q "$f" -d "out/${f%.zip}"; done
# Use the Batch Extractor in-browser for ad-hoc local inspection.Edge cases and what actually happens
Trying to call it from CI via HTTP
No APIArchive tools have no public endpoint (apiAvailable: false); they run in the browser only. A CI pipeline can't POST files to it. Use a CLI in CI; the Batch Extractor is for interactive local work. The @jadapps/runner drives the UI on Pro+, not a file API.
npm / python source tarball expecting full unpack
Not recursedA .tgz / .tar.gz is detected as gz and emitted as a single .tar (one level). Chain nested-archive-extractor to read package.json and sources.
Two artifacts named identically
OverwriteSubfolders are stem-named with no de-duplication, so two dist.zip files collapse into one dist/ and one overwrites the other. Rename to include the job or commit before batching.
Encrypted / signed release archive
RejectedNo password field, so AES / ZipCrypto entries are rejected. Decrypt via CLI first. To inspect signature/comment metadata of a ZIP, see archive-signing-info.
Multi-GB build artifact
RejectedEach file must fit the tier cap (to 2 GB at the top tiers). A large container image export or dataset bundle exceeds that — extract it with a CLI instead.
Artifact with a huge file count
RejectedThe per-archive entryLimit (Pro 50,000, top tiers 500,000) can trip on a node_modules-style archive with tens of thousands of tiny files even when the bytes are small. Split it or use a CLI.
Wheel vs sdist confusion
ExpectedA .whl is a ZIP and unpacks fully; an sdist .tar.gz is gz and comes out as a .tar. Same Python package, different one-level outcome — expect the wheel to be ready and the sdist to need a second pass.
WebAssembly disabled in a hardened dev browser
Failed7z/RAR/bz2/xz/ISO need the libarchive WASM bridge. If your browser blocks WASM, those formats fail (ZIP/GZIP/TAR via fflate still work). Allow WASM or use a CLI for those formats.
Expecting reproducible-build timestamps in the output
By designThe output ZIP carries fresh timestamps from re-zipping, not the source's. For reproducible builds, normalise deliberately with timestamp-normalizer on a created archive — the Batch Extractor is for unpacking, not reproducible packing.
Frequently asked questions
Is there a CLI or API I can script?
Not for archive tools — they're browser-only with no public HTTP endpoint (apiAvailable: false). For scripted CI work, use unzip/tar/7z. The Batch Extractor is the interactive tool for ad-hoc local inspection; the @jadapps/runner can drive it via headless Chromium on Pro+, but it isn't a file-accepting API.
Will it unpack an npm package end to end?
Not in one pass. A .tgz is detected as gz and comes out as a single .tar. Run that through nested-archive-extractor to read the package contents.
Do Python wheels work directly?
Yes — wheels are ZIP archives, so they unpack fully in one shot. Only the .tar.gz sdist form needs the extra nested pass.
Can it read a 7z release without p7zip installed?
Yes, via the libarchive WASM bridge that ships with the page. RAR works the same way. Your browser must allow WebAssembly.
Does it create or write 7z / tar output?
No. The output is always a ZIP. To build a ZIP from files use folder-to-zip; to convert formats use archive-format-converter.
How do I stop two artifacts from overwriting each other?
Give them unique filenames before dropping. Subfolders are named by stem with no counter, so dist.zip + dist.zip collide. Use dist-<job>.zip to keep them in separate folders.
How many artifacts can I drop at once?
Free 1 (so batching needs Pro), Pro 20, Pro-media 100, Developer unlimited — bounded by browser memory for the combined uncompressed bytes.
Does it handle password-protected release archives?
No — there's no password field, and encrypted entries are rejected. Decrypt with a CLI first. To test a candidate password, use archive-password-tester.
Are my proprietary artifacts uploaded anywhere?
No. Archive tools run entirely in your browser with no upload path. Build outputs stay on your machine, which is the point for closed-source releases.
Can I select only certain files from each artifact?
Not in this tool — it unpacks everything. For pattern-based extraction use selective-extractor with a glob, one archive at a time.
What's the fastest way to diff two builds?
Drop both into the Batch Extractor (renamed uniquely), unpack the output, and run diff -r on the two subfolders. For a structural ZIP-vs-ZIP comparison without unpacking, see archive-diff.
Does the output preserve directory structure inside each artifact?
Yes — internal folder structure is kept under the stem prefix. Empty directory entries from ZIP reads are dropped, but every file keeps its full relative path.
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.