How to troubleshooting the archive integrity tester
- Step 1Confirm the file is actually a ZIP —
Not a valid ZIP archivemeans the tool found no ZIP central directory. Run auto-format-detector — a renamed.7z/.rar/.tar.gzis the usual culprit. This tool verifies ZIP CRC32 only. - Step 2Check the tier limit before anything else — Free caps inputs at 50 MB and 500 entries; the check runs before processing, so an oversized or entry-heavy ZIP is rejected immediately. Pro raises this to 500 MB / 50,000 entries, Pro-Media/Developer to 2 GB / 500,000.
- Step 3If it's encrypted, supply the right password — A decryption-failure report (
Archive contains encrypted entries … Provide a password) means the ZIP is encrypted. Type the password in the password field; it's case- and whitespace-sensitive. This is not a corruption failure. - Step 4Read CRC mismatches as real corruption — A
CRC mismatchormissingper-entry result means that file's bytes are damaged or absent — the tool is working. Re-download from source; if only some entries fail, salvage the rest with corrupted-zip-repair. - Step 5Rule out browser interference — If the page stalls without an error, a browser extension may be touching the WASM worker channels. Retry in a private/incognito window with extensions disabled, and hard-refresh (Ctrl+Shift+R) to drop a stale cached bundle.
- Step 6Escalate to the right tool — Need tamper detection, not corruption? Use SHA-256 via checksum-generator. Need to know what changed between two ZIPs? Use archive-diff. Need to recover a broken ZIP? Use corrupted-zip-repair.
Error / symptom → cause → fix
The full diagnostic matrix. Match the message you see to the row.
| Symptom | Cause | Fix |
|---|---|---|
Not a valid ZIP archive. | File has no ZIP central directory — it's a 7z/rar/tar/gz, or not an archive at all | Identify with auto-format-detector; this tool verifies ZIP only |
Report says Decompression failed / Provide a password | ZIP has encrypted entries and the password is missing or wrong | Enter the correct password (case/space-sensitive) in the password field |
Per-entry CRC mismatch: computed <hex> | That entry's bytes don't match its stored CRC32 — genuine corruption or tampering | Re-download the file; salvage others with corrupted-zip-repair |
Per-entry missing | Entry is in the directory but couldn't be decompressed — usually a truncated archive | Re-fetch a complete copy; a trailing run of missing = truncation |
Tier limit exceeded (before processing) | File over 50 MB or over 500 entries on Free | Upgrade tier, or split the archive with archive-splitter |
| Page stuck, no error | Browser extension touching WASM workers, or a stale cached build | Retry in incognito with extensions off; hard-refresh (Ctrl+Shift+R) |
Is it a tool problem or a file problem?
Half of 'errors' are the tool correctly reporting a damaged file. This table separates the two.
| Outcome | Whose problem | What it means |
|---|---|---|
CRC mismatch / missing entries | File problem | The tool found real corruption — re-fetch or repair the file |
Not a valid ZIP archive | Input problem | Wrong format dropped in — verify and use the right tool |
| Decryption failure | Input problem | Missing/wrong password — supply the correct one |
| Tier-limit rejection | Plan limit | File exceeds your tier — upgrade or split |
| Page stalls / no result | Tool/env problem | Browser extension or stale cache — incognito + hard refresh |
Cookbook
The exact message you'll see, what caused it, and the one-line fix. Filenames anonymised.
'Not a valid ZIP archive' on a renamed 7z
The single most common report. The file was renamed to .zip but is really a 7z; there's no ZIP central directory to read, so the tool stops at once.
Drop: backup.zip → Error: "Not a valid ZIP archive."
Diagnose with /archive-tools/auto-format-detector:
Detected format: 7z (magic 37 7A BC AF 27 1C)
Fix: it's a 7z. Verify it with 7z t, or extract its inner
ZIP first. This tool checks ZIP CRC32 only.Decryption failure mistaken for corruption
An encrypted ZIP processed without a password returns an error report — not a CRC failure. The fix is a password, not a re-download.
Drop: secure.zip (no password) →
{ "error": "Archive contains encrypted entries
(e.g. \"db.sql\"). Provide a password to
extract.", "entries": [] }
Fix: type the password in the password field, Process again.
Wrong password → similar decryption error (not a CRC mismatch).A real CRC mismatch — the tool working
One entry's CRC32 doesn't match. This isn't a bug to work around; it's the tool catching a damaged file. The fix lives outside the tester.
Report:
{ "totalEntries": 320, "passed": 319, "failed": 1,
"results": [
{ "name": "data/db.sqlite",
"storedCrc32": "5fa2c108", "passed": false,
"error": "CRC mismatch: computed 5fa2c1f0" } ] }
Fix: re-download db.sqlite's source ZIP. To keep the other
319 good entries, run /archive-tools/corrupted-zip-repair.Tier limit hit by entry count, not size
A 30 MB ZIP under the Free size cap still rejects — because it has 1,200 entries, over the 500-entry Free limit.
Drop: node-modules-snapshot.zip (30 MB, 1,200 entries)
→ Tier limit exceeded (Free: 500 entries max)
Note: size (30 MB) was fine; the ENTRY COUNT triggered it.
Fix: upgrade to Pro (50,000 entries) or split with
/archive-tools/archive-splitter.Stuck page from an extension or stale cache
No error, just a spinner. Usually a browser extension touching the WASM worker, or an old cached chunk.
Symptom: page sits on the processing state, no result, no error.
Fix order:
1. Hard-refresh: Ctrl+Shift+R (drops stale build).
2. Open an incognito/private window (extensions off).
3. Retry. If it now works, an extension was the cause —
disable extensions that touch page/worker messages.Edge cases and what actually happens
Dropped a non-ZIP (7z / rar / tar / gz)
Rejected — not a ZIPThe tester reads the ZIP central directory; these formats don't have one, so the entry list is empty and it throws Not a valid ZIP archive. By design — it won't silently fall back to another checksum. Identify the real format with auto-format-detector and use the matching path (e.g. 7z t).
Encrypted ZIP, no/blank password
Decryption failedIf any entry is encrypted the archive routes through zip.js; with no password the report is an error object (Archive contains encrypted entries … Provide a password) and an empty entries array. This is not corruption — enter the password in the password field and re-run.
Wrong password on an encrypted ZIP
Decryption failedzip.js can't decrypt the entries, so you get a decryption error rather than a CRC mismatch. Don't read it as a damaged file. Re-enter the password exactly — it's case- and whitespace-sensitive, and a trailing space pasted from elsewhere is a frequent cause.
CRC mismatch on one or more entries
CRC failureThe named entry's recomputed CRC32 differs from the stored value — real corruption or tampering. This is the tool succeeding, not failing. Re-download the source; if only some entries fail, corrupted-zip-repair rebuilds a ZIP from the recoverable ones.
Trailing entries report 'missing'
Truncated — entries failEarly entries pass but a contiguous block at the end reports missing: the file was almost certainly cut off mid-transfer. The central directory (at the end) parsed, but the data for those entries was never written. Re-fetch a complete copy.
File over the size limit
Rejected — tier limitFree rejects inputs over 50 MB up front, before any decompression. Pro: 500 MB. Pro-Media/Developer: 2 GB. If you can't upgrade, split the archive into smaller parts with archive-splitter and verify each part.
Too many entries (entry-count cap)
Rejected — tier limitThe per-archive entry limit is separate from file size: Free 500, Pro 50,000, Pro-Media/Developer 500,000. A small ZIP full of tiny files can hit this before the size cap. Upgrade or split the archive.
Page stalls with no error
Browser interferenceA stuck processing state with no error usually means a browser extension is interfering with the WebAssembly worker channels, or a stale cached build is loaded. Retry in an incognito window with extensions disabled and hard-refresh (Ctrl+Shift+R).
Want tamper detection, not corruption
CRC32 insufficient — use SHA-256CRC32 catches accidental corruption but is forgeable, so a passed verdict isn't tamper-proof. For tamper detection compute a SHA-256 with checksum-generator and compare manifests. The integrity tester is the wrong tool for an authenticity question.
Empty or all-folders ZIP reports zero entries
By designDirectory entries carry no data and are skipped, so a ZIP that's only empty folders verifies zero file entries. That's expected, not an error — there are no file CRC32s to check. Add files, or verify a different archive.
Frequently asked questions
Why do I get 'Not a valid ZIP archive' on my .7z / .rar / .tar.gz?
Because the tester verifies ZIP CRC32 by reading the ZIP central directory, and those formats don't have one. It's the most common surprise and it's by design — the tool won't guess at a different checksum scheme. Identify your file's true format with auto-format-detector; for 7z use 7z t, for .tar.gz use gzip -t or a SHA-256.
The report shows an error and no entries — is my file corrupt?
Probably not — that shape (error + empty entries) is what an encrypted ZIP returns when the password is missing or wrong. Genuine corruption shows up as per-entry CRC mismatch / missing results, not as a top-level error. Enter the correct password and re-run before assuming corruption.
Why does an entry fail with 'CRC mismatch'?
That entry's actual bytes don't match the CRC32 stored when the ZIP was created — it's truncated, bit-rotted, or altered. This is the tool working correctly. Re-download the source archive; if only some entries fail, salvage the good ones with corrupted-zip-repair.
What does 'missing' mean on an entry?
The entry is listed in the central directory but the decompressor produced no data for it — typically a truncated archive whose tail was never written. A contiguous run of missing entries at the end is a strong truncation signal. Re-fetch a complete copy of the file.
Why was my file rejected before it even processed?
It exceeded a tier limit. Free caps at 50 MB and 500 entries; the check runs up front, so oversized or entry-heavy ZIPs never start. Note the entry-count cap is separate from size — a small ZIP with many files can trip it. Pro raises both (500 MB / 50,000), Pro-Media/Developer to 2 GB / 500,000.
It's stuck on processing with no result. What now?
First hard-refresh (Ctrl+Shift+R) to drop a stale cached build. Then try an incognito/private window with extensions disabled — extensions that touch page or worker messages can stall the WebAssembly workers. If it works in incognito, an extension was the cause.
The whole archive 'opened fine' elsewhere but fails here — why?
Opening a ZIP only reads its directory; most tools don't recompute every entry's CRC32 until you extract that specific entry. This tester decompresses and re-checksums every entry up front, so it catches a damaged file that a casual 'open' missed. The failure is real — verify by extracting the named entry.
Can I fix a ZIP that fails the test here?
The integrity tester is read-only — it reports, it never modifies. To rebuild a usable ZIP from the recoverable entries of a damaged one, use corrupted-zip-repair. If the cause is a truncated download, re-fetching the complete file is the real fix.
Does a wrong password ever look like corruption?
No — a wrong or missing password produces a decryption-failure report, distinct from per-entry CRC mismatches. Because the CRC32 is stored over decrypted plaintext, it can only be evaluated once decryption succeeds, so the two failure modes never overlap. Re-check the password (it's case- and whitespace-sensitive).
Is my file uploaded when I troubleshoot here?
No. The tester runs as WebAssembly in your browser tab; the file is read from disk and never sent to a server. There's no server-side path, so even a failing archive stays on your machine. You can confirm with DevTools → Network during a run — no outbound request carries your data.
I need to know if a file was tampered with, not just corrupted — does this help?
Not directly. CRC32 detects accidental corruption but is forgeable, so a passed here doesn't prove authenticity. For tamper detection, compute a SHA-256 with checksum-generator and compare against a trusted manifest. Use the integrity tester for corruption, SHA-256 for tampering.
Which browsers does it work in?
Any current browser with WebAssembly support — Chrome, Edge, Firefox, Safari, Brave, Opera, on desktop and mobile. Very large archives may exceed mobile device memory; if a big ZIP stalls on a phone, retry on desktop. Stale-cache and extension issues are the only browser-side gotchas, both fixed by incognito + hard refresh.
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.