How to per-file checksum generator in developer workflows
- Step 1Grab the artifact — Download the build artifact attached to the PR, CI run, or release. Drop it onto /archive-tools/checksum-generator — one archive at a time.
- Step 2Hash with SHA-256 — Leave the Algorithm dropdown on SHA-256 (or pick SHA-1 to match Git-style hashes, MD5 to match a legacy mirror). Click Process to get the manifest.
- Step 3Diff against the expected manifest — Compare the CSV against a checked-in
EXPECTED.sha256or the upstream.sha256sums. Any differing line is an artifact that changed — investigate before merging. - Step 4Verify in CI with the sums file — Commit the
.sha256sumsnext to the artifact. In CI, extract and runsha256sum -c <artifact>.sha256sums; fail the job on anyFAILEDline. - Step 5Use Archive Diff for content changes — For a PR that mutates archive contents, run Archive Diff on the before/after to get added/removed/changed/unchanged buckets — like
diff -ron extracted trees. - Step 6Make it reproducible with Timestamp Normaliser — Archive byte-identity also depends on entry timestamps. If you're chasing reproducible builds, normalise timestamps with Timestamp Normaliser (e.g. 1980-01-01) before hashing the container — though this tool already hashes file CONTENTS, which are timestamp-independent.
Developer scenarios and the right setting
The tool reads one archive and outputs a per-file manifest. Match the algorithm to whatever you're comparing against.
| Scenario | Algorithm | Output to use | Notes |
|---|---|---|---|
| Verify a release artifact | SHA-256 | .sha256sums → sha256sum -c | Default; tamper-evident |
| Match a published SHA-1 list | SHA-1 | .sha1sums | Legacy compatibility only |
| Reproduce a CDN .md5 | MD5 | .md5sums | Pure-JS MD5; slower on big entries |
| Diff two build outputs | SHA-256 | CSV (sort/compare) | Or use Archive Diff for buckets |
| Audit a vendored bundle | SHA-256 | CSV (per-file sizes + hashes) | Spot unexpected files |
Batch and automation reality
This tool is single-archive and UI-only. These are the right escalation paths for higher volume.
| Need | This tool | Use instead |
|---|---|---|
| One artifact, interactive | Yes — one drop | — |
| Compare two archives | Manually diff two CSVs | Archive Diff |
| Many archives at once | Not supported (single file) | Batch Compression Report |
| Scripted CI verification | No API yet | sha256sum -c in the pipeline |
Cookbook
Five recipes a developer actually runs. Browser action plus the CI/shell counterpart where relevant.
Verify a release ZIP against a published manifest
Generate locally, then diff against the upstream .sha256sums.
Browser: drop release-1.2.0.zip → SHA-256 → download release-1.2.0.sha256sums $ diff <(sort release-1.2.0.sha256sums) <(sort upstream/release-1.2.0.sha256sums) (no output = match)
Gate a CI job on integrity
Commit the sums file; verify in the pipeline.
# ci.yml step
- run: |
unzip -q artifact.zip -d out && cd out
sha256sum -c ../artifact.sha256sumsAudit a vendored dependency bundle
The CSV exposes every file and its size — easy to spot a surprise binary.
Input: vendor.tar.gz vendor-sha256.csv: name,size,sha256 node_modules/leftpad/index.js,612,2c26b46b...266e7ae node_modules/leftpad/postinstall.sh,8841,9f86d081...0f00a08 ← unexpected script?
Compare two build outputs file-by-file
Hash both, then diff the CSVs to find changed entries.
build-a-sha256.csv vs build-b-sha256.csv only in B: dist/chunk.4f2a.js (new hash) changed: dist/main.js (hash differs) identical: dist/vendor.js, dist/style.css
Match a Git-blob-style SHA-1
Switch to SHA-1 when reconciling with tools that report 160-bit hashes.
Browser: Algorithm = SHA-1 → Process vendor-sha1.csv: name,size,sha1 LICENSE,1071,a0b65939670bc2c010f4d5d6a0b3e4e4590fb92b
Edge cases and what actually happens
Looking for an API to call from CI
Not availableThis tool has no programmatic API yet — it's a browser page. For pipelines, run sha256sum -c directly; use the tool for interactive review and ad-hoc verification.
Hashes match but the archive bytes differ
ExpectedThis tool hashes file CONTENTS, which are independent of entry timestamps and compression level. Two archives can have identical per-file hashes yet different container bytes — normalise timestamps with Timestamp Normaliser if you need byte-identical containers.
Need to hash hundreds of artifacts
Single-file toolThe Checksum Generator processes one archive per run. For many archives, use Batch Compression Report for aggregate analysis, or script sha256sum in CI.
Artifact is an encrypted ZIP
SupportedEnter the password so zip.js decrypts each entry before hashing. The manifest reflects the decrypted contents.
Artifact is an encrypted 7z/RAR
Unsupportedlibarchive WASM can't take a password in-browser. Decrypt locally or repackage as an encrypted ZIP via Encrypted ZIP Creator first.
Free-tier artifact has 500+ files
Tier limitFree caps at 500 entries per archive. Most release bundles fit; large monorepo artifacts may need Pro (50,000 entries).
Mislabeled artifact extension
DetectedFormat is detected from magic bytes, so a .zip that's really a .tar.gz still reads correctly. Confirm a stubborn case with Auto Format Detector.
MD5 chosen for a large artifact
SlowerMD5 runs in pure JavaScript (no Web Crypto MD5), so it's slower than SHA-256 on big entries. Use it only to match an existing MD5 manifest.
Empty or directory-only archive
Empty manifestDirectory entries are skipped and only files are hashed, so an archive with no file entries yields a header-only CSV and a Files count of 0.
Frequently asked questions
Is there a CLI or API equivalent?
Not for this tool — it's UI-only today. The local equivalents are sha256sum (coreutils), openssl dgst, or PowerShell Get-FileHash. The tool's .sha256sums output interoperates with all of them.
How do I verify a manifest in CI?
Commit the .sha256sums alongside the artifact, extract it in the pipeline, and run sha256sum -c <artifact>.sha256sums. Fail the job on any FAILED line.
Does the output work with my CI's format expectations?
The sums file is plain GNU coreutils format and the CSV is plain RFC 4180 CSV — no JAD-specific wrapper. Both drop into existing steps.
How do I make verification reproducible?
Per-file hashes are already reproducible because they're over file contents, independent of timestamps. If you need the whole container to be byte-identical, normalise entry timestamps with Timestamp Normaliser first.
Can I script bulk runs?
Not through this tool — it's one archive per run with no API. For many archives, use Batch Compression Report or script sha256sum directly.
Which algorithm should I pick for release verification?
SHA-256 (the default). Use SHA-1 only to reconcile with Git-style hashes and MD5 only to match legacy mirror manifests.
Can I review an artifact without checking out the branch?
Yes — download the artifact attached to the PR or CI run and drop it in. You get a per-file manifest without cloning, building, or installing anything.
How is this different from Archive Diff?
This tool produces per-file hashes of one archive. Archive Diff compares two archives directly by name and CRC32 into added/removed/changed/unchanged buckets — better when you specifically want a before/after.
Does it read tar.gz and 7z artifacts?
Yes — ZIP/TAR/GZ via fflate, and 7z/RAR/BZ2/XZ/ISO via libarchive WASM. It reads these formats but does not write them.
What's the file-size and entry ceiling?
Free: 50 MB / 500 entries. Pro: 500 MB / 50,000 entries. Pro-Media and Developer: 2 GB / 500,000 entries, one archive per run.
Are the hashes identical to what sha256sum produces?
Yes, byte-for-byte, in lowercase hex. You can generate in the browser and verify on a server (or the reverse).
Will it tell me which file changed between builds?
Compare the two CSVs line-by-line — differing hashes pinpoint changed entries. For a ready-made diff, use Archive Diff.
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.