How to archive integrity tester online for free
- Step 1Open the tool — Visit /archive-tools/archive-integrity-tester. No account is needed for the free tier. The page loads the fflate and zip.js WASM bundles into your tab — after that it works offline.
- Step 2Confirm the input is a ZIP — This tool verifies ZIP entries against their central-directory CRC32. If your file is a
.7z,.rar,.tar, or.tar.gz, identify it first with auto-format-detector — dropping a non-ZIP here returnsNot a valid ZIP archive. - Step 3Drop the ZIP onto the dropzone — Select one archive (this is a single-file tool — no folder or batch input). The tool checks it against your tier's size and entry-count limit before any decompression starts: Free is 50 MB / 500 entries.
- Step 4Add a password if the ZIP is encrypted — If entries are AES-256 or ZipCrypto encrypted, type the password in the password field. Decryption runs through zip.js; the CRC32 is stored over the plaintext, so an entry that decrypts cleanly but mismatches is genuinely corrupt, while a wrong password surfaces as a decryption error.
- Step 5Run the test — Click Process. fflate decompresses each entry, recomputes its CRC32, and compares it to the value in the central directory. The summary shows Total, Passed, and Failed counts.
- Step 6Read or download the report — The result is a JSON file named
<archive>-integrity.jsoncontainingtotalEntries,passed,failed, and aresultsarray where each entry hasname,storedCrc32(8-hex),passed, and anerrorstring on failure (CRC mismatch: computed …ormissing). Download it for your records or pipe it into a verification step.
What the tool reads vs. what it reports
The Archive Integrity Tester parses the ZIP central directory directly and recomputes CRC32 per entry. The only user control is the password field.
| Aspect | Behaviour | Detail |
|---|---|---|
| Input formats verified | ZIP only (incl. AES-256 / ZipCrypto encrypted ZIPs) | CRC32 is read from the ZIP central directory; non-ZIP inputs have no such directory and return Not a valid ZIP archive |
| Engines | fflate (plaintext decompress + CRC32), @zip.js/zip.js (encrypted entries) | If any central-directory entry has the encryption flag set, the whole archive routes through zip.js using your password |
| Only option | password (text, hidden) — optional | Required only for encrypted ZIPs; ignored for plaintext archives. No checksum-algorithm, format, or batch options exist on this tool |
| Per-entry verdict | passed: true/false with the stored CRC32 in hex | A failure carries CRC mismatch: computed <hex> or missing when an entry is in the directory but cannot be decompressed |
| Output | JSON report <stem>-integrity.json | { totalEntries, passed, failed, results: [{ name, storedCrc32, passed, error? }] } |
Tier limits for the archive family
Limits are checked before processing. The per-archive entry-count limit matters as much as file size for ZIPs full of small files.
| Tier | Max file size | Max entries per archive | Files per 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 |
CRC32 verdicts and what they mean
How to read each per-entry outcome in the report.
| Verdict / error | What happened | Next step |
|---|---|---|
passed: true | Recomputed CRC32 equals the stored value — the entry's bytes are intact | No action — the entry extracts correctly |
CRC mismatch: computed <hex> | The entry decompressed but its bytes differ from what the CRC32 promised — corruption or tampering | Re-download or restore that entry; try corrupted-zip-repair to salvage the rest |
missing | The entry is listed in the central directory but the decompressor produced no data for it (often a truncated archive) | The archive is likely truncated — fetch a complete copy |
Decompression failed (report error) | The whole archive could not be opened — wrong password on an encrypted ZIP, or a structurally broken file | Check the password, or detect the real format with auto-format-detector |
Cookbook
Real reports from real ZIPs. The JSON shown is the actual shape the tool downloads — filenames and hashes anonymised.
A clean ZIP — every entry passes
The happy path. A 312-entry release ZIP downloaded over a flaky connection; the tester confirms every CRC32 matches, so the download was complete and intact.
Input: release-v2.4.0.zip (312 files, 41 MB)
Report (release-v2.4.0-integrity.json):
{
"totalEntries": 312,
"passed": 312,
"failed": 0,
"results": [
{ "name": "bin/app", "storedCrc32": "a1b2c3d4", "passed": true },
{ "name": "lib/core.so", "storedCrc32": "9f8e7d6c", "passed": true }
/* … 310 more, all passed: true */
]
}
Summary panel: Total 312 · Passed 312 · Failed 0One corrupt entry inside an otherwise-openable ZIP
The archive opens in a file manager and 999 of 1,000 entries extract — but one image is silently damaged. Extraction tools won't tell you which one; the CRC32 tester names it.
Input: photo-backup.zip (1,000 files)
Report:
{
"totalEntries": 1000,
"passed": 999,
"failed": 1,
"results": [
{ "name": "2026/IMG_0421.jpg",
"storedCrc32": "3c5a1f88",
"passed": false,
"error": "CRC mismatch: computed 3c5a0f88" }
]
}
Action: re-copy 2026/IMG_0421.jpg from source; the rest is fine.Truncated download — entries report as missing
A 500 MB ZIP cut off at 480 MB. The central directory at the end of the file may still parse, but the trailing entries can't be decompressed, so they come back missing rather than mismatched.
Input: dataset.zip (declared 1,204 entries; transfer interrupted)
Report:
{
"totalEntries": 1204,
"passed": 1180,
"failed": 24,
"results": [
{ "name": "part-1198.bin", "storedCrc32": "00000000",
"passed": false, "error": "missing" }
/* …23 more trailing entries all 'missing' */
]
}
A cluster of trailing 'missing' entries = truncated archive.Encrypted ZIP — password supplied
An AES-256 encrypted backup. Without a password the tester reports a decryption error; with the correct password each entry is decrypted by zip.js and its plaintext CRC32 is verified.
Input: confidential-backup.zip (AES-256, 48 entries)
Option: password = ••••••••
Report:
{
"totalEntries": 48,
"passed": 48,
"failed": 0,
"results": [ /* all passed: true */ ]
}
Wrong/blank password instead yields:
{ "error": "Archive contains encrypted entries (e.g. \"db.sql\").
Provide a password to extract.", "entries": [] }Wrong format dropped in — fast, clear rejection
A user renames a 7z to .zip and drops it in. There is no ZIP central directory to read, so the tool stops immediately instead of guessing.
Input: archive.zip (actually a .7z, magic bytes 37 7A BC AF 27 1C)
Result: Error — "Not a valid ZIP archive."
Fix: run /archive-tools/auto-format-detector to confirm the real
format. This tool verifies ZIP CRC32 only; 7z/rar/tar are
not parsed for per-entry checksums here.Edge cases and what actually happens
Non-ZIP file (7z, rar, tar, tar.gz) dropped in
Rejected — not a ZIPThe tester parses the ZIP central directory; 7z, rar, tar, and gzip carry no such structure, so the entry list is empty and the tool throws Not a valid ZIP archive. This is by design — it does not silently fall back to a different checksum. Identify the real format with auto-format-detector first.
Encrypted ZIP with no password
Decryption failedIf any central-directory entry has the encryption flag set, the archive routes through zip.js. With no password the report comes back as { error: "Archive contains encrypted entries … Provide a password to extract.", entries: [] }. Supply the password to proceed.
Wrong password on an encrypted ZIP
Decryption failedzip.js cannot decrypt the entries, so the tester returns a decryption-failure report rather than a CRC mismatch. The distinction matters: a wrong password is a key problem, not a corruption problem. Re-enter the password exactly (it is case- and whitespace-sensitive).
CRC32 matches but the entry is malicious
Not tamper-proof — fails as evidenceCRC32 is an error-detection code, not a cryptographic hash — an attacker can craft a modified file that still hashes to the original CRC32. A passed verdict means 'not accidentally corrupted', not 'not tampered with'. For tamper detection compute a SHA-256 over the source files with checksum-generator.
Trailing cluster of 'missing' entries
Truncated — entries failWhen the early entries pass but a contiguous block of trailing entries reports missing, the archive was almost certainly cut off mid-transfer. The central directory (stored at the end) parsed, but the data for those entries was never written. Re-download a complete copy.
Archive over the tier limit
Rejected — tier limitFree caps inputs at 50 MB and 500 entries; the check runs before decompression, so an oversized ZIP is rejected up front with no processing. A ZIP of many tiny files can hit the 500-entry cap well before the size cap — Pro raises both to 500 MB / 50,000 entries.
Folders / directory entries in the ZIP
By designDirectory entries (names ending in /) carry no data and no meaningful CRC32, so they are skipped — totalEntries counts files only. A ZIP that is all empty folders therefore reports zero entries verified, which is expected.
Zero-byte files inside the ZIP
PassedAn empty file has a well-defined CRC32 (00000000). The tester recomputes it and it matches, so zero-byte entries pass normally rather than being flagged. This is the correct outcome — an intentionally empty file is not corrupt.
Self-extracting ZIP (.exe with a ZIP appended)
SupportedMany SFX archives are an executable stub followed by a normal ZIP. Because the tester locates the central directory by scanning from the end of the file, these usually verify correctly. If the stub confuses the scan you'll get Not a valid ZIP archive — extract the inner ZIP first.
ZIP64 archive with very large or very many entries
Check entry countZIP64 lifts the classic 65,535-entry and 4 GB-per-entry ceilings. The tester reads the central directory as present, but your tier's entry-count and size caps still apply — a 600,000-entry ZIP exceeds even Developer's 500,000-entry limit and is rejected before processing.
Frequently asked questions
What does a CRC32 failure actually mean?
The bytes that came out of decompression do not match the checksum the archive stored when it was created. In practice that means the entry was truncated in transfer, the storage media has bit rot, or the file was altered after zipping. CRC32 is an error-detection code, not a security hash — so treat a failure as 'this entry is damaged', and for deliberate-tampering questions compute a SHA-256 over the source with checksum-generator.
Can I test password-protected ZIPs?
Yes. Enter the password in the password field and the archive is decrypted by zip.js (AES-256 and legacy ZipCrypto). The CRC32 is stored over the plaintext, so once an entry decrypts it is verified exactly like an unencrypted one. A wrong or missing password surfaces as a decryption error, not a CRC mismatch.
Why does it say 'Not a valid ZIP archive' for my .tar.gz / .7z / .rar?
This tool verifies per-entry CRC32 from the ZIP central directory, and those formats don't have one. TAR carries only a header checksum (no per-file CRC); gzip has a single trailing CRC32 over the whole stream; 7z stores CRC32 but in its own structure that this tool doesn't parse. Confirm your format with auto-format-detector.
Does my archive get uploaded?
No. fflate and zip.js run as WebAssembly inside your browser tab; the file is read from disk via the File API and never sent to a server. Open DevTools → Network during a run and you'll see zero outbound requests carrying your data. There is no server-side processing path for archive tools.
What's the largest archive I can test?
Free: 50 MB and up to 500 entries. Pro: 500 MB / 50,000 entries. Pro-Media and Developer: 2 GB / 500,000 entries. The entry-count limit is separate from the size limit and is often the one you hit first on a ZIP packed with small files.
What format is the output?
A JSON file named <archive>-integrity.json with totalEntries, passed, failed, and a results array. Each result has name, storedCrc32 (8-character hex), passed, and — on failure — an error string (CRC mismatch: computed <hex> or missing). It's designed to be read by a human or piped through jq.
Can I test several archives at once?
Not on this tool — it takes a single ZIP per run (Free is 1 file; Pro allows 20 files on tools that accept multiples, but the integrity tester itself processes one archive at a time). For verifying many archives in one pass, see the batch tools in the analysis family such as batch-compression-report.
An entry says 'missing' — what's that?
The entry is listed in the central directory but the decompressor produced no data for it. The usual cause is a truncated archive: the directory at the end of the file parsed, but the entry's compressed data was never written. A run of trailing missing entries is a strong signal the download was cut off.
Does CRC32 prove my file wasn't tampered with?
No. CRC32 detects accidental corruption reliably but is trivial to forge deliberately — two different files can share a CRC32 by design. For integrity against tampering use a cryptographic hash: generate SHA-256 over the source files with checksum-generator and compare manifests.
Can I repair a ZIP that fails the test?
This tool only reports — it never modifies your archive. If a few entries fail but you want to salvage the good ones, try corrupted-zip-repair, which rebuilds a ZIP from the recoverable entries. If the failure is a truncated download, re-fetching the file is the real fix.
Is there an API or CLI version?
No public HTTP API — archive tools are browser-only by design (apiAvailable: false). On Pro and above the same logic can run through the @jadapps/runner in a headless browser for automation, but there is no server endpoint that accepts your archive. For local CLI equivalents, unzip -t and 7z t perform comparable CRC checks.
Why test integrity if the ZIP already opened fine?
Opening a ZIP only reads the central directory; most tools don't recompute every entry's checksum until you actually extract that entry, and some won't warn even then. A ZIP can list 1,000 files, open instantly, and still hide one bit-rotted entry. This tool decompresses and re-checksums every entry up front so a single bad file can't surprise you later.
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.