How to gzip → zip: browser tool vs the gzip / zip command line
- Step 1Map the CLI equivalent — The shell version of this tool is:
gzip -dk access.log.gz(decompress, keep original) thenzip access.zip access.log. The browser tool collapses both steps into one Process click and recovers the inner name for you. - Step 2Compare on filename fidelity — The CLI uses the on-disk filename after decompression; if you renamed the
.gzin transit, you lose the original name unless you passgzip -N(restore name from header). JAD's tool reads the FNAME header by default and only falls back to stripping.gzwhen the header is absent. - Step 3Compare on privacy and setup — Both run locally — neither sends your file anywhere. The difference is friction: the browser tool needs no install, sudo, or PATH edits, which is the deciding factor on managed corporate laptops or a colleague's machine.
- Step 4Compare on scale — For one or a handful of files under the tier cap, the browser tool is faster end-to-end (no terminal, no flags to remember). For thousands of files, multi-GB streams, or anything inside a build, the CLI's loopability wins.
- Step 5Compare on output reproducibility — JAD's tool writes the entry's timestamp from the decompressed data; the CLI uses the file's mtime. If you need bit-identical archives across machines, run the output through timestamp-normalizer — the same trick
zip -Xplus a fixed mtime gives you on the CLI. - Step 6Pick per context — Quick one-off, no-install, name-preserving conversion → browser tool. Scripted, high-volume, multi-GB, or CI-embedded → CLI. They produce equivalent ZIPs, so you can mix and match.
Browser GZIP → ZIP vs the CLI pipeline
Comparing JAD's tool against gzip -dk file.gz && zip out.zip file. Behaviour reflects the actual implementation.
| Dimension | JAD GZIP → ZIP (browser) | gzip -d | zip (CLI) |
|---|---|---|
| Install required | None — runs in any modern browser | Needs gzip + zip on the PATH |
| Inner filename | Auto-read from GZIP FNAME header; fallback strips .gz | On-disk name after decompress; use gzip -N to restore from header |
| Options | None — fixed DEFLATE level 6, one entry | Full control: -0..-9, paths, multiple files |
| Per-job size limit | 50 MB Free / 500 MB Pro / 2 GB Pro+Media | Bounded by disk only |
| Batch / scripting | One file per run, no scripting hook | Loop over globs trivially |
| .tar.gz handling | Wrong tool — produces a ZIP holding a lone .tar | tar xzf then zip -r handles it |
| Privacy | Local, nothing uploaded | Local, nothing uploaded |
When each path wins
Pick the tool that matches the job, not dogma — the outputs are interchangeable standard ZIPs.
| Scenario | Better choice | Why |
|---|---|---|
| One log file, locked-down laptop | Browser tool | No install, no PATH edits, name auto-recovered |
| Thousands of .gz in a folder | CLI | for f in *.gz; do ...; done loops; tool is one-file |
| File over 2 GB | CLI | Browser caps at 2 GB; CLI bounded by disk |
| Inside a CI build step | CLI | Tool has no automation hook for input data |
| Renamed .gz, original name lost | Browser tool | Reads FNAME header automatically |
| A .tar.gz archive | tar-gz-to-zip (or CLI) | This wrapper doesn't unpack the inner TAR |
Cookbook
The same conversion done both ways, with the behavioural differences highlighted.
The minimal CLI equivalent
What the browser tool does internally, expressed as a shell pipeline. The tool's advantage is collapsing this into one click and recovering the inner name.
# CLI (two steps) gzip -dk access.log.gz # → access.log (keeps .gz) zip access.zip access.log # → access.zip # Browser tool (one step) Drop access.log.gz → Process → access.zip (inner entry name read from FNAME header)
Filename recovery the CLI misses
When a .gz was renamed in transit, plain gzip -d names the output after the on-disk file. The browser tool reads the original name from the FNAME header; the CLI needs the explicit -N flag.
# A file renamed during download:
# real inner name: customers.csv
# on disk: download(3).gz
gzip -d download(3).gz → download(3) # name lost
gzip -Nd download(3).gz → customers.csv # -N restores it
Browser tool: reads FNAME → entry named customers.csv
(no flag needed)Where the CLI clearly wins — a batch
Converting a directory of rotated logs. The browser tool is one-file-per-run, so this is the CLI's territory.
# CLI handles the whole folder in one line:
for f in /var/log/*.gz; do
base=$(basename "$f" .gz)
gzip -dkc "$f" > "/tmp/$base"
(cd /tmp && zip "${base}.zip" "$base")
done
# Browser tool: would require dropping each file individually.The .tar.gz trap, both ways
A .tar.gz is not a single-file GZIP. The browser wrapper produces a ZIP containing a lone .tar; the CLI must untar first. This is the most common cross-tool mistake.
# Browser GZIP → ZIP on project.tar.gz: → project.zip containing project.tar (NOT the files) # Correct CLI: tar xzf project.tar.gz zip -r project.zip project/ # Correct browser tool: /archive-tools/tar-gz-to-zip → files unpacked into the ZIP
Reproducible output to match a CI artifact
Both paths embed a timestamp by default. To get a byte-stable ZIP across machines, normalise the timestamps after conversion.
# CLI deterministic zip: touch -d '1980-01-01' access.log zip -X access.zip access.log # Browser tool: GZIP → ZIP, then run the output through /archive-tools/timestamp-normalizer (date 1980-01-01) → bit-identical archive across rebuilds
Edge cases and what actually happens
Single-file .gz, both paths agree
SupportedFor a genuine single-stream .gz, the browser tool and gzip -d | zip produce equivalent ZIPs — same DEFLATE data, one entry. The only differences are the inner-name handling and the embedded timestamp.
Renamed .gz with intact FNAME header
Browser tool advantageThe browser tool reads the original name from the FNAME header automatically; plain gzip -d names the output after the on-disk file and needs the -N flag to match. If name fidelity matters and you can't remember -N, the browser path is safer.
A .tar.gz fed to either
By design (wrong tool)Neither gzip -d | zip nor this wrapper unpacks a TAR. The wrapper zips the lone .tar blob; the CLI needs tar xzf first. For TAR.GZ, use tar-gz-to-zip, which parses the TAR into individual ZIP entries.
File larger than the browser tier cap
Rejected (tier limit)The browser tool blocks inputs over 50 MB (Free) / 500 MB (Pro) / 2 GB (Pro+Media) before processing. The CLI has no such cap — it's bounded by disk. For multi-GB .gz streams, the CLI is the practical choice.
Corrupt or truncated .gz
ErrorBoth paths fail on a truncated GZIP — fflate throws on the magic/trailer check, and gzip -d reports "unexpected end of file". Neither recovers a partial stream. Re-download the source.
Already-compressed payload
ExpectedWhether you re-zip via browser or CLI, a payload near its entropy floor won't shrink — both use DEFLATE. The ZIP can end up marginally larger than the .gz due to container overhead. That is normal.
No terminal access / managed device
Browser tool advantageOn a corporate laptop where you can't install or PATH-add zip, the browser tool needs nothing beyond a tab. This is the single strongest reason to prefer it over the CLI.
Embedding the conversion in a pipeline
CLI advantageThe browser tool has no automation hook that accepts input files programmatically for this conversion. If the step lives inside a build or scheduled job, the CLI is the right tool.
Frequently asked questions
What is the exact CLI equivalent of this tool?
gzip -dk file.gz && zip out.zip file — decompress keeping the original, then zip the result. The browser tool collapses both steps and additionally recovers the inner filename from the GZIP FNAME header automatically.
Are the browser and CLI outputs interchangeable?
Yes. Both produce a standard DEFLATE ZIP with the same content. There is no JAD-specific wrapper, so a ZIP made here opens identically to one made with zip, and vice versa.
Does the browser tool send my file to a server like some online converters?
No. It runs fflate in WebAssembly inside your tab — nothing is uploaded. In that sense it is exactly as private as the local CLI; the only difference is that it requires no installation.
When is the CLI clearly better?
Batches of many files, streams larger than the 2 GB browser cap, anything scripted, and steps embedded in CI. The browser tool is one-file-per-run with no automation hook for input data.
When is the browser tool clearly better?
A one-off conversion on a machine where you can't install zip, or when you need the original inner filename recovered without remembering gzip -N. Setup friction and name fidelity are where it shines.
Why doesn't the browser tool offer a compression-level option like the CLI's -0..-9?
By design — this tool has an empty options schema and uses DEFLATE level 6, the universal sweet spot. If you want to compare levels, compression-level-optimizer benchmarks levels 1/3/6/9 over your files.
Can the browser tool handle a .tar.gz like `tar xzf`?
No — this wrapper treats the GZIP as one stream, so a .tar.gz becomes a ZIP holding a single .tar. Use tar-gz-to-zip, which is the browser equivalent of tar xzf followed by zip -r.
How do I make the browser output reproducible like `zip -X` with a fixed mtime?
Run the result through timestamp-normalizer with a fixed date such as 1980-01-01. That gives a byte-stable archive across machines, matching the deterministic-zip CLI trick.
Does the browser tool match the CLI on speed?
For files under ~100 MB, fflate is fast and end-to-end the browser tool is competitive (no terminal overhead). For multi-GB files or large batches, the CLI pulls ahead because it isn't bound by the browser tier caps or single-file flow.
Is filename recovery reliable?
It depends on the source GZIP. If the file was compressed with the FNAME field (the default for many tools), the original name is recovered exactly. If it was made with gzip -n, there is no name to read and the tool strips the .gz suffix instead — the same situation the CLI faces.
Which other JAD tools cover the cases this one doesn't?
For TAR.GZ use tar-gz-to-zip; for any-direction format swaps use archive-format-converter; to go the other way (ZIP → TAR.GZ) use zip-to-tar-gz; to confirm a mystery file's true format use auto-format-detector.
Does the browser tool produce one entry like a single `zip file`, or recompress like `zip -r`?
It produces exactly one entry — a single-file GZIP holds one payload. That matches zip out.zip file (one file in), not zip -r out.zip dir/ (a tree). The data is re-DEFLATEd at level 6, equivalent to the CLI's default level 6.
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.