How to troubleshooting gzip → zip
- Step 1Confirm the input is a single-file GZIP — Run auto-format-detector on the file. It reads the first bytes and reports the true format. If it says
tar.gz, this is the wrong tool — see step 2. If it sayszip/rar/7z, the file was just renamed.gz. - Step 2If it's a .tar.gz, switch tools — A
.tar.gzgunzips to one TAR blob, which this wrapper zips whole — you'd get a ZIP holding a lone.tar. Use tar-gz-to-zip so the inner files unpack into individual ZIP entries. - Step 3Check the size against your tier — Free caps the uploaded
.gzat 50 MB; Pro at 500 MB; Pro+Media and Developer at 2 GB. An oversized file is blocked before processing with a message naming your tier and the limit. Upgrade or trim the source before compressing. - Step 4Rule out a truncated/corrupt stream — If you see "invalid gzip data" on a file that really is GZIP, it's likely truncated from an interrupted download or a partial
kubectl cp/scp. Re-fetch the file in full — GZIP has no partial-recovery path here. - Step 5Check the recovered inner filename — The entry name comes from the GZIP FNAME header. If it's wrong or generic, the source was probably made with
gzip -n(no name) and the tool fell back to stripping.gzfrom your upload's filename. Rename the upload before converting to control the result. - Step 6Interpret an output that didn't shrink — GZIP and ZIP both use DEFLATE, so re-zipping already-compressed data gives near-identical size plus a little container overhead. Use compression-ratio-calculator on the result to see the per-entry ratio.
GZIP → ZIP failure decision table
Match the symptom to the cause and the fix. Error wording reflects the real implementation.
| Symptom | Likely cause | Fix |
|---|---|---|
| "invalid gzip data" error | Not GZIP (renamed ZIP/RAR/7Z) or truncated stream | Run auto-format-detector; re-download if truncated |
ZIP contains one .tar, not the files | Input was a .tar.gz (multi-file) | Use tar-gz-to-zip |
| Blocked before processing | File over the tier size cap | Upgrade tier or shrink the source |
| Inner entry has a generic/wrong name | Source made with gzip -n (no FNAME) | Rename the upload before converting |
Output not smaller than the .gz | Already-compressed data (DEFLATE↔DEFLATE) | Expected; verify with compression-ratio-calculator |
| Tab hangs on a huge file | Decompressed payload exhausts browser memory | Use a smaller file or a desktop with more RAM |
Error message → meaning
What the wording actually indicates, grounded in the code paths that emit it.
| Message | Where it comes from | Action |
|---|---|---|
| "invalid gzip data" | fflate gunzipSync magic/trailer check | Confirm format; re-download |
| "... exceeds the free tier per-job limit (50 MB)" | Client size check before processing | Upgrade or trim source |
| "Drop an archive file to process." | No file selected | Add a .gz to the dropzone |
| Unexpected inner name in metrics | FNAME absent → fallback to input name minus .gz | Rename upload before converting |
Cookbook
Each common failure reproduced, with the diagnostic output and the fix.
"invalid gzip data" on a renamed file
The most frequent error. A file ends in .gz but its magic bytes aren't 1F 8B, so fflate rejects it. The detector reveals what it really is.
Run gzip-to-zip on archive.gz → error:
"invalid gzip data"
auto-format-detector on archive.gz:
magicBytes: "50 4B 03 04 ..." (= ZIP, not GZIP)
format: "zip"
Fix: it's already a ZIP — no conversion needed,
or use multi-format-extractor to open it.ZIP holds a lone .tar instead of files
Dropping a .tar.gz 'succeeds' but produces the wrong shape. The output ZIP contains a single .tar because the wrapper treats the GZIP as one stream.
Input: build.tar.gz
Output: build.zip
└─ build.tar ← inner files NOT unpacked
Correct tool:
/archive-tools/tar-gz-to-zip on build.tar.gz →
build.zip
├─ src/index.ts
├─ package.json
└─ ... ← individual entriesTier-limit block on a big .gz
A 90 MB log on the Free tier is rejected before any work happens. The message names the tier and the cap.
Free tier, input: debug.log.gz (90 MB) Result (red panel): File "debug.log.gz" exceeds the free tier per-job limit (50 MB). Upgrade for larger files. Fix: Pro raises the cap to 500 MB.
Unexpected inner filename
A .gz made with gzip -n carries no FNAME field, so the tool names the entry by stripping .gz from your upload's name. Rename the upload to control it.
Source compressed with: gzip -n payload.bin
(FNAME omitted)
Upload named: download.gz
Output entry name: download ← fallback, not "payload.bin"
Fix: rename upload to payload.bin.gz before converting
→ entry becomes payload.binOutput no smaller than the input
Re-zipping an already-DEFLATEd payload yields the same size. This is correct behaviour, confirmed by the ratio calculator.
Input: events.json.gz (3.1 MB) Output: events.json.zip (3.1 MB + overhead) compression-ratio-calculator on the output: events.json ratio: ~0% additional → DEFLATE can't re-shrink DEFLATE output. Expected.
Edge cases and what actually happens
Renamed non-GZIP file
Invalid inputfflate's gunzipSync validates the GZIP magic bytes (1F 8B). A ZIP/RAR/7Z renamed to .gz throws "invalid gzip data". Run auto-format-detector to read the real magic and pick the matching tool.
A .tar.gz dropped in
By design (wrong tool)A .tar.gz gunzips to a single TAR blob that this wrapper zips whole — the output ZIP holds a lone .tar, not the inner files. Use tar-gz-to-zip to unpack the TAR into individual entries.
File over the tier cap
Rejected (tier limit)The client checks the compressed .gz size before processing: 50 MB Free, 500 MB Pro, 2 GB Pro+Media/Developer. Oversized files error with a message naming your tier. The cap is on the upload, not the decompressed payload.
Truncated or interrupted .gz
ErrorGZIP ends with a CRC32 + length trailer. A stream cut off mid-transfer fails that check and errors as invalid data. Re-download in full; there is no partial-recovery path for GZIP in this tool.
No file selected
ErrorClicking Process with an empty dropzone throws "Drop an archive file to process." Add a single .gz and retry.
Wrong or generic inner filename
Preserved (fallback)When the source has no FNAME header (e.g. gzip -n), the entry name is derived by stripping .gz from the upload filename — and if that's empty, it becomes data. To control the name, rename the upload before converting.
Output is the same size or larger
ExpectedGZIP and ZIP both use DEFLATE, so re-compressing already-compressed data gives near-identical size plus ZIP's small header overhead. Confirm the per-entry ratio with compression-ratio-calculator.
Tab appears to hang on a very large file
Memory pressureThere is no fixed timeout in this tool. A stall on a large file is the decompressed payload exhausting browser memory — a 50 MB .gz of text can expand to many hundreds of MB. Use a smaller file, a desktop with more RAM, or a higher tier; the runner path on Pro+ offloads to a local headless browser.
Multiple files dropped
First file onlyThis is a single-file tool; extra files are discarded. There's no batch conversion mode here. To bundle many local files into one archive, use folder-to-zip.
Frequently asked questions
Why do I get "invalid gzip data"?
The file isn't a valid GZIP stream. Either it was renamed from another format (a ZIP/RAR/7Z called .gz) or it's truncated. Run auto-format-detector to read the magic bytes; if it really is GZIP, re-download it in full because it's likely truncated.
My ZIP contains a single .tar instead of the files — what happened?
You fed a .tar.gz. This wrapper treats the GZIP as one stream, so the inner TAR is zipped whole. Use tar-gz-to-zip, which parses the TAR and writes each file as its own ZIP entry.
Why was my file blocked before processing?
It exceeds your tier's per-job size cap — 50 MB Free, 500 MB Pro, 2 GB Pro+Media/Developer. The limit is on the compressed .gz you upload. Upgrade your tier or shrink the source before compressing.
Is there a processing timeout I'm hitting?
No — this tool has no configurable timeout. If a run stalls, it's memory pressure from a large decompressed payload, not a time cutoff. Try a smaller file or a machine with more RAM.
Why is the inner filename wrong or generic?
The entry name comes from the GZIP FNAME header. If the source was made with gzip -n (which omits the name), the tool falls back to stripping .gz from your upload's filename. Rename the upload before converting to control the resulting entry name.
Why didn't the ZIP get smaller than the .gz?
GZIP and ZIP both compress with DEFLATE. Re-compressing data that's already near its entropy floor yields essentially the same size, and ZIP adds a small header overhead. This is expected. Use compression-ratio-calculator to see the per-entry ratio.
Why does it say "Drop an archive file to process."?
No file is selected. Drop a single .gz onto the dropzone (or click to browse) and then click Process.
Could a browser extension cause a failure?
Extensions rarely break this tool because the conversion is pure fflate WebAssembly with no worker messaging it depends on. If you suspect interference, retry in an Incognito window with extensions disabled — but a hard error here is almost always a bad input or a tier limit, not an extension.
How do I confirm a mystery file's true format?
Run auto-format-detector. It reads the first bytes and reports ZIP/GZ/TAR/BZ2/XZ/7Z/RAR by magic signature, independent of the file extension, and suggests the right tool.
Can I recover a corrupt .gz?
Not with this tool — GZIP has no entry-level recovery here. If you have a damaged ZIP (not GZIP), corrupted-zip-repair scans for surviving local file headers. For a truncated GZIP, the only fix is re-downloading the source.
I have many .gz files failing one by one — is there a batch fix?
This conversion is one file per run. For converting many files, the gzip -dk file.gz && zip out.zip file shell pipeline scales better. For bundling many local files into a single archive, folder-to-zip accepts multiple files at once.
How do I verify the output is intact after conversion?
Run archive-integrity-tester on the ZIP to confirm the entry's stored CRC32 matches its data, or checksum-generator for a SHA-256 manifest.
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.