A checksum tells you the file you have matches a published value. A signature tells you a key holder vouched for the file. Neither is enough alone. A checksum on the same page as the download proves little, and a signature proves identity, not safety. Use both, from separate channels.
What a checksum proves
A checksum is a hash of the file. If your computed hash equals the published one, the bytes are identical to what the publisher hashed. That catches corrupted downloads and some tampering in transit.
It fails when the attacker controls the page. If someone replaces both the file and the hash on the same server, they match perfectly. A checksum is only as trustworthy as the channel that carries it.
What a signature proves
A digital signature binds the file to a private key. Verification checks that the file is unchanged since signing, and that the signing certificate or key chains to something you trust. On Windows, SignTool verification also considers whether the certificate was issued by a trusted authority and whether it has been revoked.
The weak point is the key. If the key is stolen, or the build was already compromised before signing, the signature still verifies. Signing proves who, not what the code does.
Side by side
- Checksum on the download page: detects accidents, weak against a compromised site.
- Checksum published elsewhere, such as a release announcement or a package manager index: stronger, because an attacker must compromise two places.
- Signature from a platform you trust, such as an OS code signing chain: strong for identity, no claim about safety.
- Signature plus transparency, such as a public log or reproducible build: stronger again, because others can notice a surprise.
A practical routine for users
- Download only from the official page, reached by typing the address or from a trusted link.
- Verify the platform signature when your OS provides tooling. Our guides cover Windows with SignTool and Android with apksigner.
- Compare the checksum against a value from a second channel.
- If the publisher identity is not the one you expected, stop.
A practical routine for publishers
Publish checksums in more than one place, sign every artifact, and write down how users should verify. Keep the verification steps on the download page, short and copyable. Document your signing identity, so users know what name to expect. See also what reproducible builds prove.
A worked example
Imagine a project page that lists an installer and a SHA-256 value beside it. An attacker who gets write access to the page swaps both. You download, hash, compare and feel reassured, and you have been fooled. Now imagine the same project also posts the hash in release notes and signs the installer with an identity you recognise. The attacker must now compromise three separate places, or steal the signing key. Each added channel raises the cost of the attack, which is the whole point.
Quick check
Is SHA-256 on the download page enough?
It catches corruption. It does not protect against someone who can edit the page and the file together.
If the signature is valid, can I skip the checksum?
The signature is the stronger check for identity. A second channel hash still helps when you doubt the signer's key or build.
Sources
Last reviewed: 19 October 2026.
