How to troubleshooting the multi-part archive creator
- Step 1Confirm your plan — This tool is Pro-minimum. If you see a Pro overlay instead of a dropzone, you're on the Free plan — upgrade to Pro or higher to use it.
- Step 2Check the total size against your cap — The size cap applies to the combined dropped files, not the part size: Pro 500 MB, Pro + Media and Developer 2 GB. Trim the bundle or upgrade if you exceed it.
- Step 3Make sure you're dropping files, not an archive — This tool builds a new ZIP from local files. If you dropped a .zip/.7z/.tar to split it, switch to /archive-tools/archive-splitter, which splits an existing archive.
- Step 4Identify the real part files — Ignore the summary name archive-N-parts.zip. The files to keep and rejoin are archive.zip.001, archive.zip.002, … Save them all into one folder.
- Step 5Rejoin in the correct order — Unix: cat archive.zip.* > archive.zip. Windows: copy /b archive.zip.001+archive.zip.002 archive.zip. The .001 part must come first.
- Step 6Verify the rejoined ZIP — Try to unzip it. If it fails, a part is missing or out of order; if individual entries fail, run /archive-tools/archive-integrity-tester to localise CRC errors.
Symptom → cause → fix
The four most common failures and what to do about each.
| Symptom | Likely cause | Fix |
|---|---|---|
| Pro overlay instead of the dropzone | Free plan (tool is Pro-minimum) | Upgrade to Pro or higher |
| 'exceeds the … tier per-job limit' | Total bundle over the size cap | Trim files or upgrade the tier (Pro 500 MB; 2 GB on higher) |
| Dropped archive got nested in a new ZIP | Used the wrong tool | Use archive-splitter for an existing archive |
| Rejoined file won't unzip | Missing part or wrong order | Collect all parts; rejoin with .001 first |
| More parts than expected | MB is decimal (1,000,000 bytes) | Expected — partBytes = partMb × 1,000,000 |
| Only got archive.zip.001 | Bundle smaller than one part | Expected — it's a single part; just extract it |
Reassembly recipes
Order matters: archive.zip.001 first. The wildcard sorts correctly because parts are zero-padded.
| OS / tool | Command | Then |
|---|---|---|
| Unix / macOS | cat archive.zip.* > archive.zip | unzip archive.zip |
| Windows (cmd) | copy /b archive.zip.001+archive.zip.002 archive.zip | tar -xf archive.zip |
| Windows (PowerShell) | cmd /c copy /b archive.zip.* archive.zip | Expand-Archive archive.zip |
| 7-Zip / WinRAR / Keka | Open archive.zip.001 directly | Tool auto-joins the sequence |
Tier limits (archive family)
Pro-minimum tool. Size cap is the total of dropped files; entry limit is per archive.
| Tier | Max input size | Entry limit | Files per job |
|---|---|---|---|
| Free | 50 MB | 500 | 1 (tool requires Pro) |
| Pro | 500 MB | 50,000 | 20 |
| Pro + Media | 2 GB | 500,000 | 100 |
| Developer | 2 GB | 500,000 | unlimited |
Cookbook
Diagnostic walk-throughs for the failures users actually hit. Filenames and sizes are illustrative.
Pro overlay on the Free plan
The tool is Pro-minimum, so Free users never see the dropzone — only a Pro overlay. This is expected, not a bug.
Symptom: page shows 'Multi-Part Archive Creator requires the Pro plan.'
Cause: minTier = pro for this tool.
Fix: upgrade to Pro (or higher) to unlock the dropzone and the
500 MB / 50,000-entry caps.Surprising part count from decimal MB
Part size is in decimal MB (1,000,000 bytes), so a 50 MB part is 50,000,000 bytes — slightly more parts than if it were MiB. This is expected.
ZIP built: 105,000,000 bytes
Part size: 50 → partBytes = 50,000,000
Parts: ceil(105,000,000 / 50,000,000) = 3
archive.zip.001 (50 MB)
archive.zip.002 (50 MB)
archive.zip.003 (~5 MB)Rejoin fails — out of order
If parts are concatenated in the wrong order the result is an invalid ZIP. The fix is to ensure .001 leads; the wildcard handles this automatically.
WRONG (manual, out of order): copy /b archive.zip.002+archive.zip.001 archive.zip → invalid RIGHT: copy /b archive.zip.001+archive.zip.002 archive.zip → valid # or simply: cat archive.zip.* > archive.zip
You meant to split an existing archive
Dropping a finished .zip nests it inside a new ZIP, then splits that. Use the Archive Splitter for an existing archive.
Symptom: rejoined.zip contains 'mybackup.zip' instead of the files.
Cause: this tool re-zips whatever you drop, including archives.
Fix: use /archive-tools/archive-splitter on the existing .zip
(split by size or by entry count).Confirm the input is what you think
If a 'file' you dropped is actually something else (renamed), confirm its true type before assuming the tool failed.
Run /archive-tools/auto-format-detector on the file. It reads the leading magic bytes and reports the real format, e.g. a '.zip' that's actually a RAR — which you'd handle elsewhere.
Edge cases and what actually happens
Free plan user can't see the tool
Pro requiredMulti-Part Archive Creator has minTier Pro. The Free plan shows a Pro overlay instead of the dropzone — expected behaviour, not an error. Upgrade to use it.
Bundle over the tier size cap
Tier limit exceededThe error names your tier and the cap (Pro 500 MB; Pro + Media / Developer 2 GB). It's the combined size of dropped files that's checked, not the per-part size. Trim or upgrade.
Rejoined ZIP won't open
Reassembly failsAlmost always a missing part or wrong order. Confirm you have every part from .001 through the last, and rejoin with cat archive.zip.* (or copy /b with .001 first). A raw byte split has no recovery if a part is gone.
Reassembling archive-N-parts.zip
Wrong filearchive-N-parts.zip is just the summary/result name shown in the UI — it is not the file to rejoin. The real parts are archive.zip.001, archive.zip.002, … Reassemble those.
Dropped an existing archive to split it
Wrong toolThis tool builds a new ZIP from files, so a dropped archive ends up nested. Use archive-splitter to split an archive you already have.
Part count higher than expected
Expected (decimal MB)Part size is in decimal MB (1 MB = 1,000,000 bytes), and DEFLATE level 6 may not shrink your data much. Both push the part count up versus a MiB-based or higher-compression assumption. This is by design.
Got only one part
ExpectedIf the built ZIP is smaller than one part, you get a single archive.zip.001. It's a normal ZIP after extraction — no special rejoin needed.
Set part size to 0 or negative
ClampedThe processor applies Math.max(1, splitSizeMb), so values below 1 become 1 MB. You cannot produce zero or negative parts.
Browser extension blocks WebAssembly
Init may stallfflate runs as WebAssembly; an aggressive extension touching worker channels can interfere. Retry in a private/incognito window with extensions disabled, and hard-refresh (Ctrl+Shift+R) to clear a stale build.
Expected each part to extract on its own
By designIndividual parts are byte slices of one ZIP — only archive.zip.001 starts with the ZIP header, and no single middle part is a complete archive. You must rejoin all parts before extracting (or open .001 in a tool that auto-joins).
Frequently asked questions
Why do I see a Pro overlay instead of the tool?
Multi-Part Archive Creator is Pro-minimum (minTier Pro). On the Free plan the dropzone is replaced by a Pro overlay. Upgrade to Pro or higher to use it.
Why did my file get rejected before processing?
Your total bundle exceeds the tier size cap — Pro 500 MB, Pro + Media and Developer 2 GB. The check is on the combined size of dropped files, not the per-part size.
Which files do I actually rejoin?
The parts named archive.zip.001, archive.zip.002, … Ignore the summary name archive-N-parts.zip shown in the UI — that's not a reassembly file.
My rejoined ZIP won't open — what's wrong?
Usually a missing part or wrong order. Make sure you have every part and that .001 comes first: cat archive.zip.* > archive.zip, or copy /b archive.zip.001+archive.zip.002 archive.zip.
Why are there more parts than I expected?
Part size is decimal MB (1,000,000 bytes), and DEFLATE level 6 may not compress your data much. Both raise the part count versus a MiB or higher-compression assumption.
Can a single part be extracted by itself?
No. Each part is a byte slice; only .001 has the ZIP start, and middle parts aren't complete archives. Rejoin all parts first (or open .001 in a tool that auto-joins).
I wanted to split an archive I already have — why did it get nested?
This tool builds a new ZIP from whatever you drop, so an existing archive ends up inside the new ZIP. Use the Archive Splitter for an existing archive.
It's stuck on 'Processing…' — what now?
Hard-refresh (Ctrl+Shift+R) to clear a stale build, and try a private window with browser extensions disabled, since they can interfere with WebAssembly init.
Can I set a smaller part size than 1 MB?
No — the minimum is 1 MB. Values below 1 are clamped up to 1 (Math.max(1, splitSizeMb)).
How do I confirm a file is really an archive?
Use the Archive Format Detector — it reads the leading magic bytes and reports the true format, catching renamed files.
An entry inside the rejoined ZIP is corrupt — how do I check?
Run the Archive Integrity Tester on the rejoined ZIP. It compares each entry's stored CRC32 against the computed value and flags mismatches.
Do I need special software to rejoin parts?
No — cat (Unix/macOS) or copy /b (Windows) plus a standard ZIP extractor is enough. 7-Zip, WinRAR, and Keka can also open archive.zip.001 directly.
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.