How to troubleshooting tar.gz → zip
- Step 1Check the size cap first — Free caps every input at 50 MB; Pro at 500 MB; Pro+Media and Developer at 2 GB. Over the cap, you get a per-job limit error before any processing — the fastest thing to rule out.
- Step 2Confirm the input is a TAR.GZ — Run /archive-tools/auto-format-detector. It reads the magic bytes and tells you the true format. A single-file
.gzbelongs in /archive-tools/gzip-to-zip; a renamed RAR/7Z won't convert here. - Step 3Check the entry count in the result — If files seem missing, look at the entry count metric. Symlinks, hardlinks, and standalone directory headers are intentionally dropped — only regular files are packed.
- Step 4Inspect a suspect input — Use /archive-tools/archive-previewer on the original TAR.GZ to see its full entry list, then compare against what landed in the ZIP.
- Step 5Rule out a corrupt download — A truncated
.tar.gzthrows a gunzip error. Re-download the file and re-run; if it still fails, the source is damaged. - Step 6Hard-refresh on a stale build — If the page behaves oddly after an update, hard-refresh (Ctrl+Shift+R) to load the latest chunk, then retry.
Failure → cause → fix
The five things that actually go wrong, with the real fix for each.
| Symptom | Likely cause | Fix |
|---|---|---|
| Per-job limit error | Input over tier size cap | Upgrade tier or split/convert via CLI |
| 'Could not detect format' | Renamed RAR/7Z or plain .gz | Use auto-format-detector / correct sibling tool |
| Files missing from ZIP | Symlinks/hardlinks/dirs skipped | Expected — only regular files cross over |
| gunzip / inflate error | Truncated or corrupt .tar.gz | Re-download; verify with format detector |
| Output size surprising | DEFLATE on already-dense data | Normal — see compression-ratio-calculator |
What gets dropped (so it's not a bug)
ZIP can't represent these TAR constructs, so the converter omits them.
| TAR entry | In ZIP? | Why it's missing |
|---|---|---|
| Regular file | Yes | Carried with identical content |
| Symlink (typeflag 2) | No | ZIP has no portable symlink type |
| Hardlink (typeflag 1) | No | ZIP has no hardlink concept |
| Directory header (typeflag 5) | No explicit entry | Folders implied by file paths |
| Unix mode / owner | Not forwarded | Re-zip writes plain entries |
Tier size caps (checked before processing)
The exact ceilings that trigger the per-job limit error.
| Tier | Max input | Files / job |
|---|---|---|
| Free | 50 MB | 1 |
| Pro | 500 MB | 20 |
| Pro+Media | 2 GB | 100 |
| Developer | 2 GB | unlimited |
| Enterprise | unlimited | unlimited |
Cookbook
Copy-paste diagnostics for each failure: confirming the format, explaining missing entries, decoding the size limit error, and handling a corrupt input.
Diagnose 'could not detect format'
Most commonly the file is a single .gz or a renamed archive. The detector tells you the truth in one read.
Drop the file at /archive-tools/auto-format-detector Result: 'GZIP (single file)' -> use /archive-tools/gzip-to-zip Result: 'RAR' or '7Z' -> use /archive-tools/multi-format-extractor Result: 'TAR.GZ' -> it should convert; check for corruption
Explain missing files
Preview the source, then compare entry counts. The gap is the skipped symlinks/hardlinks/dirs.
Source (archive-previewer): 120 entries
102 regular files
12 directory headers
6 symlinks
Converted ZIP entry count: 102
The 18 'missing' entries are dirs + symlinks — by design.Read the tier-limit error
The error names the file, your tier, and the cap. There is no ambiguity about what to do next.
File "backup.tar.gz" exceeds the free tier per-job limit (50 MB). Upgrade for larger files. Options: upgrade tier, or extract+zip with the CLI for huge files.
Handle a corrupt download
A gunzip error means the GZIP layer is broken. Re-download; if it persists, the source is damaged at rest.
Error: failed to inflate GZIP layer (invalid data) 1. Re-download the .tar.gz (it may have truncated) 2. Re-run auto-format-detector — magic bytes 1F 8B must be present 3. If still failing, the file itself is corrupt
Make sense of 'wrong' output size
A ZIP near or even slightly above the TAR.GZ size is normal when data is already dense.
in.tar.gz 42 MB (mostly JPEGs/MP4) out.zip 43 MB Why: media is already entropy-dense; DEFLATE can't shrink it, and ZIP adds per-entry headers. Confirm with compression-ratio-calculator.
Edge cases and what actually happens
Input over the tier cap
RejectedFiles above 50 MB (free) / 500 MB (pro) / 2 GB (pro-media, developer) are blocked before any work with: File "name" exceeds the {tier} tier per-job limit. Upgrade for larger files.
Renamed RAR or 7Z
Could not detect formatA .tar.gz that is really a RAR/7Z won't convert here. Confirm with /archive-tools/auto-format-detector, then unpack with /archive-tools/multi-format-extractor instead.
Single-file .gz, not a tarball
Wrong toolA plain .gz holding one file has no TAR inside. Use /archive-tools/gzip-to-zip, which reads the GZIP inner filename and wraps the single file.
Files missing from the ZIP
By designSymlinks, hardlinks, and standalone directory headers are not written to ZIP. The entry count reflects only regular files — this is expected, not data loss for those entry types.
Corrupt or truncated GZIP
Inflate errorIf the GZIP layer can't be inflated, fflate throws and the run stops. Re-download the archive and verify the 1F 8B magic bytes with the format detector.
Output bigger than input
ExpectedAlready-compressed payloads (JPEG, MP4, MP3, nested archives) can't shrink under DEFLATE, and ZIP adds per-entry header overhead, so the output can match or slightly exceed the input. Not a fault.
Stuck on 'Processing…'
WorkingThere is no timeout error — conversion is synchronous, so a large input holds the tab while fflate runs rather than failing. Wait for it; if the page seems stale after an update, hard-refresh and retry.
Long paths look truncated
May truncatePaths over the 100-byte TAR name field can truncate because the parser doesn't read GNU longname/PAX records. Rare in normal tarballs; if you hit it, unpack with the CLI.
Empty output ZIP
ExpectedIf the TAR.GZ contains no regular files (only dirs/links), the ZIP is valid but empty with entry count 0. Preview the source to confirm what it actually held.
Frequently asked questions
Why does it stay on 'Processing…'?
There is no 30-second timeout in this tool — conversion is a synchronous fflate gunzip and re-zip, so a large input briefly holds the tab while it works rather than erroring out. Wait for it to finish; if the page looks stale after an update, hard-refresh (Ctrl+Shift+R).
Why does my file fail to convert?
Usually it isn't a TAR.GZ. Check with /archive-tools/auto-format-detector: a single-file .gz needs /archive-tools/gzip-to-zip, and a renamed RAR/7Z needs /archive-tools/multi-format-extractor. A genuine but corrupt .tar.gz throws a gunzip error — re-download it.
Why are some files missing from the ZIP?
Symlinks, hardlinks, and standalone directory headers can't be represented in ZIP, so the converter drops them. Only regular files are packed. Preview the source with /archive-tools/archive-previewer and compare entry counts — the gap is those skipped entry types.
Why is the output smaller or larger than expected?
Compression varies by content: text and source shrink to roughly 15–25% of original; JPEG/MP4/MP3 and nested archives barely shrink and can even grow due to ZIP header overhead. Use /archive-tools/compression-ratio-calculator for a per-file breakdown.
What error messages might I see?
'File ... exceeds the {tier} tier per-job limit' — input too big. 'Could not detect or extract archive format' — not a recognised archive or wrong type. A gunzip/inflate error — the GZIP layer is corrupt or truncated.
Is there a setting I configured wrong?
No — TAR.GZ → ZIP has no options. It always gunzips, packs regular files, and re-zips at DEFLATE level 6. Misconfiguration is never the cause; check size, format, and corruption instead.
Did my file get uploaded when it failed?
No. The tool never uploads — everything runs in your browser tab via fflate. Failures are local (size, format, corruption); there is no server round-trip to blame.
Why won't my password-protected archive convert?
This converter has no password field — it expects a plaintext TAR.GZ. Encrypted ZIP entries are handled by other tools; for encrypted archives, decrypt first with /archive-tools/archive-password-tester or the appropriate extractor.
The extracted ZIP files aren't executable — bug?
No. ZIP entries from this tool carry no Unix mode bits, so extracted files lose their executable flag. Re-run chmod +x after extraction, or keep the original tarball where permissions matter.
My .tgz won't open — is that supported?
Yes, .tgz is just .tar.gz and uses the same pipeline. If it won't convert, run the format detector — the file may be misnamed or corrupt rather than a true .tgz.
Can I recover a damaged ZIP I made elsewhere?
That's a different problem — /archive-tools/corrupted-zip-repair scans a damaged ZIP for surviving entries. This converter only produces fresh ZIPs from TAR.GZ inputs.
What if the archive is over 2 GB?
Every JAD tier caps the input at 2 GB or below, so it will be rejected. Extract and zip such archives with the CLI (tar -xzf in.tar.gz && zip -r out.zip <files>) or split them first.
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.