How to multi-part archive creator in developer workflows
- Step 1Open the tool — Go to /archive-tools/multi-part-archive-creator on a Pro plan or higher (it's Pro-minimum). Drop the artifact's files onto the dropzone.
- Step 2Set the part size to the consumer's cap — Type Part size in MB to match the registry/email/form limit. Remember 1 MB = 1,000,000 bytes here, so set the value just under the consumer's documented ceiling.
- Step 3Generate the parts — Click Generate. fflate builds the ZIP at level 6 and slices it into ceil(totalBytes / partBytes) parts. The result panel lists each part with its size.
- Step 4Make it reproducible (optional) — If you need bit-identical output across rebuilds, the source-file modified times become the ZIP entry timestamps. Run the result through /archive-tools/timestamp-normalizer with a fixed date (1980-01-01) — but note that tool splits/operates on a single archive, so normalise the rejoined ZIP, not the parts.
- Step 5Emit a checksum manifest (optional) — Run /archive-tools/checksum-generator over the bundle to produce a SHA-256 manifest your pipeline can verify after the consumer rejoins the parts.
- Step 6Hand off with a rejoin note — Tell the consumer to run cat archive.zip.* > archive.zip (or copy /b on Windows) then extract. Ship all parts together.
Developer-relevant facts (no guessing)
What the implementation actually exposes. Claims about a CLI, API, or level control are not accurate for this tool.
| Question | Reality | Implication |
|---|---|---|
| Is there a CLI/API? | No | Use it interactively; for scripts use fflate (Node) + a byte split, or the zip/split CLIs |
| Can I pick a compression level? | No — fixed at DEFLATE level 6 | For level comparison use compression-level-optimizer |
| Does it split an existing artifact ZIP? | No — it builds a new ZIP from files | To split an existing archive use archive-splitter |
| Are timestamps reproducible? | No by default — source mtimes are used | Normalise with timestamp-normalizer on the rejoined ZIP |
| What are parts named? | archive.zip.001 … .NNN (zero-padded) | Globs and sorts correctly for scripted rejoin on the consumer |
Part sizes for common artifact consumers
Type the value into the Part size field. Set just under the documented cap because 1 MB = 1,000,000 bytes (decimal).
| Consumer | Part size (MB) | Why |
|---|---|---|
| Email a teammate (Gmail) | 25 | 25 MB attachment cap (tool default) |
| GitHub Release asset note | 1900 | Stay well under the 2 GB per-asset ceiling with margin |
| Chat upload (Discord free) | 8 | 8 MB per-file limit |
| Flaky form / resumable | 5–50 | Smaller parts retry faster on drop-outs |
| FAT32 transfer drive | 4000 | Under the 4 GiB single-file limit |
Tier limits (archive family)
Pro-minimum tool. The size cap is the total of dropped files; part size is independent.
| 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
Practical developer recipes for splitting artifacts and rejoining them on the consuming side. Filenames are illustrative.
Email a 40 MB debug-symbols pack
A symbols pack overshoots Gmail's 25 MB cap. Default part size splits it into two attachable parts.
Input: app-1.4.0.dSYM/ + build.log (~40 MB total) Part size: 25 Output: archive.zip.001 25.0 MB archive.zip.002 ~15 MB Attach one part per email; teammate rejoins with cat.
Scripted rejoin in a consumer's CI step
On the consuming side, reassembly is trivially scriptable because the parts are zero-padded and sort in order.
# CI step on the consumer: cat artifact/archive.zip.* > artifact/full.zip unzip -q artifact/full.zip -d ./payload # integrity (optional): sha256sum -c artifact/payload.sha256sums
Make output reproducible
The tool uses source-file modified times as ZIP entry timestamps, so the same files on two machines can differ. Normalise the rejoined ZIP to a fixed epoch.
# After rejoin: cat archive.zip.* > full.zip # Then in the browser: timestamp-normalizer on full.zip, date 1980-01-01 # Result: bit-identical ZIP across machines → matching SHA-256.
Node equivalent (since there's no API)
If you must script the whole thing, fflate plus a manual byte slice reproduces what the browser tool does.
import { zipSync } from 'fflate';
import { writeFileSync, readFileSync } from 'fs';
const zip = zipSync({ 'a.bin': readFileSync('a.bin'), 'b.bin': readFileSync('b.bin') }, { level: 6 });
const part = 25_000_000;
for (let i = 0, n = 1; i < zip.length; i += part, n++)
writeFileSync(`archive.zip.${String(n).padStart(3,'0')}`, zip.subarray(i, i + part));Compare levels before committing to a split
This tool is locked to level 6. If you want to know whether level 9 would cut a part, benchmark first.
compression-level-optimizer → runs levels 1/3/6/9, reports size+time If level 9 drops the ZIP under one part boundary, build that ZIP elsewhere and split it with archive-splitter instead.
Edge cases and what actually happens
Looking for a CLI flag or API endpoint
Not availableThis tool has no command-line interface and no public API. For automation, replicate it with fflate (Node) + a byte slice, or use zip/split on the command line. Treat the browser tool as an interactive utility.
Expecting a compression-level control
Fixed at level 6There's no level slider on this tool — fflate runs at DEFLATE level 6. To see whether another level helps, use compression-level-optimizer; to split a tighter ZIP you built elsewhere, use archive-splitter.
Output isn't bit-identical across machines
Expected without normalisationThe tool writes each source file's modified time into its ZIP entry, so the same inputs on two machines can yield different bytes. Normalise the rejoined ZIP with timestamp-normalizer (e.g. 1980-01-01) for reproducible output.
Dropped a built artifact ZIP to split it
Wrong toolIt builds a new ZIP from files — a dropped .zip gets nested. To split an existing artifact archive use archive-splitter.
Artifact exceeds the tier size cap
Tier limit exceededPro 500 MB, Pro + Media / Developer 2 GB total input. Large artifacts may exceed even 2 GB — build the ZIP with a streaming approach (or streaming-zip-builder for the build), then split with the Archive Splitter.
Consumer rejoined parts out of order
Reassembly failsarchive.zip.001 must lead. The zero-padded names sort correctly with cat archive.zip.* and copy /b archive.zip.*, but an explicit out-of-order list yields an invalid ZIP. Document the glob recipe for consumers.
A part went missing from the artifact set
Reassembly failsAll parts are required; there's no parity. CI consumers should assert the expected part count (e.g. ls archive.zip.* | wc -l) before rejoining.
Already-compressed payload (binaries, media)
ExpectedDEFLATE level 6 won't shrink entropy-dense artifacts much, so the part count tracks the raw size. Normal — the point is fitting the consumer's cap.
Need encryption for the artifact
Use another toolThis tool doesn't encrypt. Build an AES-256 ZIP with encrypted-zip-creator, then split that encrypted ZIP with archive-splitter.
Comparing two artifact versions after a change
Use a diff toolTo see exactly which entries changed between two artifact archives, use archive-diff — it compares before/after entry sets, equivalent to diff -r on extracted trees.
Frequently asked questions
Is there a CLI or API for this tool?
No. It's a browser-only interactive tool with no public API. For automation, replicate it with fflate in Node plus a byte slice, or use the zip/split CLIs.
Can I set the compression level?
No — it's fixed at DEFLATE level 6. Use the Compression Level Optimizer to benchmark other levels, and Archive Splitter if you want to split a ZIP you built at a different level.
How do I make the output reproducible?
The tool stamps ZIP entries with the source files' modified times, so output isn't reproducible by default. Rejoin the parts, then run the Timestamp Normaliser with a fixed date (1980-01-01) on the resulting ZIP.
Does it split an existing artifact archive?
No — it builds a new ZIP from local files. To split an archive you already have, use the Archive Splitter.
How does a CI consumer rejoin the parts?
cat artifact/archive.zip.* > full.zip then unzip full.zip. The zero-padded names guarantee correct order under the wildcard.
How can I verify the artifact after rejoin?
Generate a SHA-256 manifest with the Checksum Generator before handoff, and have the consumer run sha256sum -c after rejoin. The Archive Integrity Tester can CRC-check the rejoined ZIP.
What's one MB in part-size terms?
1,000,000 bytes (decimal): partBytes = partMb × 1,000,000. Set the value just under the consumer's documented cap.
What's the maximum artifact size?
Pro 500 MB, Pro + Media and Developer 2 GB total. Beyond that, build with a streaming approach and split with the Archive Splitter.
Can I script bulk splits?
Not through this tool. For batches, script fflate + byte-slicing in Node, or use the command-line zip/split tools.
How do I diff two artifact versions?
Use the Archive Diff tool to compare two archives' entry sets — it shows added/removed/changed entries without manual extraction.
Will the rejoined ZIP work in my CI extraction step?
Yes — it's a standard ZIP with no JAD wrapper. unzip, tar, and language ZIP libraries all read it.
Does it work on a fresh dev box?
Yes — it's browser-only with no install, so a clean machine with a modern browser is enough.
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.