How to zip → tar.gz vs command-line tar / gzip pipelines
- Step 1Decide if permissions/symlinks matter — If the TAR will be extracted on Linux and a file needs to stay executable, or you have symlinks to preserve, use the CLI:
unzip -q in.zip -d out && tar -czf out.tar.gz -C out .. The browser tool flattens everything to mode 0644 and dereferences symlinks to plain files. - Step 2Decide on size — The browser tool is in-memory and capped (50 MB free, 500 MB Pro, 2 GB higher). For multi-gigabyte archives, the streaming CLI is the only practical option. For a few MB to a few hundred MB, the browser is instant and avoids the shell.
- Step 3Decide on privacy — If the archive contains anything you'd rather not upload, the browser tool is strictly local — nothing leaves the device. Avoid generic online converters that upload; the CLI is also local but needs the tooling installed.
- Step 4For the browser path, just drop and process — There are no flags or options to set — open the tool, drop the ZIP, press Process, download
name.tar.gz. GZIP level is fixed at 6. - Step 5For the CLI path, choose your flags deliberately —
tar czfdefaults to GZIP level 6 (same as the browser). Add--mtime/--owner=0 --group=0 --numeric-ownerfor reproducible output; the browser tool can't do that and stamps the current time on every entry. - Step 6Verify either output the same way — Both paths produce standard
.tar.gz. List withtar -tzf out.tar.gz. Diff two outputs' file lists if you're migrating a process from CLI to browser to confirm the entry set matches (it will differ on empty folders and mtimes).
Browser ZIP → TAR.GZ vs CLI pipelines, feature by feature
What each path actually does. The browser column reflects the real implementation, not aspirations.
| Capability | JAD browser tool | unzip | tar czf (CLI) | 7-Zip GUI |
|---|---|---|---|
| Install required | None (runs in tab) | unzip + tar + shell | 7-Zip app |
| Uploads your files | Never (0 bytes uploaded) | No (local) | No (local) |
| GZIP level | Fixed 6 | Default 6, -I 'gzip -9' to change | Selectable |
| Unix permissions | Dropped → 0644 | Preserved | Partially |
| Symlinks | Flattened to file | Preserved (-h to follow) | Varies |
| Timestamps | Current time on all | Preserved | Preserved |
| Reads 7z / RAR / XZ | Yes (WASM) | No (tar can't) | Yes |
| Max practical size | ≤ 2 GB, in-memory | Disk-bound (huge) | Disk-bound |
| Scriptable / CI | Via runner on paid tiers | Native | CLI build only |
Which path for which job
A quick decision matrix.
| Your situation | Best path | Why |
|---|---|---|
| One-off convert on a work laptop, no admin | Browser tool | Zero install, nothing to upload |
| TAR must keep +x bits / symlinks for deploy | CLI | Browser drops mode to 0644, flattens symlinks |
| Reproducible build (byte-identical output) | CLI with --mtime --owner=0 | Browser stamps current time, can't pin it |
Source is a .7z and no 7-Zip installed | Browser tool | WASM reader opens 7z; tar can't |
| 5 GB archive in a CI runner | CLI | Streaming, no browser memory cap |
| Sensitive archive, must not upload | Browser tool | Strictly local; avoids upload-converters |
Cookbook
The same conversion done both ways, with the differences called out so you can predict what each produces.
The CLI equivalent of the browser tool
What the browser tool does, expressed as a shell pipeline — minus the permission preservation it can't replicate.
# Browser: drop in.zip, press Process → in.tar.gz # CLI equivalent (closest match): unzip -q in.zip -d /tmp/x tar -czf in.tar.gz -C /tmp/x . # Difference: tar keeps mode/mtime from the unzipped files; # the browser sets every entry to 0644 + current time.
Where permissions diverge
A ZIP containing an executable script. The CLI keeps +x; the browser doesn't.
Input zip: deploy/run.sh (was chmod 755 before zipping) CLI: tar -tzvf out.tar.gz → -rwxr-xr-x deploy/run.sh Browser: tar -tzvf out.tar.gz → -rw-r--r-- deploy/run.sh Fix after browser conversion: tar -xzf out.tar.gz && chmod +x deploy/run.sh
Reproducible output: only the CLI can pin it
Two runs of the browser tool on the same ZIP produce different bytes because the mtime is the current time. The CLI can force a fixed time.
Browser run #1 and #2 of same in.zip:
sha256 differs (mtime = Date.now() each run)
CLI, pinned:
tar --sort=name --mtime='1970-01-01' \
--owner=0 --group=0 --numeric-owner \
-czf out.tar.gz -C /tmp/x .
→ byte-identical across runsBrowser wins: converting a 7z with no 7-Zip on the box
tar cannot read 7z. The browser's WASM reader can, so the browser path succeeds where a pure-tar pipeline fails.
# CLI on a machine without p7zip: $ 7z x assets.7z bash: 7z: command not found # Browser: drop assets.7z → assets.tar.gz (libarchive WASM reads 7z, output is TAR.GZ)
Empty folders: CLI keeps them, browser drops them
A subtle difference when migrating a process. The TAR builder only writes file entries.
ZIP contains: src/main.c, build/ (empty)
CLI: tar -tzf out.tar.gz → ./ src/ src/main.c build/
Browser: tar -tzf out.tar.gz → src/main.c
(build/ and bare dir entries are not written)Edge cases and what actually happens
You expected preserved +x bits
Not preservedThe browser TAR builder writes mode 0644 for every entry. If your pipeline relied on tar czf keeping executable bits, the browser output will not — extract and chmod on the far end, or stay on the CLI for that job.
Reproducible-build byte equality
Browser can't pinEach browser conversion stamps Date.now() as the mtime, so outputs differ run-to-run. Reproducibility requires the CLI with --mtime, --owner=0 --group=0 --numeric-owner and --sort=name. The browser tool has no flags to set any of these.
Symlinks in the source archive
FlattenedThe in-browser reader resolves symlinks to their target bytes, so the TAR contains regular files, not links. tar (without -h) would preserve them as symlinks. This matters for archives that deliberately ship links.
Archive larger than ~2 GB
Browser blockedEven the top tier caps at 2 GB per file, and conversion is in-memory. The CLI streams from disk and handles far larger archives. For big artifacts the CLI is the only realistic path.
GZIP level you can't change
Fixed at 6The browser tool hard-codes GZIP level 6. If you need maximum compression (gzip -9) or fastest (-1), use the CLI's -I 'gzip -9', or for ZIP output the smart archive compressor exposes a 0–9 slider.
Encrypted ZIP input
Browser rejectsThe CLI can decrypt with unzip -P pass; the browser tool has no password field and stops with an encrypted-entries error. For encrypted sources, decrypt on the CLI first or extract with a password-capable sibling tool, then convert.
Privacy on a generic online converter
Risk avoidedMany web converters upload your archive to their server. JAD's tool does not — it's fflate in your tab. If privacy is the reason you avoided web tools, this one is safe; the comparison isn't browser-vs-CLI on privacy, it's this-tool-vs-uploader-tools.
Migrating a CI step from CLI to browser
Mostly compatibleUse the runner on a paid tier to call the tool locally in automation. But verify: file lists differ on empty folders, and metadata (mode/mtime) won't match the CLI output. If your downstream only reads file contents, you're fine; if it checks permissions, stay on the CLI.
Windows users who can't run tar
Browser winsModern Windows ships tar.exe, but locked-down corporate images often block it. The browser tool needs nothing installed and works in any browser, making it the path of least resistance on Windows.
Output two-layer unwrap on Windows
ExpectedBoth the browser and CLI produce a TAR-inside-GZIP. Windows tools may show two layers; tar -xzf or 7-Zip handle both at once. This is identical between the two paths — not a browser-specific quirk.
Frequently asked questions
Is the browser output identical to tar czf?
Functionally — both are standard ustar TAR in GZIP at level 6 — but not byte-identical. The browser sets every entry to mode 0644 and stamps the current time as mtime, while tar czf preserves the source files' mode and timestamps. File contents are the same; metadata and byte hashes differ.
Why would I not just use the command line?
Three reasons: no install (the CLI needs unzip + tar, often missing on locked-down machines), no upload exposure (vs generic online converters), and broader input reach (the browser reads 7z/RAR/XZ, which plain tar cannot). For huge files or permission-sensitive output, the CLI is still better.
Does the browser tool preserve file permissions like tar does?
No. It writes mode 0644 for every entry because ZIP doesn't expose Unix mode bits cleanly. If you need executable bits or specific permissions in the TAR, use unzip | tar czf on the CLI, or chmod after extracting the browser output.
Can I get reproducible (byte-identical) output from the browser tool?
No — it stamps the current time on every TAR entry, so two runs differ. Reproducible builds need the CLI with --mtime, --owner=0 --group=0 --numeric-owner, and --sort=name. The browser tool has no flags to control any of that.
What's the largest archive the browser can handle vs the CLI?
The browser caps at 50 MB (free) / 500 MB (Pro) / 2 GB (top tiers) and works in memory, so very large or highly-expanding archives can crash the tab. The CLI streams from disk and handles archives far larger than RAM. Above a couple of GB, use the CLI.
Can the browser tool read formats tar can't?
Yes. A libarchive WASM bridge reads 7z, RAR, BZ2, XZ and ISO inputs and converts them to TAR.GZ. Plain tar reads none of those without external tools. If you just need generic format conversion, the archive format converter lets you target ZIP, TAR.GZ or GZIP.
Does either path handle encrypted ZIPs?
The CLI does (unzip -P password). The browser ZIP → TAR.GZ does not — it has no password field and rejects encrypted archives. Decrypt first, or extract with a password-capable sibling like the multi-format extractor.
Is 7-Zip a better choice than either?
7-Zip is a fine GUI on Windows and preserves more metadata than the browser tool, but it's an install and Windows-centric. The browser tool wins on zero-install and cross-platform; the CLI wins on scripting and scale. Pick by constraint, not by brand.
How do I verify the two outputs contain the same files?
Run tar -tzf on each and diff the listings. Expect differences on empty directories (browser drops them) and on metadata (mode/mtime). The set of file paths and their contents should otherwise match.
Can I script the browser tool like a CLI?
On paid tiers, yes — the @jadapps/runner exposes POST http://127.0.0.1:9789/v1/tools/zip-to-tar-gz so a script can drive it locally with no upload. It's not as flexible as tar flags (there are none), but it slots into a pipeline. See the developer workflow guide.
Which is faster for a 100 MB ZIP?
For a one-off, the browser is faster end-to-end because there's no shell context switch and no temp directory — drop, process, download. The CLI pulls ahead on very large files and when the conversion is already inside a script.
Does the browser tool work on macOS where ditto makes ZIPs?
Yes. macOS-created ZIPs (including ones with __MACOSX/ resource-fork folders) read fine. Those __MACOSX/ entries will carry through into the TAR as regular files — strip them first with the path prefix remover or a filename filter if you don't want them.
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.