How to per-file checksum generator for security & compliance
- Step 1Stage the evidence locally — Pull the archive from your evidence store, backup vault, or pipeline artifact onto the analyst's machine. The tool reads from disk via the File API — nothing transits a network.
- Step 2Open the Checksum Generator — Go to /archive-tools/checksum-generator. For evidence bundles over 50 MB, use Pro (500 MB) or higher so you don't have to split the archive.
- Step 3Keep SHA-256 selected — Leave the Algorithm dropdown on SHA-256 for tamper-evidence. Only switch to SHA-1 or MD5 when you must reproduce a legacy manifest a counterparty already published.
- Step 4Unlock encrypted bundles — If the evidence ZIP is AES-encrypted, enter the password so each entry is decrypted before hashing. Encrypted 7z/RAR can't be read in-browser — decrypt those locally first.
- Step 5Process and record the manifest — Click Process. Note the Files (entry count) chip and save both outputs: the CSV for your case record and the
.sha256sumsfor verification. Store them with the archive's acquisition metadata. - Step 6Re-run after any handling step to prove no change — After copying, transferring, or repackaging the archive, run the manifest again and compare. Identical hashes are your tamper-evident proof; any difference flags exactly which file changed.
Why SHA-256 for tamper detection
All three algorithms are available, but they serve different purposes. For integrity-vs-tamper decisions, the distinction matters.
| Algorithm | Detects accidental corruption | Detects deliberate tampering | Recommended for compliance |
|---|---|---|---|
| SHA-256 (default) | Yes | Yes — collision-resistant | Yes |
| SHA-1 | Yes | Weak — known collision attacks | Only for legacy match |
| MD5 | Yes | No — broken for collisions | Only for legacy match |
| CRC32 (not this tool) | Yes | No — trivially forgeable | No |
What stays local vs what's enforced
Browser-only execution means the regulated boundary doesn't move. Tier checks happen client-side before processing.
| Concern | Behaviour | Implication for compliance |
|---|---|---|
| Data location | Files read from disk; hashing in-browser; zero uploads | Evidence never leaves the analyst's machine |
| Network | No outbound request for input data (verify in DevTools) | Equivalent to running a local CLI |
| Encrypted ZIP | Decrypted in-memory with the supplied password | Hashes reflect cleartext contents; password is not stored or sent |
| Size / entry limits | Free 50 MB / 500 entries; Pro 500 MB / 50,000; paid up to 2 GB / 500,000 | Plan for the bundle size; split very large evidence sets |
Cookbook
Five chain-of-custody and release-integrity patterns. Each shows the manifest you keep and how it's later verified.
Manifest an evidence bundle at acquisition
Default SHA-256. Save the manifest alongside the acquisition log.
Input: case-2026-0142.zip (4 files) case-2026-0142-sha256.csv: name,size,sha256 disk-image.dd,1048576,2c624232cdd221771294dfbb310aca000a0df6ac8b66b696d90ef06fdefb64a3 memory.raw,524288,4b227777d4dd1fc61c6f884f48641d02b4d121d3fd328cb08b5531fcacdabf8a chain.log,2210,ef2d127de37b942baad06145e54b0c619a1f22327b2ebbcfbec78f5564afe39d
Verify after transfer to the analysis box
Same archive, copied across systems. Extract and check — every entry must report OK.
$ unzip case-2026-0142.zip $ sha256sum -c case-2026-0142.sha256sums disk-image.dd: OK memory.raw: OK chain.log: OK
Prove a release bundle is unchanged
Generate at build time, publish the .sha256sums, let downstream consumers verify.
Input: product-2.0.0-release.zip product-2.0.0-release.sha256sums (published): 9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca7 installer.msi 0263829989b6fd954f72baaf2fc64bc2e2f01d692d4de72986ea808f7e99813a signature.asc
Manifest an encrypted evidence ZIP
Enter the password; hashes are of the decrypted contents.
Input: sealed-evidence.zip (AES-256) Password: •••••••• sealed-evidence-sha256.csv: name,size,sha256 interview.mp4,30408704,7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730 transcript.pdf,118233,18ac3e7343f016890c510e93f935261169d9e3f565436429830faf0934f4f8e4
Spot a tampered file between two checkpoints
Re-running after handling reveals exactly which entry changed.
Checkpoint A (transcript.pdf): 18ac3e73...0934f4f8e4 Checkpoint B (transcript.pdf): a948904f...a192a447 ← CHANGED All other entries: identical → only transcript.pdf was altered
Edge cases and what actually happens
Auditor questions whether data was uploaded
By designOpen DevTools → Network and run a job — there are zero outbound requests for the file data. Processing is local WASM + Web Crypto, equivalent to a local CLI for data-handling-policy purposes.
Evidence ZIP is password-protected
SupportedEnter the password in the optional field; zip.js decrypts each entry before hashing. The password is used in-memory only — it is not stored or transmitted.
Encrypted 7z or RAR evidence
Unsupportedlibarchive WASM can't accept a password in-browser. Decrypt with 7-Zip/WinRAR on the analyst machine, or re-package as an encrypted ZIP via Encrypted ZIP Creator, then manifest the ZIP.
Need to detect tampering, not just corruption
Use SHA-256Keep the default. SHA-1 has known collisions and MD5 is broken for collisions; for a defensible tamper-evidence claim, SHA-256 is the appropriate choice.
Bundle exceeds 500 entries on free tier
Tier limitFree archives cap at 500 entries. Large evidence sets are a Pro use case (50,000 entries); upgrade or split with Archive Splitter and manifest each part.
Hash differs from a sealed manifest
InvestigateIf a re-run doesn't match the original manifest, a file changed between checkpoints. The CSV pinpoints the entry — compare its size and hash against the sealed record.
Just need to confirm the archive isn't corrupt
Different toolFor a quick integrity pass without a full manifest, use Archive Integrity Tester, which validates structure and per-entry CRC32.
Need signing / signature metadata, not hashes
Different toolHashes prove integrity but not authorship. To inspect an archive's embedded signing information, use Archive Signing Info.
Multiple analysts working in parallel
SupportedEach browser tab is an independent instance with no shared state. Free-tier limits apply per session; Pro removes the per-job size constraint.
Frequently asked questions
Is this suitable for tamper-evident manifests?
Yes. It produces per-file SHA-256 hashes plus a verifiable .sha256sums file. Because nothing is uploaded, it fits chain-of-custody workflows where evidence must stay on-machine.
How do I prove no data was uploaded?
Open DevTools → Network and watch a run. There are zero outbound requests for the file contents — extraction and hashing are local WASM/Web Crypto operations.
Why SHA-256 instead of CRC32 or MD5?
CRC32 only catches accidental corruption and is trivial to forge; MD5 and SHA-1 are broken for collisions. SHA-256 is collision-resistant, so a matching manifest is real tamper-evidence.
Can I manifest an encrypted evidence archive?
Encrypted ZIPs: yes — enter the password and each entry is decrypted before hashing. Encrypted 7z/RAR: no — decrypt locally first, since libarchive WASM can't take passwords in-browser.
Is the password stored or sent anywhere?
No. It is passed to zip.js in-memory to decrypt entries and is never transmitted or persisted — consistent with the no-upload architecture.
Will this satisfy HIPAA / PCI / FedRAMP data-handling rules?
Because nothing transits a network, using the tool is equivalent to a local CLI — the regulated boundary doesn't move. Confirm with your compliance team that local browser processing matches policy; most accept it.
How do auditors verify the manifest?
Extract the archive to matching relative paths and run sha256sum -c <archive>.sha256sums (or Get-FileHash on Windows). Any mismatched file is flagged immediately.
What's the largest evidence bundle I can process?
Free: 50 MB / 500 entries. Pro: 500 MB / 50,000 entries. Pro-Media and Developer: 2 GB / 500,000 entries. Split larger sets and manifest each part.
Does it hash the archive or the files inside?
The files inside. Each entry's decompressed contents are hashed, giving you a per-file manifest suitable for granular audit.
Can multiple analysts use it at once?
Yes — each tab is independent with no shared state. There's nothing to lock or contend over.
What about chain-of-custody before and after processing?
Generate a manifest at acquisition and again after each handling step. Identical hashes prove the bundle is unchanged; a difference identifies exactly which file moved.
Does it record who ran it or when?
No — it's a stateless utility that outputs hashes only. Pair the manifest with your own acquisition log or case-management metadata for the who/when/where.
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.