How to gzip → zip in developer workflows
- Step 1Grab the .gz from wherever it lives — A bug-report attachment, a CI artifact, a
gzip-compressed fixture in the repo. The tool reads from local disk via the File API — no checkout or rebuild needed to convert. - Step 2Sanity-check it's single-file GZIP — If it's a
.tar.gz/.tgz(multi-file), it'll wrap a lone.tarhere. Route those to tar-gz-to-zip. For a quick.gzvs.tar.gzcheck, auto-format-detector reads the magic bytes. - Step 3Drop and Process — Open /archive-tools/gzip-to-zip, drop the file, click Process. fflate decompresses, reads the FNAME header, and re-zips one entry. The metrics confirm the recovered Inner name and that Entries is 1.
- Step 4Make it reproducible if it's an artifact — Run the resulting ZIP through timestamp-normalizer with a fixed date (1980-01-01 is the reproducible-build standard). The entry timestamp becomes deterministic, so the SHA-256 is stable across rebuilds.
- Step 5Pin a checksum — Run checksum-generator on the normalised ZIP to emit a
.sha256sumsmanifest. Commit or attach it so reviewers and CI can verify the artifact later withsha256sum -c. - Step 6Verify before shipping — Run archive-integrity-tester on the ZIP to confirm the entry's stored CRC32 matches its data — a fast last check before attaching the artifact to a PR or release.
Developer-facing behaviour at a glance
The contract you can rely on when scripting around or documenting this conversion.
| Property | Guaranteed behaviour |
|---|---|
| Entry count | Always 1 — a single GZIP stream is one payload |
| Compression | Fixed DEFLATE level 6 (no level option exists) |
| Inner name | GZIP FNAME header, else input name minus .gz, else data |
| Output type | Standard ZIP 2.0, UTF-8 names, forward-slash paths |
| Timestamp | Derived from the data — normalise for reproducibility |
| Options surface | Empty schema — no password, level, or glob inputs |
Reproducible-artifact pipeline
Chaining three archive tools to turn a .gz into a byte-stable, verifiable ZIP. Each step is a separate tool page.
| Step | Tool | Effect |
|---|---|---|
| 1. Wrap | gzip-to-zip | .gz → one-entry ZIP |
| 2. Normalise | timestamp-normalizer | Fix entry timestamp to 1980-01-01 |
| 3. Hash | checksum-generator | Emit .sha256sums manifest |
| Verify | archive-integrity-tester | Confirm CRC32 of each entry |
Cookbook
Developer-shaped conversions: fixtures, captures, and reproducible artifacts. Names anonymised.
SQL fixture from a PR, wrapped for the tracker
A reviewer attached seed.sql.gz but your tracker only accepts .zip. One Process click gives a self-describing ZIP with seed.sql inside.
Input: seed.sql.gz FNAME → seed.sql Output: seed.sql.zip └─ seed.sql Metrics: Source GZIP · Target ZIP · Inner seed.sql · Entries 1
API capture for a bug repro
A flaky integration test dumped a gzipped response body. Wrapping it as a ZIP makes it a clean, double-clickable attachment for the issue.
Input: response-capture.json.gz (1.3 MB) FNAME → response-capture.json Output: response-capture.json.zip └─ response-capture.json
Reproducible artifact across two machines
Wrapping then normalising timestamps makes the ZIP byte-identical regardless of who ran it or when — so a checksum committed in CI keeps matching.
On machine A: app.log.gz → gzip-to-zip → app.zip → timestamp-normalizer (1980-01-01) → app.zip' sha256(app.zip') = 4b8f…c2 On machine B (same input): identical bytes → same 4b8f…c2 → commit the hash; CI verifies with sha256sum -c
Verifying the wrapped output
Before attaching the artifact, confirm the single entry's CRC32 is consistent — a quick integrity gate.
gzip-to-zip → fixture.zip
→ archive-integrity-tester on fixture.zip:
{
"totalEntries": 1,
"passed": 1,
"failed": 0
}
→ safe to attach.Catching the .tar.gz fixture mistake
A teammate committed testdata.tar.gz thinking it was single-file. Detect it before wrapping so you use the right tool.
auto-format-detector on testdata.tar.gz: format: "tar.gz" recommendedTools: ["tar-gz-to-zip", "multi-format-extractor"] → use /archive-tools/tar-gz-to-zip (gzip-to-zip would zip a lone testdata.tar)
Edge cases and what actually happens
Single-file fixture or capture .gz
SupportedThe standard developer path. A .sql.gz, .json.gz, or .log.gz is one GZIP stream and wraps cleanly into a one-entry ZIP with the inner name recovered from the FNAME header.
A .tar.gz fixture
By design (wrong tool)testdata.tar.gz gunzips to a single TAR, which this tool zips whole — so the ZIP holds a lone .tar, not the test files. Use tar-gz-to-zip so each file becomes its own entry.
Non-reproducible timestamp surprises CI
Expected (normalise to fix)The wrapped ZIP's entry timestamp derives from the data, so two raw conversions may not be byte-identical. That's expected — chain timestamp-normalizer with a fixed date to get a stable SHA-256 across machines and rebuilds.
Expecting a compression-level option
Not supportedThis tool's options schema is empty — no level slider. Compression is fixed at DEFLATE 6. If you need to compare levels for size/time, compression-level-optimizer benchmarks 1/3/6/9 over your input files.
File exceeds the tier cap
Rejected (tier limit)The compressed .gz must be under 50 MB (Free), 500 MB (Pro), or 2 GB (Pro+Media/Developer). The check runs before processing; oversized files error with a message naming your tier.
Renamed file that isn't GZIP
Invalid inputfflate validates the GZIP magic. A .gz-named ZIP or other format throws "invalid gzip data". Run auto-format-detector to read the real magic bytes and pick the right tool.
Truncated artifact download
ErrorA partially-downloaded .gz fails the trailer/length check and errors. Re-download; GZIP has no partial-recovery path in this tool.
Wanting to convert many fixtures at once
First file onlyThis is a single-file conversion. To bundle multiple local files into one archive instead, use folder-to-zip or smart-archive-compressor.
Frequently asked questions
Is there a CLI or API equivalent for automation?
Archive tools run browser-side with no server endpoint for input data, so there's no HTTP API for this conversion. The direct CLI equivalent is gzip -dk file.gz && zip out.zip file — that's the path to script in CI. The browser tool targets fast, no-install, in-flow conversions.
How do I make the output reproducible?
Wrap with this tool, then run the ZIP through timestamp-normalizer with a fixed date (1980-01-01 is the reproducible-build standard). The entry timestamp becomes deterministic, so the SHA-256 is identical across machines and rebuilds.
Why is the output sometimes the same size or larger than the input .gz?
GZIP and ZIP both use DEFLATE. Re-compressing data that's already near its entropy floor yields essentially the same size, and ZIP's per-entry headers add a small overhead. That's expected, not a regression.
Can I set the compression level?
No — the tool has no options and uses DEFLATE level 6. To explore the size/time trade-off across levels for your data, use compression-level-optimizer.
How many entries will the ZIP have?
Exactly one. A single-file GZIP carries one payload, so the wrapper always emits a one-entry ZIP. The metrics panel confirms Entries: 1.
What name does the entry get?
The GZIP FNAME header if present; otherwise the input filename with .gz stripped; and if that's empty, data. So fixture.sql.gz reliably becomes fixture.sql inside the ZIP.
Can I script bulk .gz → ZIP runs through JAD?
Not for this conversion — it's one file per run with no automation hook for input. For high-volume conversion use the shell gzip/zip pipeline. For bundling many local files into one archive, folder-to-zip accepts multiple files in a single run.
Will the output work with my CI's format expectations?
Yes — it's a standard DEFLATE ZIP with no JAD-specific wrapper. Drop it into any step that reads ZIP. For a deterministic artifact, normalise timestamps first.
How do I verify the wrapped artifact later?
Run archive-integrity-tester to confirm the entry's CRC32, or checksum-generator for a SHA-256 manifest you can pin and re-check with sha256sum -c.
Does it run locally on my machine on paid tiers?
Yes. On Pro+ the conversion can auto-route through the local @jadapps/runner (a short-lived headless browser on your own machine); on Free it runs directly in the tab. There is no server-side processing path for archive tools.
What if a teammate's `.tar.gz` lands in my workflow?
Detect it with auto-format-detector and convert it with tar-gz-to-zip. This wrapper would zip the lone inner .tar, which is rarely what you want.
Can I go the other direction (ZIP back to TAR.GZ)?
Yes — use zip-to-tar-gz for ZIP → TAR.GZ, or archive-format-converter to convert between ZIP, TAR.GZ, and GZIP in any direction.
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.