How to tar.gz → zip in developer workflows
- Step 1Grab the artifact — Download the
.tar.gzfrom the PR, CI run, or registry. No checkout needed — you only need the file on disk. - Step 2Convert in-browser — Open /archive-tools/tar-gz-to-zip, drop the tarball, click Process. fflate gunzips, parses, and re-zips at DEFLATE level 6 with no options.
- Step 3Inspect or diff — Open the ZIP locally, or feed before/after archives to /archive-tools/archive-diff to see exactly which entries changed between two builds.
- Step 4Normalise timestamps for reproducibility — Run /archive-tools/timestamp-normalizer on the ZIP with a fixed date (1980-01-01 is the ZIP epoch) so two builds from the same content share a byte-identical archive.
- Step 5Emit a checksum manifest — Run /archive-tools/checksum-generator on the normalised ZIP to produce a SHA-256 manifest your pipeline can verify against future builds.
- Step 6Wire it into the flow — Drop the ZIP into the review thread, release page, or downstream step. There is no JAD-specific wrapper — it is a plain ZIP.
The fixed conversion pipeline
Exactly what runs — no flags, no presets, fully deterministic for a given input's content.
| Step | Call | Determinism note |
|---|---|---|
| Inflate GZIP | fflate gunzipSync | Pure function of input bytes |
| Parse TAR | parseTar (typeflag 0 only) | Same entries selected every run |
| Re-pack | fflate zipSync, level 6 | Same DEFLATE output for same data |
| Timestamps | current time | NOT deterministic — normalise after |
| Filename | stem + .zip | Derived from input name |
Reproducible-artifact recipe
Chain these JAD archive tools to get a bit-identical ZIP plus a verifiable manifest.
| Stage | Tool | Output |
|---|---|---|
| Convert | /archive-tools/tar-gz-to-zip | ZIP with current-time stamps |
| Normalise | /archive-tools/timestamp-normalizer | ZIP with fixed epoch stamps |
| Attest | /archive-tools/checksum-generator | SHA-256 manifest (.sha256sums) |
| Verify later | sha256sum -c | Pass/fail against future builds |
Scripting and batch options today
What is available now versus the roadmap, with per-tier batch capacity.
| Need | Available now | Notes |
|---|---|---|
| Single convert in UI | Yes (all tiers) | One archive per run |
| Headless-browser runner | Yes (Pro+) | Auto-routes jobs off the main tab |
| Many archives at once | via batch tools | Use batch-extraction-manager |
| Public API | Phase 15 (planned) | Not yet callable from CI |
Cookbook
Developer-shaped runs: reviewing a PR artifact, diffing two builds, producing a reproducible ZIP, and the CLI equivalent for when you do want to script it.
Peek at a PR artifact without checkout
A PR attaches dist.tar.gz. Convert and open the ZIP locally to eyeball the shipped files in seconds.
Download dist.tar.gz from the PR Drop at /archive-tools/tar-gz-to-zip -> Process -> dist.zip Open dist.zip in Finder/Explorer — no branch checkout, no rebuild.
Diff two release builds
Convert both, then run Archive Diff to see exactly which entries changed — like diff -r on extracted trees.
v1.tar.gz -> v1.zip v2.tar.gz -> v2.zip Feed v1.zip + v2.zip to /archive-tools/archive-diff Report: added / removed / changed entries between builds.
Reproducible ZIP from a tarball
Conversion stamps current time; normalising to the ZIP epoch makes two runs byte-identical for the same content.
tar-gz-to-zip: app.tar.gz -> app.zip (mtime = now) timestamp-normalizer: app.zip -> app-repro.zip (date 1980-01-01) checksum-generator: app-repro.zip -> app.sha256sums Same content => same SHA-256 across machines.
The CLI equivalent
When you do want it in a script today, this is the shell pipeline JAD's converter mirrors.
mkdir out && tar -xzf app.tar.gz -C out (cd out && zip -rX ../app.zip .) # -X drops extra attributes for a cleaner, more reproducible ZIP
Watch for the timestamp gotcha
Skipping the normalise step yields ZIPs that differ only by embedded timestamps — a common reproducibility trap.
Run A 10:01 -> app.zip (entry time 10:01) Run B 10:05 -> app.zip (entry time 10:05) SHA-256 differs even though content is identical! Fix: always pass through timestamp-normalizer for repro builds.
Edge cases and what actually happens
Output not byte-identical across runs
ExpectedThe re-zip stamps entries with the current time, so two runs produce different bytes. This is by design — chain /archive-tools/timestamp-normalizer to get a deterministic archive.
Executable bits lost in CI consumers
Not preservedZIP entries carry no Unix mode bits, so a downstream step expecting +x files will get plain ones. Re-set permissions after extraction or keep the tarball in that leg of the pipeline.
Symlinked node_modules trees
SkippedSymlink entries (common in pnpm/yarn caches) are dropped. The converted ZIP will be missing those links — verify completeness before treating it as a faithful copy.
Expecting a callable API
RoadmapThere is no public REST API yet (Phase 15). For automation today, use the Pro+ headless runner from the tool page, or the CLI equivalent in your scripts.
Batch of many tarballs
Single-inputThis tool converts one archive per run. For many archives use /archive-tools/batch-extraction-manager to unpack them together, then convert as needed.
Artifact over the tier cap
RejectedInputs above your tier ceiling (50 MB free / 500 MB pro / 2 GB pro-media and developer) are blocked before processing with a per-job limit error naming the file.
Corrupt CI artifact
ErrorA truncated or corrupt .tar.gz fails to gunzip and the run stops with an error. Re-download from the CI run and confirm the format with /archive-tools/auto-format-detector.
GNU longname paths in the tarball
May truncateThe parser reads the 100-byte TAR name field and does not interpret GNU longname/PAX records, so paths beyond that length can truncate. Most build tarballs stay under the limit.
Frequently asked questions
Is there a CLI or API equivalent?
A public API is planned for Phase 15. Today, paid tiers can run archive jobs through a local headless-browser runner, and the direct CLI equivalent is tar -xzf in.tar.gz && zip -rX out.zip <files> — JAD wraps that pipeline (fflate gunzip + DEFLATE re-zip) behind one page.
Is the output reproducible?
The file content is deterministic, but the re-zip stamps entries with the current time, so raw output differs run-to-run. Pass it through /archive-tools/timestamp-normalizer with a fixed date (1980-01-01) for a byte-identical archive.
Can I script bulk tar.gz → zip runs?
Not directly from this single-input tool. For volume, use /archive-tools/batch-extraction-manager (unpacks many archives) on Pro+ tiers, or script the CLI equivalent until the Phase 15 API ships.
Are there any options to tune?
No — the pipeline is fixed: gunzip, parse regular files, re-zip at DEFLATE level 6. That is intentional, so output is predictable. For different compression trade-offs, /archive-tools/compression-level-optimizer benchmarks levels on your files.
Does the output have any JAD-specific wrapper?
No — it is a plain DEFLATE ZIP readable by unzip, 7-Zip, and Finder. Drop it into any CI step or release page without special handling.
Will Unix permissions survive into my pipeline?
No. The re-zip writes no mode bits, so executable and read-only flags are lost. If a downstream step needs them, re-set after extraction or keep the tarball for that leg.
How do I diff two builds?
Convert both tarballs to ZIP, then feed them to /archive-tools/archive-diff. It reports added, removed, and changed entries — equivalent to diff -r on the extracted trees.
Does conversion recompress or just re-wrap?
It recompresses — entries are decompressed from GZIP/TAR and re-encoded as DEFLATE in the ZIP. Content is unchanged but genuinely re-encoded, so the compressed bytes differ from the source.
What if the artifact is a single .gz, not a tarball?
Use /archive-tools/gzip-to-zip for a single-file GZIP. This tool expects a TAR inside the GZIP; a one-file GZIP belongs in the wrapper tool.
Can I go ZIP → TAR.GZ for a Linux consumer?
Yes — /archive-tools/zip-to-tar-gz handles the reverse, and /archive-tools/archive-format-converter lets you pick the target from a dropdown.
How big can the input be?
Free: 50 MB. Pro: 500 MB. Pro+Media and Developer: 2 GB. The size check runs on the input before any decompression.
Is the conversion blocking the tab?
The fflate gunzip and re-zip are synchronous, so very large inputs can briefly hold the tab while processing. On paid tiers the headless runner offloads jobs to keep the page responsive.
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.