How to integrity tester for security & compliance
- Step 1Capture a baseline manifest first — Before handling, run the source files (or the archive) through checksum-generator to record a SHA-256 manifest. CRC32 catches corruption; SHA-256 is what stands up as tamper evidence later.
- Step 2Stage the ZIP locally only — Pull the archive from your evidence store, vault, or pipeline to the analyst's machine. The tester reads it via the File API — confirm with DevTools → Network that no request carries the data.
- Step 3Run the integrity test — Open /archive-tools/archive-integrity-tester and drop the ZIP. For an encrypted evidence archive, enter the password so AES-256 / ZipCrypto entries are decrypted and their plaintext CRC32 verified.
- Step 4Record the report as an artifact — Download
<archive>-integrity.json(totalEntries,passed,failed, per-entryresults). Attach it to the case file or pipeline record as the corruption-check evidence for that handling step. - Step 5Re-hash to detect tampering — After handling, regenerate the SHA-256 manifest and compare to the baseline. A CRC32 pass plus matching SHA-256 manifests is the defensible 'intact and unaltered' claim; CRC32 alone only covers accidental corruption.
- Step 6Escalate failures correctly — A
CRC mismatchormissingentry means corruption or truncation — re-pull from source and investigate the transfer. A SHA-256 change with CRC32 still passing is the alarming case: it suggests deliberate alteration crafted to preserve the CRC32.
CRC32 vs SHA-256 for compliance
Which check answers which compliance question. The integrity tester covers the first column; pair it with checksum-generator for the second.
| Question | CRC32 (this tool) | SHA-256 (checksum-generator) |
|---|---|---|
| Was the archive accidentally corrupted or truncated? | Yes — per-entry verdict | Yes (whole-file) |
| Can the result be forged by an attacker? | Yes — CRC32 is not collision-resistant | No — cryptographically strong |
| Suitable as tamper evidence / chain-of-custody? | No — corruption check only | Yes — standard for integrity attestation |
| Granularity | Per entry inside the ZIP | Per file / per archive |
| Needs the file uploaded? | No (browser-local) | No (browser-local) |
Tier limits for compliance volumes
Pick a tier by the size and entry count of your evidence bundles. Limits are enforced before any decompression.
| Tier | Max file size | Max entries per archive | Typical fit |
|---|---|---|---|
| Free | 50 MB | 500 | Ad-hoc single-artifact checks |
| Pro | 500 MB | 50,000 | Most case-evidence and release bundles |
| Pro-Media | 2 GB | 500,000 | Large media/forensic image bundles |
| Developer | 2 GB | 500,000 | Automation via the headless runner |
Cookbook
Compliance-shaped workflows. Evidence names and hashes are anonymised; the report shapes are exactly what the tool produces.
Chain-of-custody: CRC32 + SHA-256 before/after
The defensible pattern. CRC32 confirms no entry was corrupted in handling; SHA-256 manifests before and after confirm nothing was altered.
1. Baseline (checksum-generator): case-2026-114.zip
SHA-256: 8f3a...e21 (recorded in case file)
2. Integrity test (this tool):
{ "totalEntries": 47, "passed": 47, "failed": 0 }
→ no entry corrupted during transfer
3. After handling, re-hash (checksum-generator):
SHA-256: 8f3a...e21 → MATCHES baseline
Verdict: intact (CRC32) AND unaltered (SHA-256).Vendor supply-chain artifact arrives corrupt
A third-party ZIP delivered over an unreliable channel. The tester catches a single damaged binary before it's deployed.
Input: vendor-sdk-3.2.zip (delivered by partner)
Report:
{
"totalEntries": 214,
"passed": 213,
"failed": 1,
"results": [
{ "name": "lib/native/x64/core.dll",
"storedCrc32": "7b2c9a01",
"passed": false,
"error": "CRC mismatch: computed 7b2c9a05" } ]
}
Action: reject the delivery; request a re-send and re-verify.Encrypted evidence ZIP verified in place
AES-256 evidence under retention. The analyst verifies it without decrypting to disk anywhere persistent — zip.js decrypts in the tab only.
Input: incident-evidence.zip (AES-256)
Option: password = <case key>
Report:
{ "totalEntries": 88, "passed": 88, "failed": 0 }
No plaintext written to disk by JAD; verification happens
in memory in the browser tab and the report is the only
artifact produced.Backup restorability check before certification
Before signing off a retained backup as restorable, verify every entry rather than trusting that the ZIP 'opens'.
Input: nightly-backup-2026-06-12.zip (9,300 entries)
Report:
{
"totalEntries": 9300,
"passed": 9300,
"failed": 0
}
Certify: every entry decompresses and matches its CRC32.
(Free tier's 500-entry cap is too small here — Pro/Pro-Media
is required for 9,300 entries.)The tamper case CRC32 cannot catch
A reminder of the boundary: a file altered to preserve its CRC32 passes the integrity test but fails SHA-256. This is exactly why the two checks are paired.
Integrity test (CRC32):
{ "name": "report.pdf", "storedCrc32": "a4b1c2d3",
"passed": true } ← looks fine
SHA-256 (checksum-generator) vs baseline:
baseline: 11ff..a9
current: 62cd..07 ← DOES NOT MATCH
Verdict: tampered. CRC32 alone would have certified it clean.Edge cases and what actually happens
Relying on CRC32 as tamper evidence
Insufficient — use SHA-256CRC32 is an error-detection code, not a cryptographic hash, and is forgeable — a passed verdict proves only that the entry wasn't accidentally corrupted. For chain-of-custody and tamper detection you must pair it with a SHA-256 manifest from checksum-generator. Document this distinction in your audit notes.
Encrypted evidence ZIP, no password
Decryption failedAn AES-256 / ZipCrypto archive without a password returns a decryption-failure report (Archive contains encrypted entries … Provide a password to extract.) rather than a verdict. Supply the case key in the password field; decryption stays in the tab and no plaintext is persisted by JAD.
Evidence is not a ZIP (7z, tar.gz, forensic image)
Rejected — not a ZIPThe tester verifies ZIP CRC32 only. A .7z, .tar.gz, or disk image is rejected with Not a valid ZIP archive. Detect the real format with auto-format-detector; for whole-file assurance on any format compute a SHA-256 with checksum-generator.
Large evidence bundle exceeds Free limits
Rejected — tier limitForensic and backup bundles routinely exceed Free's 50 MB / 500 entries. The limit check runs before decompression, so an oversized ZIP is rejected up front. Use Pro (500 MB / 50,000 entries) or Pro-Media (2 GB / 500,000 entries) for real volumes.
Concurrent analysts on the same evidence set
By designEach browser tab is an independent instance with no shared server state, so multiple analysts can verify copies of the same archive simultaneously. Tier limits apply per session. There is no central store to coordinate around — and nothing uploaded to coordinate.
Regulated environment (HIPAA / PCI / FedRAMP boundary)
Boundary preservedBecause the archive is never transmitted, using the tool doesn't move data outside your controlled boundary — it's equivalent to running a local CLI in the browser. Still, confirm with your compliance team that local browser processing matches your data-handling policy and record the no-upload posture in the assessment.
Truncated retained backup
Truncated — entries failA backup cut off mid-write reports its trailing entries as missing even though the file opens. Certifying it as restorable on the strength of 'it opens' would be wrong — the integrity test surfaces the missing tail so you can re-take the backup before it's needed.
Report retention and reproducibility
SupportedThe JSON report is the artifact: store it with the case or pipeline record. Re-running the test on the same bytes yields the same results, so the verdict is reproducible. For unalterable evidence, hash the report itself with SHA-256 and record that hash too.
Frequently asked questions
Is the Integrity Tester enough for tamper detection?
Not on its own. CRC32 reliably catches accidental corruption and truncation but is forgeable, so a passed verdict is not proof a file wasn't deliberately altered. Pair it with a SHA-256 manifest from checksum-generator captured before and after handling — that combination is what stands up as tamper evidence.
Does sensitive evidence get uploaded anywhere?
No. fflate and zip.js run as WebAssembly in the analyst's browser tab; the archive is read from disk and never transmitted. There is no server-side processing path for archive tools, so the regulated boundary doesn't move when you use the tool. Verify with DevTools → Network during a run.
Can I verify an encrypted (AES-256) evidence ZIP?
Yes. Enter the password in the password field; zip.js decrypts the entries in the tab and the integrity tester verifies each one's plaintext CRC32. No plaintext is written to disk by JAD — the report is the only artifact produced. A wrong password yields a decryption error, not a false CRC pass.
What do I attach to a case file or audit?
Download <archive>-integrity.json — it contains totalEntries, passed, failed, and a per-entry results array with each stored CRC32. For chain-of-custody, attach this alongside the before/after SHA-256 manifests from checksum-generator.
How does this compare to enterprise integrity platforms?
JAD covers the speed-of-task, no-upload case for one-off and ad-hoc checks. Enterprise platforms add SSO, centralised audit logging, and managed storage. Many teams use both: JAD for the analyst's desk-side check, the platform for the system-of-record. The key JAD property is that nothing leaves the analyst's machine.
Why does it reject our 7z / tar.gz evidence?
The tester verifies ZIP CRC32 specifically — it parses the ZIP central directory, which 7z and tar.gz don't have, so they're rejected with Not a valid ZIP archive. Identify the format with auto-format-detector; for whole-file integrity on any format, compute a SHA-256 with checksum-generator.
Can several analysts use it at once?
Yes — each browser tab is an independent instance with no shared state. Free-tier limits apply per session; Pro and above lift them. There's no licence server or seat count to manage because there's no server component handling the files.
Does it work on a locked-down corporate laptop?
Yes. It runs entirely in the browser with no install and no admin rights — the most common reason compliance teams choose it over a CLI they can't install. As long as the browser supports WebAssembly (every current Chrome, Edge, Firefox, Safari does), it works.
Is the result reproducible for an auditor?
Yes. The same archive bytes always produce the same results, since the CRC32 of each entry is deterministic. Store the JSON report with the record; to make it self-attesting, hash the report itself with SHA-256 and note that hash in the case file.
How big an evidence archive can it handle?
Free: 50 MB / 500 entries. Pro: 500 MB / 50,000 entries. Pro-Media and Developer: 2 GB / 500,000 entries. Forensic and backup bundles usually need Pro or above; the per-archive entry-count limit is enforced separately from file size and is often the binding one.
Can we automate integrity checks across many archives?
There's no public API (apiAvailable: false), but on Pro and above the @jadapps/runner can drive the tool through a headless browser for automation while keeping the no-upload guarantee. For batch reporting across many archives, the analysis family's batch-compression-report processes multiple files in one pass.
What's the right escalation when an entry fails?
A CRC mismatch or missing entry means corruption or truncation — re-pull from source and investigate the transfer path. The serious case is a SHA-256 change while CRC32 still passes: that pattern suggests deliberate alteration engineered to preserve the CRC32, and should trigger your tamper-response procedure.
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.