How to troubleshooting zip to 7z
- Step 1Confirm the output type first — If your only complaint is 'I got a .tar.gz', stop here — that is the intended output. Open it in 7-Zip/Keka/WinRAR/
tar; it extracts fine. The tool cannot make a native.7zin the browser. - Step 2Check the file size against your tier — If processing was refused, compare the archive size to your cap: Free 50 MB, Pro 500 MB, Pro-media/Developer 2 GB. Also check entry count (500 / 50,000 / 500,000). Either limit can trigger a rejection.
- Step 3Verify the input is really a ZIP — A 'could not detect or extract' error usually means the file isn't a real ZIP (a renamed
.7z/.rar, or a corrupt download). Run auto-format-detector to see the true format from its magic bytes. - Step 4Check for encryption — If extraction fails on a valid ZIP, it may be password-protected. This tool has no password field. Confirm with encrypted-archive-detector, then decrypt+extract with multi-format-extractor and re-zip the plaintext.
- Step 5If it stalls, suspect size/memory — A large archive near the cap is processed entirely in RAM and can make the tab feel frozen. Wait it out, close other heavy tabs, or split with archive-splitter so each part is well under the cap.
- Step 6If files look missing, check the by-design drops — Empty folders and original timestamps are not preserved. If a checksum of the extracted files matches the source, nothing is corrupted — only empty dirs/mtimes changed. Use checksum-generator to confirm.
Symptom -> cause -> fix
The fastest path from a complaint to a resolution. 'By design' rows are not bugs.
| Symptom | Likely cause | Fix |
|---|---|---|
Got a .tar.gz, expected .7z | Native 7Z write isn't possible in-browser (by design) | Open the .tar.gz in 7-Zip; or use a native 7-Zip install for a real .7z |
| 'File exceeds the … limit' | Over the tier byte cap (50 MB Free) | Upgrade tier or split with archive-splitter |
| Rejected but file looks small | Over the entry-count cap (500 Free) | Upgrade tier; entry cap is separate from byte cap |
| 'Could not detect or extract' | Input isn't a real ZIP / corrupt | Check true format with auto-format-detector |
| Extraction fails on a valid ZIP | ZIP is encrypted; no password field here | Decrypt with multi-format-extractor, re-zip, retry |
| Tab freezes mid-process | Large archive processed in RAM | Close tabs / split the archive into parts |
| Empty folders missing | Directory entries dropped (by design) | Recreate folders downstream; contents are intact |
| Timestamps all the same/new | TAR header uses conversion time (by design) | Normalise with timestamp-normalizer |
Tier limits to check against
Both the byte cap and the entry-count cap apply per archive. A rejection means one of these, not a crash.
| Tier | Max size | Max entries | Files/run |
|---|---|---|---|
| Free | 50 MB | 500 | 1 |
| Pro | 500 MB | 50,000 | 20 |
| Pro-media | 2 GB | 500,000 | 100 |
| Developer | 2 GB | 500,000 | Unlimited |
Cookbook
Worked fixes for the failures people actually report. Each shows the symptom, the diagnosis, and the resolving action.
'It gave me a .tar.gz, I wanted a .7z'
The most common report — and not a bug. The tool can't write native 7Z in the browser, so it emits TAR.GZ, which 7-Zip opens.
Symptom: downloaded report.tar.gz, expected report.7z Diagnosis: by design — metrics say 'Native 7Z: unavailable in browser' Fix: double-click report.tar.gz in 7-Zip/Keka/WinRAR -> extracts fine. Need a true .7z? Use a native 7-Zip install: 7z a report.7z extracted/
Encrypted ZIP fails to convert
A password-protected ZIP can't be read because the tool has no password field. Decrypt first, then convert the plaintext.
Symptom: conversion fails on a valid ZIP Check: encrypted-archive-detector -> 'AES-256 encrypted entries' Fix: 1. multi-format-extractor with the password -> plaintext files 2. re-zip the plaintext (folder-to-zip) 3. zip-to-7z on the plaintext zip -> works
File-too-large rejection on Free
A 120 MB archive is refused on Free (50 MB cap). Two ways out depending on whether you can upgrade.
Symptom: 'File exceeds the 50 MB limit for your tier.'
Fix A: upgrade to Pro -> 500 MB cap, runs.
Fix B: archive-splitter -> 3 x 40 MB parts -> convert each part
(each part is under 50 MB).'Could not detect or extract' on a .zip
The file is named .zip but isn't one — often a renamed 7z/rar or a truncated download. Identify the real format.
Symptom: 'Could not detect or extract archive format for file.zip' Check: auto-format-detector -> reports actual magic bytes If it's really a 7z/rar: extract with multi-format-extractor, re-zip, then convert. If truncated: re-download the file.
Files seem missing after conversion (they're not)
Empty folders vanish and timestamps reset — both by design. Prove the actual file contents are intact with a checksum.
Symptom: 'logs/' folder gone; all dates show today Diagnosis: empty dirs dropped + TAR uses conversion time (by design) Proof: checksum-generator on source vs output -> per-file hashes match Fix mtimes if needed: timestamp-normalizer before converting.
Edge cases and what actually happens
Output is .tar.gz instead of .7z
By designNot a failure. Browser-side native 7Z (LZMA2) writing is intentionally not implemented (it needs a heavy WASM encoder), so the tool re-packages as TAR.GZ. The metrics state 'Native 7Z: unavailable in browser'. The .tar.gz opens in 7-Zip/Keka/WinRAR/tar.
Password-protected ZIP
FailsThe tool exposes no password field, so encrypted ZIP entries can't be decrypted and the conversion fails. Detect with encrypted-archive-detector, decrypt+extract with multi-format-extractor, re-zip, then convert.
Archive over the byte cap
Rejected (limit)Free refuses anything over 50 MB before processing. Caps are 50 MB / 500 MB / 2 GB / 2 GB by tier. Upgrade or split with archive-splitter. The check is on the input ZIP size.
Archive over the entry-count cap
Rejected (limit)A small archive with thousands of tiny files can still be rejected: Free allows 500 entries, Pro 50,000, Pro-media/Developer 500,000. This cap is independent of the byte cap.
Input isn't a real ZIP
FailsAn unrecognised file (renamed .7z/.rar, corrupt download) throws 'Could not detect or extract archive format'. Check the true format with auto-format-detector; re-download if truncated.
Tab stalls or freezes on a large archive
Slow / memory-boundThe entire archive is decompressed and re-compressed in browser RAM. Near the 2 GB cap this can feel frozen for a while or hit a memory wall on a low-RAM machine. Close other heavy tabs or split the archive so each part is well under the cap.
Empty folders missing from output
Not preservedZIP directory entries (names ending in /) are dropped on extraction. Empty folders disappear; folders with files survive via their file paths. Recreate empty dirs downstream if needed — the file contents are untouched.
All timestamps show the conversion time
Not preservedThe TAR header writes the current time for every entry, so original ZIP mtimes are not carried over. This is by design, not corruption. Normalise with timestamp-normalizer if stable dates matter.
Browser extension blocks WebAssembly / scripts
EnvironmentA strict content-blocker or locked-down enterprise policy can prevent the page's JavaScript/WASM from running, so nothing happens on drop. Try a clean browser profile or allowlist the page. The conversion itself needs no network, only local script execution.
Output larger than the input
Expected sometimesIf the ZIP held already-compressed data (media, a high-compression ZIP), GZIP can't shrink it and adds slight overhead. This is normal for incompressible content and not an error.
Frequently asked questions
Why did I get a .tar.gz instead of a .7z?
Because the tool cannot write native 7Z in a browser — that needs a heavy WASM LZMA2 encoder it deliberately doesn't ship. It re-packages your ZIP as TAR.GZ instead, which opens in 7-Zip, Keka, WinRAR, and tar. The metrics even say 'Native 7Z: unavailable in browser'. It's intended behaviour, not a bug.
My password-protected ZIP won't convert — why?
The tool has no password field, so it can't decrypt encrypted ZIP entries and the conversion fails. Decrypt and extract first with multi-format-extractor (it takes a password), re-zip the plaintext with folder-to-zip, then convert that.
It says my file is too large — what's the limit?
Free allows 50 MB and 500 entries per archive. Pro is 500 MB / 50,000, Pro-media and Developer 2 GB / 500,000. Both the byte cap and the entry count are checked, so a small file with too many entries can also be rejected. Upgrade or split with archive-splitter.
I get 'Could not detect or extract archive format' — what now?
The file probably isn't a real ZIP — it may be a renamed .7z/.rar or a corrupt/truncated download. Run auto-format-detector to see the true format from its magic bytes. If it's a different archive type, extract with multi-format-extractor and re-zip; if it's truncated, re-download.
The tab freezes when I convert a big archive. Is it broken?
Probably not — the whole archive is decompressed and re-compressed in browser memory, so a large one can make the tab unresponsive for a while or hit a RAM limit. Wait it out, close other heavy tabs, or split the archive with archive-splitter so each part is well under the cap.
My empty folders are gone after conversion — is that a bug?
No. ZIP directory entries are dropped during extraction, so empty folders don't appear in the output. Folders that contain files are preserved. The file contents themselves are intact — recreate any needed empty directories downstream.
Why are all my file dates the same / today's date?
The TAR header stamps every entry with the conversion time rather than the original ZIP mtime. It's by design. If you need stable dates (e.g. for reproducible builds), normalise with timestamp-normalizer before converting and re-normalise after extraction.
How do I prove the conversion didn't corrupt my files?
Run checksum-generator on the source ZIP's contents and on the converted TAR.GZ's contents — the per-file hashes match because the conversion is byte-lossless. If hashes match, only the container (and empty dirs/timestamps) changed.
Nothing happens when I drop a file — why?
Usually a strict content-blocker or enterprise policy preventing the page's JavaScript/WebAssembly from running. Try a clean browser profile, disable the blocker for the page, or use a different browser. The conversion needs no network access, only local script execution.
Can I change the compression to get a smaller file?
No — the tool has no options and uses a fixed GZIP level 6. For a smaller result you'd need LZMA2 (a native 7z, which this tool can't produce). To see how different levels affect size on a ZIP, use compression-level-optimizer.
Why is my output bigger than the original ZIP?
If the ZIP already contained compressed data (JPEGs, MP4s, or a high-compression ZIP), GZIP can't shrink it further and adds a little container overhead. That's expected for incompressible content — the conversion changed the format, not the size, in that case.
Is there an API or CLI if the browser tool keeps failing for my use case?
There's no REST API for archive tools (they're browser-only). On Pro+ you can automate via the @jadapps/runner (headless browser), or reproduce the conversion locally with unzip then tar czf. For a clearer-named equivalent see zip-to-tar-gz.
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.