File Hash Verifier

This tool computes a file’s cryptographic hash in your browser using the Web Crypto API. The file is read locally — it never leaves your machine. Use it to verify a downloaded file against the hash the publisher posted.

Why hash verification exists

A binary downloaded from the internet may have been:

• Corrupted in transit — a flaky network, a bit error, a partial download. Most download tools handle TLS layer integrity, but file integrity at the byte level is separate.
• Replaced on the mirror — if the publisher’s primary download is offline and you fetched from a third-party mirror, did you get the same file?
• Tampered with — by a man-in-the-middle attack, a compromised mirror, or an attacker in control of the publisher’s CDN.

Hash verification turns “I have these bytes” into a checkable claim: compute the hash, compare to the publisher’s posted hash, and if they match, the bytes are exactly what the publisher signed.

How the verification works

1. Publisher releases file:        ubuntu-22.04.iso
2. Publisher computes:             sha256sum ubuntu-22.04.iso
                                    → 5e38b55d57d94ff029719342357325ed3bda38fa80054f9330dc789cd2d43931
3. Publisher posts the hash on their website (over HTTPS).
4. You download the file.
5. You compute:                    sha256sum ubuntu-22.04.iso
                                    → 5e38b55d57d94ff029719342357325ed3bda38fa80054f9330dc789cd2d43931
6. You compare. Match → bytes are correct.

Step 3 is critical. The hash itself must come from a trustworthy source — the publisher’s HTTPS site, signed metadata, an out-of-band notification. A hash on the same compromised page as a malicious download proves nothing; the attacker just rewrote both.

Algorithm choice

The tool above computes SHA-1, SHA-256, SHA-384 and SHA-512 (the algorithms the browser’s Web Crypto API provides). It does not compute MD5 for files; if a publisher only posts MD5, use md5sum / Get-FileHash -Algorithm MD5 locally.

Use whatever the publisher posted. If the publisher posted MD5, your only options are: (a) compute MD5 and trust the algorithm enough to detect corruption (it can do that), or (b) ask the publisher for a SHA-256 or use a different distribution channel.

What hashes prove and don’t prove

Match → identical bytes. If your computed hash matches the publisher’s, the file you have is bit-for-bit identical to the file the publisher hashed. No tampering, no corruption.

Mismatch → not identical bytes. Could be corruption (download error, partial download). Could be tampering. The hash alone doesn’t tell you which.

Match doesn’t prove the publisher is trustworthy. It proves you got the bytes the publisher intended to deliver. If the publisher itself was compromised and is signing malicious binaries, the hash matches and the file is still bad. Hash verification is one layer; package signing (GPG, code signing certificates) is the layer above.

Match doesn’t prove the file is what you think it is. A correct hash for bad-software.exe doesn’t help if you wanted good-software.exe. Verify the publisher and filename in addition to the hash.

Common file-hash patterns in the wild

• .sha256 files alongside downloads. A small text file containing one or more <hash> <filename> lines. The standard form for Linux distributions.
• SHA256SUMS master file. A single file listing hashes for everything in a release. Often signed with GPG to chain trust.
• Inline hash on the download page. Common for small projects without a release-management process.
• Subresource Integrity (SRI) hashes. Browser-enforced hashes for <script> and <link> tags. The browser refuses to execute the asset if the hash doesn’t match.

Browser memory limits

Hashing a multi-gigabyte file in the browser consumes memory equal to the file size. Browsers handle 1–2 GB acceptably; multi-gigabyte ISOs may slow down or fail. For very large files, command-line tools (sha256sum, shasum -a 256, Get-FileHash) are more efficient.

The tool above reads the whole file into memory and then hashes it with Web Crypto, so memory use grows with the file size — fine for downloads of a few hundred megabytes, slow or failing for multi-gigabyte images.

Common pitfalls

• Comparing only some hex characters. “The first 8 chars match, must be fine.” Hashes are designed so any change scrambles the entire output; comparing a prefix isn’t safe. Compare the full string.
• Whitespace in the published hash. Some publishers post 5e38b55d filename.iso (hash, two spaces, filename, in sha256sum format). Copy only the hash part.
• Algorithm mismatch. Computing SHA-256 and comparing to a SHA-1 hash. The lengths differ — 64 hex chars for SHA-256 vs 40 for SHA-1 — so the mismatch is obvious; but it’s still the most common manual-verification error.
• Trusting the hash from the same source as the binary. If both come from a compromised mirror, both are bad together. Get the hash from the publisher’s authoritative HTTPS source.

For other hash needs, see the hash generator for hashing strings, and the dedicated pages for MD5, SHA-1, SHA-256, SHA-512.