File checksum

The point of a checksum is to establish that a file is exactly what its publisher intended — that nothing was corrupted in transit and nothing was substituted. Sending that file to a third party in order to find out reintroduces exactly the party you were trying to rule out. If they returned the wrong digest you would have no way to know.

Computing it locally is the only arrangement where the answer means anything. The digest is produced by your browser using the cryptography built into it, which is the same code your browser uses for HTTPS.

A matching digest proves the bytes are identical to the ones the publisher hashed. That covers a truncated download, a corrupted copy and a substituted file. It is a strong guarantee and a narrow one.

What it does not prove is that the publisher is trustworthy, or that the page you copied the expected value from was not itself tampered with. If an attacker can change the download they can usually change the checksum printed beside it, which is why serious projects sign their releases as well. A checksum answers "did I get what that page offered", not "was that page honest".

MD5 has been broken for collision resistance since 2004, and the cryptography built into browsers deliberately declines to implement it. That is a defensible decision and an inconvenient one, because a good many older projects still publish only an MD5.

SHA-1 is here despite having its own collision weakness, because comparing against a published value is the whole use and a great many pages still publish one. It is marked as legacy. If a project publishes only MD5, that is worth noticing about the project.

It proves the file you have is byte-for-byte the file the hash was computed from. That covers a truncated download, a corrupted disk, a transfer that silently failed — the ordinary accidents, which are the common case and the reason most checksums exist.

It proves nothing about where the hash came from. If both the file and the hash were fetched from the same page, an attacker who could replace one could replace the other. A checksum verifies integrity against accident by itself, and against tampering only when the hash arrived by a route the file did not.

SHA-256 is the default worth using and is what most projects publish now. MD5 and SHA-1 are both broken for security purposes — deliberate collisions have been demonstrated for each — which means neither should be trusted to prove a file has not been altered on purpose.

They remain in wide use for accidental corruption, where they are perfectly adequate and faster, and a great deal of older software emits nothing else. Verifying an MD5 published in 2009 against a file from 2009 is a reasonable thing to do; treating a new MD5 as a security guarantee is not.

A SHA-256 hash is 64 hexadecimal characters. Checking the first six and the last six feels sufficient and is exactly the shortcut that a deliberately crafted collision would exploit, and also the way a genuine mismatch in the middle goes unnoticed.

Paste the expected value in and let the comparison be done character by character. It takes the same time as glancing and removes the class of error entirely — which is the whole reason a verification field exists rather than just a display of the computed hash.

Hashing runs inside your browser tab, so nothing is uploaded. That matters more than it might seem: the files people verify are installers, disk images, archives and backups, and sending a multi-gigabyte file to a website to check it has not changed would be an odd way to establish that.

It also means there is no size ceiling beyond your own patience — a large disk image is read in chunks rather than held in memory whole, and the only cost is time on your own processor.