How to multi-part archive creator vs cli splitters (zip -s, split, 7z -v)
- Step 1Decide on output style — If your recipient expects raw concatenation (cat/copy /b), the browser tool and split match exactly. If they expect spanned .z01 volumes, use zip -s; if they expect 7z volumes, use 7z -v.
- Step 2Compare on throughput — For bundles under a few hundred MB the browser tool finishes in seconds (fflate is fast). For multi-GB inputs a native CLI streams from disk and avoids browser memory limits — prefer the CLI past your tier's 2 GB cap.
- Step 3Compare on privacy — Both are local. The browser tool reads files via the File API and never uploads; the CLI reads from disk. The browser path additionally needs no install rights — useful on a managed laptop.
- Step 4Compare on reassembly — Browser + split: cat archive.zip.* > archive.zip. zip -s: rejoin with zip -s 0. 7z -v: open the .001 in 7-Zip. Match the producer to what the recipient can run.
- Step 5Compare on compression — The browser tool is fixed at DEFLATE level 6. zip and 7z let you pick levels and (7z) LZMA2 for tighter output. If size is critical and the recipient has 7-Zip, the CLI wins on ratio.
- Step 6Pick and produce — For a quick, private, install-free split that anyone can rejoin with cat/copy, use the browser tool. For scripted or multi-GB jobs, reach for the CLI.
Splitter approaches side by side
What each tool emits, how you rejoin it, and the practical constraints. JAD's tool matches the split style most closely.
| Approach | Output | Rejoin | Compression control |
|---|---|---|---|
| JAD Multi-Part Creator | archive.zip.001 … .NNN (raw byte split of one ZIP) | cat archive.zip.* > archive.zip / copy /b | Fixed DEFLATE level 6 |
zip -s 25m | name.z01 … name.zip (spanned multi-volume) | zip -s 0 name.zip --out joined.zip | DEFLATE levels 0–9 via -0…-9 |
split -b 25m | part_aa, part_ab, … raw byte chunks | cat part_* > file.zip | None (operates on the finished file) |
7z a -v25m | name.7z.001 … .NNN (7z volumes) | Open .001 in 7-Zip / 7z x name.7z.001 | LZMA/LZMA2 levels; tighter than DEFLATE |
When to use which
Decision guide. The browser tool wins on convenience and privacy; the CLI wins on scale and ratio.
| Situation | Best choice | Why |
|---|---|---|
| No install rights on the machine | JAD browser tool | Runs in the tab; no toolchain needed |
| One-off bundle under ~500 MB | JAD browser tool | Seconds to run, nothing to set up, easy rejoin |
| Scripted/CI pipeline | zip -s or split | Deterministic, automatable, no UI |
| Input larger than 2 GB | CLI (split / 7z) | Streams from disk; beyond browser tier caps |
| Maximum compression matters | 7z a -v -mx9 | LZMA2 beats DEFLATE level 6 on most data |
| Recipient only has cat/copy | JAD browser tool or split | Raw byte parts rejoin with no special tool |
Tier limits for the browser path
The browser tool is Pro-minimum. These caps decide when you should fall back to a CLI for scale.
| Tier | Max input size | Entry limit | Files per job |
|---|---|---|---|
| Pro | 500 MB | 50,000 | 20 |
| Pro + Media | 2 GB | 500,000 | 100 |
| Developer | 2 GB | 500,000 | unlimited |
Cookbook
Equivalent commands and outputs, so you can map a CLI workflow onto the browser tool (and back).
Browser tool ≈ split on the finished ZIP
The browser tool's part style is the same idea as zip then split. Both rejoin with cat.
# CLI equivalent of what the browser tool does: zip -r -6 archive.zip ./files # build ZIP at level 6 split -b 25000000 archive.zip archive.zip. # 25 MB raw parts # Browser tool: drop ./files, Part size 25 → archive.zip.001 … # Rejoin (both): cat archive.zip.* > archive.zip
zip -s spanned volumes (different output)
zip -s produces .z01/.z02/.zip, which rejoin differently. Don't mix the two reassembly recipes.
$ zip -s 25m -r bundle.zip ./files ... bundle.z01 bundle.z02 bundle.zip # Rejoin spanned volumes: $ zip -s 0 bundle.zip --out joined.zip $ unzip joined.zip # NOTE: 'cat bundle.z*' does NOT work for spanned volumes.
7z volumes for tighter compression
If the recipient has 7-Zip and you need a smaller payload, 7z volumes beat DEFLATE level 6.
$ 7z a -v25m -mx9 bundle.7z ./files ... bundle.7z.001 bundle.7z.002 $ 7z x bundle.7z.001 # auto-finds the rest # Trade-off: requires 7-Zip; smaller than the browser tool's DEFLATE-6 output.
Rejoin a browser-tool split on Windows
The browser parts use the same cat/copy recipe as split. On Windows, copy /b in binary mode.
C:\> copy /b archive.zip.001+archive.zip.002+archive.zip.003 archive.zip C:\> tar -xf archive.zip
Why level matters for the size delta
The browser tool is locked to level 6. On text-heavy bundles, 7z -mx9 (LZMA2) is meaningfully smaller; on already-compressed media the gap nearly vanishes.
Source: 100 MB of mixed source code + assets DEFLATE level 6 (browser tool): ~38 MB ZIP → 2 × 25 MB parts LZMA2 -mx9 (7z): ~29 MB → fewer/smaller parts (Media-heavy inputs: both land within a few % of each other.)
Edge cases and what actually happens
Recipient tried cat on zip -s volumes
Reassembly failsSpanned .z01/.z02 volumes are NOT raw byte chunks — concatenating them produces an invalid archive. Spanned volumes need zip -s 0 to rejoin. The browser tool avoids this trap entirely by emitting raw byte parts that DO rejoin with cat.
Mixing browser parts with 7z reassembly
Wrong rejoinarchive.zip.001 from the browser tool is a ZIP byte slice, not a 7z volume. Use cat/copy, not 7z x. (7-Zip can still open archive.zip.001 because it recognises the byte-split convention, but the underlying container is ZIP.)
You need a true CLI script
Use the CLIThe browser tool has no command-line interface or public API. For unattended/CI use, zip -s, split, or 7z -v are the right tools — they're scriptable and deterministic.
Bundle exceeds 2 GB
Tier limit exceededEven on Developer the input cap is 2 GB. Past that, a streaming CLI (split, 7z) reading from disk is the practical choice — the browser holds the whole input in memory.
You want the smallest possible parts
CLI wins on ratioThe browser tool is fixed at DEFLATE level 6. 7z -mx9 (LZMA2) compresses tighter, so the same content yields fewer/smaller parts. Choose 7z when the recipient can open it and size is the priority.
Locked-down corporate laptop, no install rights
Browser winsWhen you can't install or run a CLI, the browser tool is the only local-processing option. It runs in the tab with no admin rights and never uploads your files.
You expected ZIP comments or timestamps preserved across the split
By designThe split is purely at the byte level of the freshly built ZIP, so once rejoined the ZIP is intact with its level-6 entries. There's no separate metadata to lose — but note the tool builds the ZIP fresh from your files, so source-file timestamps become the ZIP entry timestamps.
Recipient on Windows without tar/unzip
SupportedWindows 10+ ships bsdtar (tar.exe) and PowerShell's Expand-Archive. After copy /b rejoins the parts, either can extract the ZIP. No third-party tool is strictly required.
Comparing speed on tiny files
Both instantFor small bundles the difference is negligible — both the browser tool and a CLI finish before you notice. The comparison only matters at scale (hundreds of MB to GB).
Need encryption plus splitting
Combine toolsThe browser tool doesn't encrypt. With a CLI, 7z -p -v does both. In the browser, encrypt with encrypted-zip-creator then split that ZIP with archive-splitter.
Frequently asked questions
Is the browser tool's output the same as zip -s?
No. zip -s makes spanned multi-volume archives (.z01/.z02/.zip) that rejoin with zip -s 0. The browser tool makes raw byte parts (archive.zip.001 …) that rejoin with cat or copy /b — the same style as split.
Which is closest to the browser tool, split or 7z?
split. Both produce raw byte chunks of a finished archive and both rejoin with cat. 7z -v makes 7z-format volumes with their own container and reassembly.
Can I script the browser tool?
No — there's no CLI or public API for it. For automation use zip -s, split, or 7z -v on the command line.
Does the browser tool compress as tightly as 7z?
No. It's fixed at DEFLATE level 6. 7z's LZMA2 (-mx9) is tighter, especially on text/source. On already-compressed media the difference is small.
Why would I use the browser tool over a CLI at all?
Zero install, zero upload, and a rejoin recipe (cat/copy) anyone understands — ideal on locked-down machines, for one-off jobs, or for non-technical recipients.
Is the browser tool private?
Yes. Files are processed by fflate WebAssembly in your tab and never uploaded. A local CLI is also private; the difference is the browser needs no toolchain.
What's the largest bundle the browser tool handles?
Pro 500 MB, Pro + Media and Developer 2 GB. Beyond that, use a streaming CLI.
Can recipients rejoin browser parts without any tool?
They need a way to concatenate (cat on Unix, copy /b on Windows) and a ZIP extractor. Both ship with modern OSes.
Do the parts have to be downloaded together?
Yes — you need every part to rejoin. The result panel offers a 'Download N parts' action; save them all in one folder.
Is one MB 1,000,000 or 1,048,576 bytes?
The browser tool uses 1,000,000 (decimal): partBytes = partMb × 1,000,000. split -b 25m typically uses the same decimal sense; 7z -v25m uses MiB. Check before matching part counts exactly.
Can the browser tool split an existing archive?
No — it builds a new ZIP from local files. To split an archive you already have, use the Archive Splitter (browser) or split (CLI).
Will GUI tools open archive.zip.001?
Usually yes — 7-Zip, WinRAR, and Keka recognise the .001/.002 convention and auto-join. If yours doesn't, concatenate first with cat/copy.
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.