How to verify a downloaded artifact with SHA-256, signatures, or SRI
Choose the right verification method for a downloaded artifact by comparing local checksums, public signatures, and browser-side integrity checks.
Tip
Run the workflow once with a disposable value, then do a decrypt or restore check before you share anything real.
Downloaded-artifact verification can mean three slightly different things. You may want to compare bytes against a published digest, verify that a trusted signer approved the artifact, or tell the browser to enforce integrity for a fetched asset.
The right method depends on who is verifying and how the trust is distributed.
Summary
Definition: SHA-256 comparison checks byte equality against a known digest, digital signatures verify origin and integrity using public keys, and SRI lets browsers enforce integrity for fetched subresources.
Why it matters: Different distribution channels and trust models need different verification mechanisms.
Pitfall: A checksum published on the same page as the download is not the same trust story as a detached signature or browser-enforced SRI.
Checksums are a comparison tool first
A SHA-256 checksum is excellent for confirming that the file you have matches the file whose digest you trust. The catch is trust distribution. If the checksum comes from the same compromised channel as the file, the comparison may not tell you what you hoped it would. The digest is still useful; the publication story matters.
Signatures change the trust model
A signature lets verifiers confirm origin and integrity using a public key they trust separately from the artifact delivery path. That is why signatures are stronger when broad distribution or mirror infrastructure is involved. SRI solves a related but narrower browser problem: a page can pin the expected digest of a fetched script or stylesheet.
- Checksum: good for byte comparison when the digest itself is trusted.
- Signature: better when trust should be separable from the download channel.
- SRI: browser-enforced integrity for fetched subresources.
Use the right verification layer for the right audience
A human or release engineer may verify a downloaded archive with a checksum or signature. A browser verifies an included asset with SRI. The methods overlap conceptually, but the operational audience is different. Good documentation should say that plainly.
Quick example
Use this when you need a simple decision rule for a release download or a CDN asset.
What to notice: The verification method should match the distribution channel and the verifier doing the checking.
Downloaded archive for humans -> checksum or signature
Third-party JS/CSS in a web page -> SRI
Practical check
- Decide whether you need byte comparison, signer verification, or browser enforcement.
- Trust the verification material through a channel appropriate to the risk.
- Do not assume a digest and a signature solve the same distribution problem.
FAQ
Is SHA-256 enough for verifying software downloads?
It is useful, but the trust model depends on how you obtained the digest.
Does SRI replace release signatures?
No. SRI is for browser-fetched subresources, not general software distribution.
Developer workflow
Use this guide as a local handling check before a secret or protected file leaves your machine.
- Start with a harmless value that has the same shape as the real secret.
- Run the matching browser tool and copy the result into a scratch note.
- Run the decrypt, restore, or verification step before you share the real output.
1. disposable input
2. browser-only protect/encrypt step
3. decrypt or restore check
4. share only the intended artifact