How to batch extractor vs unzip / 7z cli / winrar
- Step 1Decide whether privacy is the deciding factor — If the archives are confidential and the machine isn't fully yours (shared CI runner, a colleague's laptop, a kiosk), the browser tool's no-upload guarantee is the reason to use it over
unzip. If the files are non-sensitive and you live in a terminal, the CLI is fine. - Step 2Check whether you need recursion or passwords — If sources contain nested archives or are password-protected, the CLI (
7z x,unzip -P) is the better fit — the Batch Extractor does neither. For nesting only, you can still use the browser tool and finish with nested-archive-extractor. - Step 3Confirm the formats involved — The Batch Extractor reads ZIP/GZIP/TAR (fflate) and 7z/RAR/bz2/xz/ISO (libarchive WASM). WinRAR and 7-Zip read those too; stock
unzipreads only ZIP. If your batch is all ZIP, any tool works; mixed formats favour the browser tool over plainunzip. - Step 4Match the workload to the tier caps — The browser tool is bounded by tier: Pro is 500 MB / 50,000 entries / 20 files; Pro-media and Developer reach 2 GB / 500,000 entries / 100+ files. A multi-gigabyte forensic image is CLI territory; a few hundred log ZIPs fit comfortably in the browser.
- Step 5Drop the batch or run the loop — In the browser: drag every archive onto batch-extraction-manager and download the consolidated ZIP. In the shell: a
forloop with per-file output directories reproduces the subfolder behaviour. - Step 6Verify the output the same way in both — The browser tool reports
Input archivesandTotal entries; the CLI gives you exit codes andls -R. In both, watch for fewer entries than expected — in the browser that means a stem collision; in the shell it usually means a-ooverwrite or a non-zero exit you didn't check.
Feature matrix
How JAD's Batch Extractor compares with common extraction tools. Browser-tool rows reflect the actual implementation, not marketing.
| Capability | JAD Batch Extractor | unzip (stock) | 7-Zip CLI / WinRAR |
|---|---|---|---|
| Install required | None (runs in browser) | Usually preinstalled (POSIX) | Manual install / licence |
| Files leave your machine | No — no upload path | No (local) | No (local) |
| Reads ZIP / GZIP / TAR | Yes (fflate) | ZIP only | Yes |
| Reads 7z / RAR / bz2 / xz / ISO | Yes (libarchive WASM) | No | Yes |
| Password-protected archives | No | Yes (-P) | Yes |
| Recurses nested archives | No (one level) | No (one level) | No by default |
| Batch + consolidate output | Yes (one output ZIP) | Manual loop | Manual loop / GUI |
| Size / entry ceiling | Tier-bound (to 2 GB / 500k) | Disk-bound | Disk-bound |
When to use which
Pick by job, not habit. The browser tool and the CLI are complementary.
| Scenario | Best tool | Why |
|---|---|---|
| Confidential client archives on a shared machine | Batch Extractor | No upload path; nothing written to a server |
| A folder of mixed ZIP/7z/RAR, no CLI installed | Batch Extractor | Reads all of them via WASM, zero install |
| Password-protected archives | 7-Zip / WinRAR | Browser tool has no password field |
| Deeply nested archives-in-archives | 7-Zip CLI (scripted) | Browser tool is one level; or chain nested-archive-extractor |
| Multi-GB forensic image / huge tarball | CLI | Disk-bound, not memory-bound; no tier cap |
| Quick consolidation of a few dozen log ZIPs | Batch Extractor | One drop, one consolidated output ZIP |
Cookbook
The same job done both ways, so the trade-offs are concrete rather than abstract.
Consolidating log ZIPs: browser vs shell
The Batch Extractor's headline behaviour reproduced as a shell loop. The browser version needs no install and leaks nothing; the shell version handles unlimited size.
Browser: drop app-01.zip ... app-30.zip ->
batch-extracted-30-archives.zip (each under its stem/)
Shell equivalent:
for f in *.zip; do
unzip -q "$f" -d "out/${f%.zip}"
done
zip -qr batch.zip out/Reading 7z without p7zip installed
Stock unzip can't touch 7z. The browser tool reads it via the libarchive WASM bridge with nothing to install.
$ unzip backup.7z Archive: backup.7z End-of-central-directory signature not found ... Browser: drop backup.7z onto the Batch Extractor -> backup/db.sql, backup/schema.sql (read via WASM)
Password archive: where the CLI is required
The Batch Extractor rejects encrypted entries because it has no password input. The CLI is the right tool here.
Browser: drop secret.zip (AES entries) -> Error: "Archive contains encrypted entries ... Provide a password" (the Batch Extractor has no password field) CLI: 7z x secret.7z -psuperpass unzip -P superpass secret.zip
tar.gz: both stop at one level
Neither plain unzip nor the Batch Extractor unpacks a gzipped tarball in one shot. The browser tool emits a .tar; gzip + tar (or 7z twice) is the CLI path.
Browser: drop release.tar.gz -> release/release.tar (still packed) then run /archive-tools/nested-archive-extractor CLI: tar -xzf release.tar.gz # one command, fully unpacked
Tier ceiling vs disk: the big-file line
A 6 GB image exceeds even the top browser tier's 2 GB file cap. That is a clear CLI job.
Browser (any tier): drop disk-image.iso (6 GB) -> rejected: over the 2 GB file cap CLI: 7z x disk-image.iso -oout/ # disk-bound, no cap
Edge cases and what actually happens
Source archives are password-protected
CLI winsThe Batch Extractor has no password field and rejects encrypted entries. unzip -P, 7z x -p, or WinRAR handle this. Decrypt with the CLI, then optionally batch the cleartext output in the browser.
Deeply nested archives-in-archives
CLI winsThe browser tool extracts one level. A scripted 7z loop or repeated extraction recurses; in the browser, chain the output into nested-archive-extractor which is purpose-built for depth.
Multi-gigabyte single archive
CLI winsThe browser tool holds all uncompressed bytes in memory and is bounded by the 2 GB top-tier file cap. The CLI is disk-bound, so a 10 GB tarball is routine there and impossible in the browser.
Untrusted archives on a shared machine
Browser winsRunning unzip writes files to a disk you may not control and may execute hooks in some workflows. The Batch Extractor processes in-page with no upload and no disk write until you download, which limits exposure.
Mixed formats, no toolchain
Browser winsA laptop with only stock unzip can't read 7z or RAR. The Batch Extractor reads both via the libarchive WASM bridge with nothing to install.
Two sources share a stem
Both need careThe browser tool overwrites same-stem sources (subfolder = stem, no counter). A shell loop using -d "${f%.zip}" has the same collision if two files share a base name. Rename to disambiguate in either tool.
You need a non-ZIP output
CLI winsThe Batch Extractor always outputs a ZIP. If you need the extracted tree as loose files or a tar, the CLI gives you that directly. For format conversion in-browser, see archive-format-converter.
Scripted / unattended pipeline
CLI winsThere is no public HTTP API for archive tools, so a headless server cron job can't call the Batch Extractor. The CLI scripts cleanly. On Pro+ the @jadapps/runner drives the tool in headless Chromium, but it is not a file-accepting endpoint.
Frequently asked questions
Is the browser tool faster than the CLI?
For small-to-medium batches the difference is negligible and the browser tool wins on convenience (no install). For very large archives the CLI is faster and unbounded because it works on disk rather than holding everything in memory.
Can the Batch Extractor read everything 7-Zip can?
It reads the common set — ZIP, GZIP, TAR, 7z, RAR, bz2, xz, ISO — via fflate and a libarchive WASM bridge. 7-Zip supports a longer tail of niche formats. For mainstream archives they overlap; for exotic containers the CLI goes further.
Does the browser tool write 7z or RAR like WinRAR?
No. It only ever writes a ZIP. The libarchive bridge is read-only in-browser. To create a ZIP from files use folder-to-zip; for an encrypted ZIP use encrypted-zip-creator.
Why would I use a browser tool over a trusted CLI I already have?
Three reasons: the machine isn't yours (no install rights), the files are sensitive and you want a no-upload guarantee, or your batch mixes formats your stock unzip can't read. Otherwise the CLI is perfectly good.
Does it handle passwords like unzip -P?
No — there is no password field in this tool, and it rejects encrypted entries. For password work use the CLI, or archive-password-tester to check a candidate password.
Can I script the Batch Extractor in CI?
Not as an HTTP API — archive tools are browser-only with no public endpoint. In CI, use the actual CLI. The @jadapps/runner can drive the tool via headless Chromium on Pro+ tiers, but it isn't a server you POST files to.
Does the Batch Extractor recurse like 7z's nested handling?
No. It is strictly one level. For recursion, either script the CLI or pass the output to nested-archive-extractor.
What happens to a .tar.gz in each tool?
The CLI's tar -xzf unpacks it fully in one command. The Batch Extractor detects the gz layer, gunzips once, and emits the inner .tar — you then need a second pass to unpack the tar.
Is there a file-count or size cap on the CLI like the browser tool?
No — the CLI is bounded only by disk and time. The browser tool is bounded by tier (to 2 GB file size, 500,000 entries, and 100+ files per batch at the top tiers).
Can I use both together?
Yes, and it's often best. Use the browser tool to consolidate a pile of mixed archives into one ZIP, then process that ZIP with whatever CLI tooling your pipeline already has — the output is a standard DEFLATE ZIP.
Which is better for incident-response log triage?
The browser tool shines for quickly consolidating many log ZIPs with no install and no upload. For multi-GB captures or password-locked evidence archives, the CLI is the right call. See the DevOps and incident-response guide.
Does the browser tool leave temp files behind like the CLI can?
No. It builds the output ZIP in memory and only writes to disk when you click download. The CLI writes the extracted tree to disk as it goes, which you then have to clean up.
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.