How to gzip → zip for linux & container engineers
- Step 1Confirm it's a single-stream .gz, not a tarball — Run
file app.log.gz— if it says "gzip compressed data" with one inner name it's fine. If it's a.tar.gz/.tgz(release tarball,docker saveoutput, layer export), use tar-gz-to-zip instead so the inner files unpack. - Step 2Pull the log or dump to your workstation — Get the
.gzonto the machine running the browser —scp,kubectl cp, an artifact download, or adocker logs ... | gzipredirect. The tool reads from local disk via the File API; nothing transits a network during conversion. - Step 3Open the tool and drop the file — Go to /archive-tools/gzip-to-zip and drop the
.gz. It's a single-file dropzone. On Free the cap is 50 MB; for a large container log, Pro raises it to 500 MB and Pro+Media to 2 GB. - Step 4Click Process — fflate decompresses the stream, reads the FNAME header for the inner name, and re-zips one entry at level 6. The metrics show Source GZIP, Target ZIP, and the recovered Inner filename.
- Step 5Download and hand off — Download the ZIP and attach it to the ticket, share it with the Windows reviewer, or feed it to the upload form. It opens natively everywhere — no
.gzhandler required on the recipient's side. - Step 6Attach a checksum if it's evidence — For incident or audit handoffs, run checksum-generator on the ZIP to emit a SHA-256 manifest, establishing integrity from the moment you convert.
Common Linux/container .gz sources and how they convert
Which everyday GZIP outputs are a fit for this single-file wrapper — and which need the TAR.GZ tool instead.
| Source | File shape | Right tool |
|---|---|---|
pg_dump | gzip > db.sql.gz | Single-file GZIP | This tool → ZIP with db.sql |
docker logs app 2>&1 | gzip | Single-file GZIP | This tool → ZIP with the log |
journalctl -u svc | gzip | Single-file GZIP | This tool |
logrotate access.log.1.gz | Single-file GZIP (FNAME present) | This tool — name auto-recovered |
docker save img | gzip / release tarball | TAR inside GZIP (.tar.gz) | tar-gz-to-zip |
A .bz2 / .xz log | Not GZIP | multi-format-extractor |
Tier limits for large container logs
The cap applies to the compressed .gz you upload. Big debug logs compress well, so even a multi-GB raw log often fits as a .gz.
| Tier | Max .gz size | Entries per archive | Batch files |
|---|---|---|---|
| Free | 50 MB | 500 | 1 |
| Pro | 500 MB | 50,000 | 20 |
| Pro + Media | 2 GB | 500,000 | 100 |
| Developer | 2 GB | 500,000 | unlimited |
Cookbook
Real container and Linux GZIP outputs converted for cross-platform handoff. Hostnames and IDs anonymised.
Rotated nginx log for a Windows reviewer
logrotate writes the FNAME field, so the original name survives. The reviewer gets a ZIP they can double-click in Explorer with no extra software.
Input: access.log.1.gz (logrotate output, 6 MB) GZIP FNAME header: "access.log.1" Result metrics: Source: GZIP Target: ZIP Inner: access.log.1 Entries: 1 Output: access.log.1.zip → opens in Windows Explorer
Postgres dump from pg_dump | gzip
A nightly DB dump piped through gzip. Whether or not the FNAME field is set, you get a clean .sql inside the ZIP for attaching to a migration ticket.
Input: nightly.sql.gz (gzip -c, 40 MB compressed) FNAME present → inner name: nightly.sql (or fallback strips .gz → nightly.sql) Output: nightly.sql.zip └─ nightly.sql
kubectl previous-pod log capture
Capturing a crashed pod's previous logs and compressing them for an incident bridge. The browser tool wraps it for teammates on any OS without uploading the log.
$ kubectl logs app-7d9 --previous | gzip > crash.log.gz Browser tool: drop crash.log.gz → Process → crash.log.zip (one entry: crash.log) Nothing uploaded — pod logs with internal IPs stay local.
The release-tarball mistake to avoid
A .tar.gz is the default shape for release artifacts and docker save exports. Dropped here, it wraps the inner TAR whole — not what you want for a reviewer who expects individual files.
Input: release-1.4.0.tar.gz Gunzips to: release-1.4.0.tar (one blob) Output here: release-1.4.0.zip └─ release-1.4.0.tar ← inner files NOT unpacked Fix: /archive-tools/tar-gz-to-zip → files extracted into the ZIP
Evidence handoff with a checksum
For an incident where the log is evidence, convert then hash so the ZIP's integrity is provable from the moment of conversion.
1. GZIP → ZIP: audit.log.gz → audit.zip
2. /archive-tools/checksum-generator on audit.zip
→ audit.sha256sums:
9f2c...e1 audit.log
3. Attach both to the ticket; recipient runs
sha256sum -c audit.sha256sums to verify.Edge cases and what actually happens
Single-file container log .gz
SupportedThe intended path. A log captured via docker logs, journalctl, or kubectl logs and piped through gzip is a single GZIP stream — it wraps cleanly into a one-entry ZIP with the inner name recovered.
Release tarball or `docker save | gzip`
By design (wrong tool)These are .tar.gz — a TAR inside a GZIP. This wrapper zips the lone .tar blob rather than the inner files. Use tar-gz-to-zip to unpack the TAR into individual ZIP entries.
A .bz2 or .xz compressed log
Invalid inputMany Linux pipelines use bzip2 or xz instead of gzip. Those are not GZIP — fflate's gunzip will reject them. Send .bz2/.xz to multi-format-extractor, which routes them through the libarchive WASM bridge.
Large debug log over the tier cap
Rejected (tier limit)Verbose container logs can be big. The cap applies to the compressed .gz: 50 MB Free, 500 MB Pro, 2 GB Pro+Media/Developer. Logs compress well, so a multi-GB raw log often fits as a .gz; if not, upgrade or split the log before compressing.
gzip -n output (no FNAME)
PreservedSome pipelines use gzip -n to strip the name (for reproducibility). With no FNAME header, the tool strips the .gz suffix from your filename instead — svc.log.gz becomes svc.log. No failure; just the fallback name.
Sensitive data in the log
By design (local-only)Because conversion runs entirely client-side, IPs, hostnames, and tokens in the log never traverse a network. This is the key reason the tool suits regulated or security-sensitive container ops — it is equivalent to running a local CLI.
Truncated `kubectl cp` / partial download
ErrorAn interrupted transfer yields a truncated GZIP that fails the magic/trailer check and errors out. Re-fetch the file; there is no partial-recovery path for GZIP here.
Many per-pod logs to convert
First file onlyThis tool converts one .gz per run. To bundle many local log files into a single archive instead, folder-to-zip or smart-archive-compressor accept multiple files at once.
Frequently asked questions
Is this suitable for logs that might contain sensitive data?
Yes. The .gz is decompressed and re-zipped entirely in your browser via fflate WebAssembly — nothing is uploaded. For chain-of-custody, pair it with checksum-generator to produce a SHA-256 manifest of the resulting ZIP.
My teammate is on Windows and can't open .gz — does this fix that?
Exactly the use case. The output is a standard ZIP that Windows Explorer opens natively with a double-click. No .gz handler, 7-Zip, or WSL needed on the recipient's side.
Can I convert a Docker image export or release tarball with this?
No — those are .tar.gz. This wrapper would produce a ZIP containing a single .tar. Use tar-gz-to-zip, which parses the TAR so the inner files land as individual ZIP entries.
What about .bz2 or .xz logs?
This tool only handles GZIP. For bzip2 or xz streams, use multi-format-extractor, which uses the libarchive WASM bridge to read BZ2/XZ/7Z/RAR/TAR that fflate can't.
How big a container log can I convert?
The cap is on the compressed .gz: 50 MB Free, 500 MB Pro, 2 GB Pro+Media/Developer. Text logs compress heavily, so a raw log of several GB frequently fits as a .gz under these caps.
Will the inner filename match what `gzip` recorded?
If the GZIP was written with the FNAME field (the common default), yes — the inner ZIP entry takes that exact name. If it was made with gzip -n, the tool strips the .gz suffix from the upload name instead.
Does this work on a locked-down jump box without admin rights?
Yes — it needs only a browser tab. No install, sudo, or PATH changes. That's a deliberate advantage over needing gzip/zip/unzip present on a restricted host.
Can multiple engineers use it at once?
Each browser tab is an independent client-side instance — there's no shared server state to contend over. Free-tier limits apply per session; paid tiers raise them.
Does it run through the runner on paid tiers?
On Pro and above, archive tools can auto-route through the local @jadapps/runner (a short-lived headless browser on your own machine). Either way the data stays local — there is no server-side path for archive processing.
How do I make the ZIP reproducible for a pipeline artifact?
Run the output through timestamp-normalizer with a fixed date such as 1980-01-01. Two conversions of the same .gz then yield byte-identical ZIPs.
What if the file is actually corrupt?
A truncated or damaged GZIP fails the magic/trailer validation and errors out. If you suspect a renamed-but-wrong file, run auto-format-detector to read the magic bytes and confirm the real format.
Is there an API I can call from a script?
Archive tools run browser-side with no server endpoint for input data, so there's no HTTP API for this conversion. For scripted, high-volume conversion, the gzip -dk file.gz && zip out.zip file CLI pipeline is the better fit; the browser tool targets ad-hoc, no-install handoffs.
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.