File Hash & Checksum Verifier

A cryptographic hash reduces a file of any size to a fixed-length fingerprint. Change one bit anywhere in the file and the digest changes completely — not slightly, completely, because that avalanche behaviour is what the function is designed for. So if the digest of your download matches the one on the publisher's page, the file you have is bit-for-bit the file they built.

That is a narrower guarantee than people often assume, and the distinction matters. A matching checksum proves integrity: nothing corrupted the file in transit and nobody swapped it on a mirror. It does not prove authenticity, because an attacker who can replace the download can usually also replace the checksum printed next to it. For authenticity you want a signature — GPG, or a hash published somewhere the attacker does not control.

Even so, integrity is worth checking, and hardly anybody does. Corrupted downloads are still common on flaky connections, mirrors do go stale, and the check costs about ten seconds.

Published checksums arrive in a dozen formats, and a verifier that reports "no match" because of a stray space teaches people to stop checking. This one takes the digest out of whatever you paste.

The algorithm is inferred from the digest's length rather than taken from a dropdown, so pasting a SHA-512 checksum compares against SHA-512 even if you were looking at the SHA-256 row. That removes the most common cause of a false mismatch — comparing two different algorithms and concluding the file is bad.

All four digests are computed at once when you choose the file, because you usually do not know in advance which one the publisher used, and computing the rest costs a few milliseconds even on a large file.

There is a circularity in server-side checksum tools that is easy to miss.

You are checking a file because you are not yet sure you can trust it — or because you cannot fully trust the channel it came through. Uploading it to a third-party website to answer that question means transferring the very file you are suspicious of to another party, and then trusting *that* party's answer about it. You have not removed a trust assumption; you have added one, and the new one is less accountable than the original.

The files people check make this concrete: an operating system image, an installer, a firmware blob, an encrypted archive, a database backup, a legal document whose integrity is the whole point. Uploading a multi-gigabyte ISO to a website is also just impractical, which is why most such tools quietly cap the file size and the ones you would most want to check are the ones you cannot.

Computing locally has neither problem. `crypto.subtle` is built into your browser, the file is read from your disk, and nothing is transmitted. There is no size cap beyond your device's memory. Verify the claim the same way as anywhere else here: Network tab, or disconnect from Wi-Fi and hash a file anyway.

SHA-256 is the right default and what almost every project publishes. SHA-512 is not meaningfully more secure for this purpose but is slightly faster on 64-bit hardware and some projects prefer it. SHA-384 appears occasionally, mostly in certificate contexts.

SHA-1 is included because a great deal of existing infrastructure still publishes SHA-1 checksums — Git object ids, older release pages, legacy vendor downloads — and you need to be able to check them. It should not be trusted against a deliberate attacker: practical collisions have been demonstrated, meaning someone can construct two different files with the same SHA-1. For catching accidental corruption it remains perfectly serviceable.

MD5 is deliberately absent, and not by oversight. The Web Crypto API does not implement it, precisely because it is comprehensively broken — collisions can be produced in seconds on ordinary hardware. Offering it would mean shipping a separate implementation in order to provide a check that gives false confidence. If a publisher offers only an MD5 checksum, treat it as a corruption check and not as evidence of anything more, and prefer a source that publishes SHA-256.

One practical note: the digest is of the file's exact bytes. An archive re-created from the same contents, or a text file whose line endings changed between Windows and Unix, produces a completely different digest even though the content looks identical. That is the function working correctly, not a fault.