How to tar.gz → zip vs command-line tar / gzip pipelines
- Step 1Decide on privacy footing — Both are private. The browser tool never uploads (verify in DevTools → Network); the CLI never leaves your box either. Privacy is a tie — pick on other axes.
- Step 2Weigh fidelity needs — Need executable bits, symlinks, or hardlinks intact? Use the CLI. Need only file content moved into a Windows/Finder-friendly ZIP? The browser tool is enough.
- Step 3Check the size — Under your tier cap (50 MB free / 500 MB pro / 2 GB pro-media and developer) the browser tool is fine. Past 2 GB, or for streaming pipelines, go CLI.
- Step 4Run the browser path — Open /archive-tools/tar-gz-to-zip, drop the
.tar.gz, click Process, download the ZIP. No flags, no options. - Step 5Run the CLI path —
mkdir out && tar -xzf in.tar.gz -C out && (cd out && zip -r ../out.zip .). Add-Xto strip extra attributes for a cleaner ZIP. - Step 6Verify the output — Both produce standard ZIPs. Confirm contents with /archive-tools/archive-previewer or
unzip -l out.zip— entry trees should match for regular files.
Browser converter vs CLI pipeline
JAD TAR.GZ → ZIP (fflate, in-browser) versus tar | zip on the command line.
| Dimension | JAD TAR.GZ → ZIP | CLI tar + zip |
|---|---|---|
| Install needed | None — just a browser | tar, gzip, zip (or 7z) installed |
| Upload | None — runs in the tab | None — runs locally |
| Unix mode bits | Dropped | Preserved (ZIP extra field) |
| Symlinks / hardlinks | Skipped | Stored per zip(1) handling |
| Max size | 2 GB (paid tiers) | Disk/RAM bound only |
| Scriptable | Roadmap (Phase 15) / runner | Native to shell + CI |
Output equivalence
What you can rely on being identical between the two paths.
| Property | Same across both? | Notes |
|---|---|---|
| Regular file bytes | Yes | Content is lossless either way |
| File/folder tree | Yes for regular files | Paths carry directory prefixes |
| Entry timestamps | No | Re-zip uses current time; CLI keeps mtime |
| Compression algorithm | Both DEFLATE | fflate level 6 vs zip's default |
| Readability | Yes | Both open in unzip, 7-Zip, Finder |
Cookbook
The same conversion done both ways, plus the cases where the choice actually matters — permissions, symlinks, and oversized inputs.
One-off convert, both ways
A teammate sent report.tar.gz and you just need a ZIP. Either path works; the browser one needs nothing installed.
# CLI mkdir out && tar -xzf report.tar.gz -C out (cd out && zip -r ../report.zip .) # Browser Drop report.tar.gz at /archive-tools/tar-gz-to-zip -> Process -> Download report.zip
When executable bits matter
Shipping a CLI binary inside the archive? The browser converter drops mode bits; the CLI keeps them.
Input contains: bin/tool (mode 0755) Browser ZIP: bin/tool stored with no mode bits (not executable on extract) CLI ZIP: bin/tool keeps 0755 via the Unix extra field Use the CLI when the exec flag must survive.
An archive full of symlinks
node_modules-style trees and latest links are symlinks. The browser tool skips them; the CLI preserves what ZIP can.
release.tar.gz: lib/v2/... regular files lib/current -> v2 symlink Browser ZIP: lib/current is absent CLI ZIP: lib/current stored as a symlink entry
Output size sanity check
Because both use DEFLATE-class compression on the same payload, sizes land close. This is expected, not a bug.
in.tar.gz 18.4 MB browser zip 18.9 MB (fflate level 6) cli zip 18.7 MB (zip default) Delta is just header/encoder differences, not data loss.
Too big for the browser
A 3 GB tarball exceeds every JAD tier. The CLI has no such ceiling.
Browser (any tier): rejected — exceeds 2 GB per-job limit CLI: tar -xzf huge.tar.gz -C out && (cd out && zip -r ../huge.zip .) No size cap beyond your disk and RAM.
Edge cases and what actually happens
Permissions required in output
Use CLIThe browser converter does not forward Unix mode bits. If extracted files must keep their executable or read-only flags, use zip on the command line.
Symlinks must survive
Use CLITAR symlink entries are skipped by the browser tool. zip(1) can store symlinks (with -y), so the CLI is the right path when links matter.
Timestamps must match mtime
DiffersThe browser re-zip stamps entries with the current time, not the original mtime. The CLI preserves mtime. For reproducible builds, normalise after with /archive-tools/timestamp-normalizer.
Input above 2 GB
Use CLIEvery JAD tier caps the input at 2 GB or below. Multi-gigabyte tarballs must be handled by the CLI or split before conversion.
No tar installed (locked-down host)
Use browserOn corporate or kiosk machines where you cannot install or run tar, the browser converter needs nothing beyond the page itself.
Untrusted archive you don't want on disk
Use browserExtracting an unknown tarball with the CLI writes files to disk. The browser tool keeps everything in tab memory and hands back one ZIP, leaving no extracted tree behind.
Scripted, repeatable conversion
Use CLIFor pipelines and CI, the CLI is scriptable today; JAD's programmatic API is on the Phase 15 roadmap, with a headless runner available on paid tiers.
GNU longname / PAX paths
CLI saferThe browser parser reads the 100-byte name field only and does not interpret GNU longname or PAX extension records, so very long paths can truncate. GNU tar handles them natively.
Frequently asked questions
Is the browser tool less private than the CLI?
No — both are fully local. JAD's converter runs in your browser tab with fflate and uploads nothing; the CLI runs on your machine. Privacy is equivalent.
Will the outputs be interchangeable?
For regular-file content, yes — both produce standard DEFLATE ZIPs readable by unzip, 7-Zip, and Finder. They differ on permissions, symlinks, hardlinks, and timestamps.
Why does the CLI keep permissions but the browser tool doesn't?
JAD re-zips a clean file map with no Unix mode bits. zip(1) writes those bits into a ZIP extra field. If exec flags matter, use the CLI.
Which is faster?
For small to medium archives the browser tool is effectively instant — fflate is highly optimised C-to-WASM. For multi-gigabyte tarballs the CLI streams better and isn't bound by browser memory.
Can the browser tool handle 5 GB tarballs?
No. The maximum input is 2 GB (Pro+Media / Developer). Larger archives must use the CLI or be split upstream before conversion.
Does the browser converter store symlinks like zip -y?
No — symlink entries are skipped entirely. There is no flag to change this. Use the CLI with zip -y if symlinks must be preserved.
Do I need the same compression level as the CLI?
JAD always uses DEFLATE level 6, the universal sweet spot. zip(1) defaults near there too, so output sizes land within a few percent of each other.
When is the browser tool clearly the better choice?
One-off jobs, machines without tar, untrusted input you don't want extracted to disk, and quick demos where install time matters more than fidelity.
When is the CLI clearly better?
Reproducible builds, executable bits, symlinks/hardlinks, archives over 2 GB, and any scripted or CI workflow.
Can I script the JAD converter?
A programmatic API is planned (Phase 15). Paid tiers can run archive jobs through a local headless-browser runner today. For full scripting now, the CLI is the answer.
Does converting recompress the data?
Yes — both paths decompress the GZIP/TAR payload and re-encode it as DEFLATE in the ZIP. The file content is unchanged, but it is genuinely re-compressed, not just re-wrapped.
What about going ZIP back to TAR.GZ?
Use /archive-tools/zip-to-tar-gz for the reverse, or /archive-tools/archive-format-converter to pick a target from a dropdown. Same in-browser, no-upload model.
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.