How to troubleshooting zip → tar.gz
- Step 1Read the error text first — The tool surfaces the real message in a red box.
Archive contains encrypted entries…→ password problem.exceeds the … tier per-job limit→ size.Could not detect or extract archive format→ input isn't a recognised archive. Match the string before guessing. - Step 2Check for encryption — If the message mentions encrypted entries, your ZIP is password-protected. This tool has no password field and cannot proceed. Confirm with the encrypted archive detector, then extract with the multi-format extractor (it has a password input) and repackage.
- Step 3Check the size against your tier — Free allows 50 MB and 500 entries; Pro 500 MB / 50,000; Pro-media and Developer 2 GB / 500,000. The check uses the on-disk file size and fires before processing. If you're over, upgrade or split the archive first.
- Step 4Verify the input is really an archive — The reader sniffs magic bytes. A renamed
.txt, a partial download, or a corrupt header won't be recognised. Re-download the file, confirm the extension matches the real content, and try opening it in another archiver to rule out corruption. - Step 5If it's stuck 'Processing…', suspect memory — Conversion holds the input, the fully-decompressed contents, and the output in memory at once. A small ZIP that inflates to gigabytes can hang or crash the tab. Close other tabs, try a machine with more RAM, split the source, or fall back to the CLI.
- Step 6Confirm 'missing' files are an expectation, not a loss — If the entry count is lower than expected, it's usually dropped empty folders (only file entries are written) or an encrypted entry that stopped the job. List the output with
tar -tzfto see exactly what made it through.
Error message → cause → fix
The exact strings the tool surfaces and what to do about each.
| Message you see | Cause | Fix |
|---|---|---|
Archive contains encrypted entries (e.g. "…"). Provide a password to extract. | Password-protected ZIP; no password field on this tool | Decrypt first or extract with the multi-format extractor, then convert |
File "x.zip" exceeds the free tier per-job limit (50 MB). Upgrade for larger files. | Over the tier size cap | Upgrade tier, or split the archive before converting |
Could not detect or extract archive format for <name> | Not a recognised archive (corrupt, renamed, partial download) | Re-download; confirm it's a real archive; test in another tool |
Drop an archive file to process. | Pressed Process with no file | Add a file to the dropzone first |
Tab freezes on Processing… | In-memory blow-up on a hugely-expanding archive | Split, free RAM, paid tier, or use the CLI |
| Output missing some files | Empty folders dropped / encrypted entry stopped the job | Expected for empty dirs; check for encryption otherwise |
Looks like a bug, is by design
Behaviours frequently mistaken for failures.
| Symptom | Why | What to do |
|---|---|---|
| Executable scripts no longer run after extract | Every entry written at mode 0644 | chmod +x after extraction |
| Empty directories missing from output | Only file entries are written to the TAR | Recreate with mkdir -p if needed |
| Checksum differs every time | TAR mtime = current time per run | Checksum the shipped artifact once; don't re-derive |
| Symlinks became regular files | Reader flattens links to target bytes | Recreate links after extraction |
| Output is a .tar inside a .gz on Windows | GZIP wraps a single TAR stream | tar -xzf or 7-Zip unwrap both at once |
Cookbook
Each diagnosis with the symptom, the real cause from the code, and the exact fix.
Encrypted ZIP refuses to convert
The most common hard stop. The error names a sample encrypted entry so you know it's not a generic failure.
Drop: protected.zip Error (red box): Archive contains encrypted entries (e.g. "config.env"). Provide a password to extract. Fix: 1. Detect: encrypted-archive-detector confirms AES/ZipCrypto 2. Extract with multi-format-extractor (password field) 3. Re-zip the cleartext, then convert
Over the free tier cap
Size is checked before any processing, so you see this immediately on Process.
Drop: dataset.zip (88 MB) on free tier Error: File "dataset.zip" exceeds the free tier per-job limit (50 MB). Upgrade for larger files. Fix: upgrade to Pro (500 MB) or split the archive first.
Unrecognised format
A renamed or corrupt file fails magic-byte detection after a last-resort ZIP attempt.
Drop: report.zip (actually a renamed PDF) Error: Could not detect or extract archive format for report.zip Fix: it isn't a ZIP — check the true type $ file report.zip → PDF document rename to .pdf; this tool only converts real archives
Stuck on Processing — memory blow-up
A tiny ZIP of a huge sparse/log file inflates beyond what the tab can hold.
Drop: logs.zip (12 MB) → inflates to ~6 GB of text Symptom: spinner never finishes, tab may crash Fix: - close other tabs / use a 16 GB+ machine, OR - split the source, OR - CLI: unzip logs.zip && tar czf logs.tar.gz logs/
Fewer entries than expected (not a bug)
Empty folders are dropped; the file count is lower but no files are lost.
ZIP: 30 files + 4 empty folders (34 entries in Explorer) Result panel: Entries: 30 This is correct — empty directories aren't written to TAR. Verify nothing real is missing: tar -tzf out.tar.gz | wc -l → 30 files present
Edge cases and what actually happens
Encrypted ZIP, no way to supply a password
RejectedThe central directory is probed before unzipping; any encrypted entry stops the job with Archive contains encrypted entries… Provide a password to extract. This tool has no password input, so there's no workaround within it — extract elsewhere with a password-capable sibling, then convert the cleartext.
File over the tier cap
Blocked (limit)Checked before processing using on-disk size: 50 MB free, 500 MB Pro, 2 GB top tiers. The message names the file, the tier, and the limit. Upgrade or split. Note the check is on the compressed file size, not the uncompressed total.
Input not a recognised archive
RejectedFormat is detected from magic bytes; an unknown header triggers a last-resort ZIP attempt and, if that fails, Could not detect or extract archive format. Causes: renamed file, partial/corrupt download, or a format outside the supported set. Re-download and verify the true type.
Pressed Process with no file
RejectedDrop an archive file to process. — the run guard requires a file for this non-generative tool. Add one to the dropzone. (Only the first file is used if you drop several.)
Huge in-memory expansion
May fail (memory)Conversion decompresses fully and holds input, contents, and output simultaneously. A small archive that inflates to gigabytes can freeze or crash the tab. Mitigate by splitting, freeing RAM, using a paid tier on a larger machine, or switching to the streaming CLI.
Permissions gone after extraction
By designEvery TAR entry is mode 0644 — executable bits are not preserved (ZIP doesn't expose Unix mode cleanly). Not a bug: chmod +x after extraction, or use the CLI when permissions must survive.
Empty directories missing
By designOnly regular file entries are written; bare/empty directory entries are dropped. The folder structure of non-empty directories survives through file paths. Recreate any required empty dirs after extraction with mkdir -p.
Checksum changes on re-conversion
ExpectedThe TAR mtime is the current time, so re-converting the same ZIP yields different bytes and a different hash. This isn't corruption. Checksum the artifact you actually keep; don't expect a re-run to reproduce the digest.
Symlinks turned into files
By designThe reader resolves symlinks to their target contents, so links become regular files in the TAR. If you need the links, recreate them after extracting, or use a CLI path that preserves them.
WebAssembly blocked by a browser extension
Possible blockExotic inputs (7z/RAR/XZ/ISO) need the libarchive WASM module. A strict privacy/security extension or enterprise policy that blocks WebAssembly can make those inputs fail while plain ZIP (handled by fflate) still works. Try a clean browser profile or temporarily disable the blocking extension.
Frequently asked questions
Why does it say my ZIP has encrypted entries?
Your ZIP is password-protected. The tool probes the central directory and refuses if any entry is encrypted, because it has no password field. Detect it with the encrypted archive detector, extract with the password-capable multi-format extractor, then convert the cleartext result.
How do I convert a password-protected ZIP to TAR.GZ?
Not directly here — there's no password input. Extract the ZIP with a tool that accepts a password (e.g. the multi-format extractor), repackage the extracted files into an unencrypted ZIP or TAR, then run this converter. TAR has no native encryption, so the output is cleartext regardless.
What does 'exceeds the tier per-job limit' mean?
Your file is bigger than your tier allows: 50 MB free, 500 MB Pro, 2 GB Pro-media/Developer. The check runs before any processing using the file's on-disk size. Upgrade your tier, or split the archive into smaller pieces before converting.
Why do I get 'Could not detect or extract archive format'?
The file isn't a recognised archive. Common causes: it was renamed (a .pdf saved as .zip), the download was incomplete, or the header is corrupt. Verify the true type (file name.zip on Unix) and re-download if needed. The tool only converts genuine archives.
The tool is stuck on 'Processing…' — is it frozen?
Probably a memory issue. Conversion is in-memory and decompresses fully, so a small archive that expands to gigabytes can exhaust the tab. Close other tabs, use a machine with more RAM, split the source, or convert on the CLI for very large inputs.
Why are fewer files in the output than in my ZIP?
Two reasons. Empty directories are dropped — only file entries are written — so the count looks lower without any real loss. Or an encrypted entry stopped the job entirely. List the output with tar -tzf to confirm exactly what came through.
My executable doesn't run after extracting — bug?
No — by design. Every entry is written at mode 0644, so executable bits aren't preserved (ZIP doesn't expose Unix mode reliably). Run chmod +x on the binary after extraction, or use a CLI unzip | tar czf pipeline when permissions must carry over.
Why does the checksum change every time I convert?
The TAR stores the current time as each entry's mtime, so re-converting the same ZIP produces different bytes and a different hash. It's not corruption. Generate the checksum once on the artifact you'll actually use; don't try to reproduce it by re-running.
Can a browser extension break it?
Yes, for non-ZIP inputs. 7z/RAR/XZ/ISO conversion needs the libarchive WebAssembly module; an extension or enterprise policy that blocks WASM can make those fail while plain ZIP (handled by fflate, no WASM) still works. Try a clean profile or disable the blocker.
Does it actually upload my file when it 'fails'?
No — nothing is ever uploaded, success or failure. All processing is in the browser via fflate/WASM, and the result panel shows 0 bytes uploaded. Errors are computed locally; your file never leaves the device.
It accepted my .7z but I expected only ZIP — is that wrong?
That's intended. The reader handles ZIP, TAR, GZIP, 7z, RAR, BZ2, XZ and ISO, all converging to TAR.GZ. If you specifically want to choose the output format, use the archive format converter; to go from TAR.GZ back to ZIP, use TAR.GZ to ZIP.
When should I just use the command line instead?
When the file is multi-gigabyte (the browser is in-memory and capped at 2 GB), when you need preserved permissions/symlinks, or when you need byte-reproducible output (the tool stamps the current mtime). For convenient, private, install-free one-offs in the MB-to-hundreds-of-MB range, the browser tool is ideal.
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.