Online Tool Store
· 4 min read
How to Verify a Download Against Its Checksum
Heshan Fernando
Co-founder & COO
A project publishes an installer and a line of hexadecimal beside it. Most people download the installer and ignore the hexadecimal, partly because checking it seems like a job for a terminal.
It takes about ten seconds, and it catches two genuinely different problems.
What a hash comparison proves
A cryptographic hash maps a file to a fixed-length value. Change one byte and the value changes completely — there is no partial match, and no way to predict the effect of a change.
So a matching hash tells you the file you have is byte-identical to the file whose hash was published. That rules out:
Corruption in transit. A truncated download, a flipped bit, an interrupted transfer. Rare on modern connections and not impossible, particularly on large files over unreliable links.
The wrong file. Downloading version 2.3 when you meant 2.4, or a mirror serving something stale.
Tampering by a third party who intercepted the download but could not alter the page publishing the hash.
What it does not prove
The limitation matters, and it is regularly overstated in both directions.
If an attacker compromised the site, they could replace both the file and the published hash. The two would match perfectly and the file would be malicious. A checksum on the same page as the download only defends against interference between the two.
That gap is what signatures close. A signed release is verified against the project’s public key, held independently of the website, so replacing the file requires the private key rather than write access to a web server. Where a project publishes signatures, they are strictly better than a checksum.
Checksums remain worth checking because they are trivial and catch the common cases. They are not a strong integrity guarantee against a determined attacker.
| Threat | Checksum catches? |
|---|---|
| Corrupted download | Yes |
| Wrong version | Yes |
| Man-in-the-middle swap | Yes, if the hash page was untouched |
| Compromised publisher | No — signatures needed |
Which algorithm
SHA-256 is the current default and what most projects publish.
SHA-1 and MD5 both have practical collision attacks — it is feasible to construct two different files with the same hash. They still detect accidental corruption perfectly well, and should not be relied on against a deliberate attacker. Where a project publishes only MD5, that is a mild signal about how current their release process is.
Comparing hashes should be a whole-string comparison. Checking the first and last few characters is a habit that defeats the point, since a constructed collision would match exactly there.
Where the checksum is published matters
A hash is only as trustworthy as its source, and the source is frequently the weak link.
On the same page as the download — protects against corruption and interception in transit, and not against a compromised site.
On a different host — a project’s repository when the file is on a CDN, for instance. An attacker now needs both.
In a signed release file, verified against a key you hold independently. This is the strong version, and it is what package managers do automatically.
Quoted by a third party — a distribution’s package index, a security advisory — which is useful corroboration.
The practical rule: a checksum beside the download is worth checking and is not evidence of anything about the publisher.
Common mistakes to avoid
- Comparing the first six and last six characters by eye instead of the whole string.
- Treating a matching hash as proof the software is safe. It proves the bytes match what was published, not that what was published is trustworthy.
- Uploading a sensitive file to a hosting service to hash it.
- Using an MD5 checksum for security purposes rather than corruption detection.
- Checking the hash after installing rather than before.
How to do it with File Hash Comparison Tool
The File Hash Comparison Tool hashes the file in your browser.
- Select the file — it is hashed locally and never uploaded, so file size is limited by memory rather than by an upload cap.
- Paste the checksum the publisher provided, using the same algorithm.
- Compare the full strings rather than the ends.
- Prefer a signature where the project publishes one; it defends against a case the checksum cannot.
Other security tools are in the tools directory.
Frequently asked questions
Does a matching hash mean the file is safe?
It means the file is byte-identical to what was published. If the publisher’s site was compromised and both the file and the checksum were replaced, they will still match — which is what signature verification exists to catch.
Which algorithm should I use?
SHA-256. MD5 and SHA-1 have practical collision attacks and should not be relied on against a deliberate attacker, though they still catch accidental corruption.
Is my file uploaded?
No. Hashing runs in the browser, so a large or confidential file never leaves your machine.
Final thought
Compare the whole string, and prefer a signature where one exists. A checksum is a ten-second check against the ordinary failures, not a guarantee against a determined one.