How to zip to 7z in developer workflows
- Step 1Grab the artifact — Download the
.zipfrom your CI job, GitHub release, or vendor portal. This tool takes one archive at a time, so if you have several, convert them one by one (or script the runner on Pro+). - Step 2Drop it into the tool — Open zip-to-7z and drop the ZIP. There are no options to set — fflate extracts it and re-GZIPs the TAR at level 6. Sub-second for typical artifacts.
- Step 3Read the metrics, not just the filename — Confirm Source: ZIP, Target: TAR.GZ (7Z fallback), the entry count, and input vs output size. The 'Native 7Z: unavailable in browser' line is your reminder this is TAR.GZ — useful before you hand it to a colleague who literally asked for 7z.
- Step 4Download and rename if your pipeline needs a specific name — The file is
<stem>.tar.gz. If a downstream job expectsrelease-1.2.3.tar.gz, rename on download. The extension and content are a standard gzipped tar. - Step 5For repeatable jobs, use the runner — There is no REST API for archive tools (apiAvailable is false). To automate, pair the @jadapps/runner (Pro+), which executes the tool in a headless Chromium session locally — same code, no upload, scriptable from your build.
- Step 6Normalise for reproducibility if needed — If the artifact feeds a reproducible build, remember the TAR header uses the current time. Pre-normalise the ZIP with timestamp-normalizer and/or normalise mtimes after extraction so hashes are stable across runs.
Interactive vs automated use
Verified: archive tools are browser-only with apiAvailable=false. There is no HTTP tool endpoint; Pro+ automation goes through the runner's headless browser.
| Mode | How | Tier | Notes |
|---|---|---|---|
| Interactive (UI) | Drop a ZIP on the tool page | Free+ | One archive at a time; no options |
| Automated | @jadapps/runner (headless Chromium) | Pro+ | Same browser code; runs locally, no upload |
| REST API call | Not available | — | apiAvailable is false for archive tools |
| CLI equivalent (no JAD) | unzip then tar czf | n/a | Reproduces output without the tool |
What the conversion does and does not change
Grounded in the conversion handler. Use this to decide whether the re-pack is safe to drop into a pipeline.
| Aspect | Behaviour | Pipeline implication |
|---|---|---|
| File contents | Byte-identical | Safe to substitute; checksums match |
| Container | ZIP -> TAR.GZ (GZIP level 6) | Downstream must accept gzipped tar |
| Compression level | Fixed at 6, no options | Predictable size; not LZMA2-tight |
| Empty directories | Dropped | Recreate in build if required |
| Timestamps | Set to conversion time | Bust caches / hashes — normalise |
| Output filename | <stem>.tar.gz | Rename if a job expects a fixed name |
Cookbook
Developer-shaped recipes. Where automation is shown, it uses the runner (there is no REST API) or the CLI equivalent.
Triage a CI release ZIP into the format your scripts expect
Your deploy script consumes .tar.gz, but the CI job emits .zip. Re-pack interactively before the manual deploy.
Download: release-1.4.0.zip (from CI) zip-to-7z -> release-1.4.0.tar.gz Metrics: Source ZIP -> Target TAR.GZ (7Z fallback), 412 entries Then: ./deploy.sh release-1.4.0.tar.gz
The exact CLI equivalent for a scripted pipeline
Since there is no REST API, if you want a pure-script path without the runner, reproduce the tool with standard utilities.
# Equivalent of zip-to-7z: unzip release.zip -d _x/ tar czf release.tar.gz -C _x . rm -rf _x # Same output container the browser tool produces (gzip level 6 ~ default).
Automate with the runner (no upload, Pro+)
Pair the @jadapps/runner once; it runs the tool in a local headless browser so source artifacts never leave the machine. Conceptual flow shown — wire it into your CI step.
# Conceptual runner flow (Pro+): # 1. pair @jadapps/runner with your account once # 2. CI step hands release.zip to the runner -> tool 'zip-to-7z' # 3. runner returns release.tar.gz, processed in headless Chromium # No data leaves the build host; no REST endpoint involved.
Make the artifact reproducible
Re-converting the same ZIP yields different timestamps (TAR uses 'now'), which breaks content-addressed caches. Normalise first.
Naive: release.zip -> release.tar.gz (twice) -> different mtimes -> cache miss
Fixed:
1. timestamp-normalizer on release.zip (epoch 1980-01-01)
2. zip-to-7z -> release.tar.gz
3. in CI, after extract: find . -exec touch -d @0 {} +Prove the re-pack didn't corrupt the artifact
Gate the pipeline on a checksum match between the source ZIP's contents and the converted TAR.GZ's contents.
checksum-generator on release.zip -> app sha256: 9c1b...77 zip-to-7z -> release.tar.gz checksum-generator on release.tar.gz -> app sha256: 9c1b...77 Match -> contents intact -> proceed with deploy.
Edge cases and what actually happens
Looking for a REST API endpoint
Not availableArchive tools are browser-only and apiAvailable is false — there is no GET /api/v1/tools/zip-to-7z or /run endpoint. For automation, use the @jadapps/runner (Pro+), which executes the tool in a headless Chromium session, or reproduce it with unzip + tar czf in your script.
Expecting a native .7z artifact
By designThe output is .tar.gz, not .7z. If a release process or downstream system specifically checks for a 7Z magic header, it will reject the file. The metrics say so explicitly ('Native 7Z: unavailable in browser'). Use a native 7-Zip on a build agent if you truly need 7Z.
Reproducible builds broken by timestamps
Not preservedThe TAR header stamps the current time per entry, so identical inputs produce non-identical archives and content-addressed caches miss. Normalise with timestamp-normalizer before converting and re-normalise mtimes after extraction in CI.
Empty directories dropped from the artifact
Not preservedZIP directory entries are removed on extraction. If a build or runtime expects an empty dist/ or cache/ directory inside the archive, it will be missing — create it in your build step instead of relying on the archive.
Executable bit lost on scripts
Defaults appliedEntries are written with default 0644 permissions, so chmod +x scripts lose the execute bit after the round trip. Re-apply chmod +x post-extract or set permissions in your build.
Encrypted artifact ZIP
FailsPassword-protected ZIPs cannot be converted — there is no password field. Decrypt and extract with multi-format-extractor, re-zip the plaintext, then convert.
Artifact over the tier cap
Rejected (limit)Large build artifacts can exceed 50 MB (Free) or 500 MB (Pro). Limits are 50 MB / 500 MB / 2 GB / 2 GB by tier, with entry caps of 500 / 50,000 / 500,000. Split with archive-splitter or upgrade.
Output slightly larger than the source ZIP
Expected sometimesIf the artifact contained already-compressed assets (minified bundles can be incompressible, embedded media certainly is), level-6 GZIP cannot shrink them and adds tiny overhead. That is normal for incompressible content.
Frequently asked questions
Is there an API I can POST to for this conversion?
No. Archive tools are browser-only and apiAvailable is false — there is no REST tool endpoint. For automation use the @jadapps/runner (Pro+), which runs the same browser code in a local headless Chromium session, or reproduce the conversion with unzip then tar czf in your own script.
Does it actually output 7Z?
No. It outputs .tar.gz (TAR + GZIP level 6). Browser-side LZMA2 writing needs a heavy WASM encoder the tool doesn't ship, so it re-packages as TAR.GZ. The output opens in 7-Zip, but it is not a native .7z and won't pass a 7Z magic-byte check.
Can I automate it in CI?
Yes, two ways: (1) the @jadapps/runner on Pro+ executes the tool headlessly and locally; (2) reproduce it with unzip + tar czf if you'd rather not depend on the runner. There is no HTTP endpoint to call directly.
Will the re-packed artifact's contents match the source?
Yes — byte-lossless. Run checksum-generator on the source ZIP and the converted TAR.GZ; per-file hashes match. It's safe to substitute the TAR.GZ for the ZIP content-wise.
How do I make the output reproducible?
Normalise timestamps before converting with timestamp-normalizer, because the TAR header writes the current time per entry. In CI, also normalise mtimes after extraction so content-addressed caches and reproducible-build hashes stay stable.
Can I set the compression level for smaller artifacts?
No — the level is fixed at GZIP 6 with no options. For a smaller artifact you'd need LZMA2 (a native 7z) which this tool can't produce, or experiment with compression-level-optimizer to see level-by-level sizes on a ZIP.
Are file permissions preserved?
No. Entries are written with default 0644 permissions, so executable scripts lose their +x bit. Re-apply chmod +x after extraction in your build or deploy step.
Are empty directories kept?
No. ZIP directory entries are dropped during extraction. If your artifact relies on an empty directory existing, create it in your build rather than expecting it inside the archive.
Does my pre-release code get uploaded?
No. The conversion runs entirely in the browser (or in the local headless browser via the runner). Source ZIPs — including NDA'd vendor artifacts or internal builds — never leave the machine.
Can it process a batch of artifacts at once?
Not in a single run — this tool takes one archive at a time and is not a multi-file tool. For repeated conversions, script the runner or the CLI equivalent. For batch extraction (the reverse direction) see batch-extraction-manager.
What if the output is bigger than the input?
That happens when the artifact already held compressed assets (media, pre-minified bundles). DEFLATE can't shrink incompressible bytes and adds a little container overhead. It's expected — the value is the format change, not size, in that case.
Is there a direct ZIP-to-TAR.GZ tool if the name confuses me?
Yes — zip-to-tar-gz does the same thing under a clearer name. For other targets use archive-format-converter, and to compare levels use compression-level-optimizer.
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.