Hash and Checksum Generator

Somewhere under most download buttons sits a line of gibberish: sixty-four letters and digits, sometimes labelled SHA-256, sometimes not labelled at all. Most people scroll past it. That line is the only part of the page that can tell you whether the file on your disk is the file the publisher meant you to have, and checking it takes about as long as reading this paragraph.

What a hash is, and what it is not

A cryptographic hash function takes a message of any length and returns a short value of fixed length, called a digest. The Secure Hash Standard, FIPS 180-4, defines SHA-1 and the SHA-2 family: SHA-224, SHA-256, SHA-384, SHA-512 and the truncated SHA-512/256, among others. MD5, older still, is described in RFC 1321. Each one works the same way at heart. The message is padded, cut into blocks of 512 or 1,024 bits, and pushed block by block through a compression function that churns a small internal state. Whatever state is left at the end is the digest.

The useful property is that a tiny change anywhere in the input scrambles the whole output. Change one byte of a four-gigabyte disk image and its digest changes, in NIST’s word, dramatically. That makes the digest a fingerprint. It is not a summary, though, and it is not encryption. Nothing about the file can be read back out of it, and nothing about it says who made the file.

That last point deserves a sentence of its own. A matching checksum proves that two sets of bytes are identical. It proves nothing about whether those bytes are good. If an attacker can change both the download and the checksum printed beside it, the two will agree perfectly. The checksum is only as trustworthy as the page you copied it from, which is why careful projects publish it somewhere separate from the file, or sign it.

The digest also depends on bytes, not on meaning. The same sentence saved with Windows line endings, which put a carriage return before every line feed, has one more byte per line than the same sentence saved on a Mac or Linux machine, so it has a completely different hash. Text typed into a browser box is stored with plain line feeds, and the tool lets you choose how line breaks are written before hashing, because that choice alone decides whether your digest will ever match someone else’s.

Why the line next to a download matters

Files get damaged in boring ways far more often than in sinister ones. A download stops early and the browser keeps the partial file. A mirror serves a stale copy. A flaky USB stick flips a bit. An installer that is one byte short may still start, then fail halfway through in a way that looks like a bug in the software rather than in the copy. Comparing a checksum catches all of these before you have wasted an afternoon on them.

Checking costs seconds. Skipping it can cost a day spent chasing a bug that was never in the software.

The habit also has a security payoff. Download mirrors are run by many different people. If the checksum is published on the project’s own site over a secure connection, a match tells you that the mirror handed you exactly what the project released, not something swapped in on the way.

Checksum lists have a settled shape. The GNU Coreutils manual describes the plain format written by tools such as sha256sum: the hex digest, a space, a mode flag that is a space for text or an asterisk for binary, then the file name. That is why most lists show two spaces between the hash and the name. The tagged format looks like a sentence, with the function’s name, the file name in parentheses, an equals sign and the digest. The FreeBSD manual shows both forms and notes that its tools read either. A file named SHA256SUMS is usually just many such lines, one per file in a release.

How to compare one by hand

Comparing by eye is where people slip. Humans check the first few characters and the last few and call it done. With 64 hex digits, that leaves a long middle nobody looked at. Use a tool that compares every digit, or at least paste both values into the same search box and see whether one finds the other.

Here is a worked example you can reproduce. Type the three letters abc, nothing else, no line break after them, and hash them with SHA-256. The standard says the message is padded with a single one bit, then 423 zero bits, then the length, 24, written as a 64-bit number, which fills exactly one block of 512 bits. The digest NIST publishes in its SHA-256 example file begins ba7816bf and ends f20015ad.

If you add a line break after the letters, the input becomes four bytes and the digest changes completely. Now try the 56-letter alphabet sequence from the same example file, abcdbcdecdef and so on up to nopq. Fifty-six bytes leave no room in the first block for the eight-byte length, so the padding spills into a second block. Implementations that forget that second block give wrong answers for every input whose length falls in that narrow band, which is why the tool is tested at exactly that boundary.

Length is a quick first clue to the function. MD5 digests are 32 hex digits, SHA-1 40, SHA-224 56, SHA-256 64, SHA-384 96 and SHA-512 128. One length is ambiguous: SHA-512/256 also produces 64 digits, so a bare 64-digit value could be either, and only the publisher’s label settles it. The tool guesses SHA-256, the far more common choice, and asks you to confirm.

Why MD5 and SHA-1 are retired, and why they still work for this

A hash used for security has to resist collisions: it must be infeasible to find two different inputs with the same digest. MD5 lost that property long ago. RFC 6151 records that collisions were demonstrated in 2004, that later attacks found them in about a minute on an ordinary notebook, and that the attack was carried over to forged certificates. Its conclusion is direct: MD5 is no longer acceptable where collision resistance is required, such as digital signatures.

SHA-1 held out longer. RFC 6194, written in 2011, already described an attack far cheaper than brute force. In 2017 a team of researchers published the first actual collision for the full function: two different PDF documents with the same SHA-1 digest. Their paper puts the cost at about 2^63.1 compression calls, roughly 6,500 CPU years and 100 GPU years, which sounds enormous and was still more than 100,000 times faster than brute force. NIST announced in 2022 that SHA-1 should be phased out by December 31, 2030, and urged anyone relying on it for security to move to SHA-2 or SHA-3.

None of this breaks them for spotting accidental damage. A collision attack needs someone to build both files on purpose. A truncated download or a flipped bit is not an adversary; it is noise, and noise does not find collisions. The GNU manual makes the same distinction for MD5: reliable for accidental corruption, not secure against deliberate tampering. So if a project only publishes an MD5 sum, checking it is still far better than checking nothing. Just do not treat a match as proof that nobody interfered.

So the rule is short. When you choose the function, choose SHA-256 or stronger. When someone else chose it, check whatever they published.

HMAC, briefly

A plain hash can be recomputed by anyone, so it cannot prove that a message came from someone who holds a secret. HMAC, defined in RFC 2104 and standardized as FIPS 198-1, adds a key. The key is padded to the block size and mixed into two nested hashes, one inside the other, with fixed constants. Only someone with the key can produce the right tag, and RFC 4231 publishes test values so that implementations can be checked against each other. Interestingly, RFC 6151 notes that HMAC-MD5 was not urgently threatened by the MD5 collision results, though new designs should still avoid it.

Streaming large files

The browser has a hashing interface of its own, SubtleCrypto, and MDN documents its limits plainly: it offers SHA-1, SHA-256, SHA-384 and SHA-512 only, and it does not support streaming input, so the whole file must sit in memory first. That is fine for a text box and hopeless for a ten-gigabyte image. The design of these functions is what saves the day. Because they consume one block at a time and keep only a small state, a file can be fed to them in pieces of any size and the result is identical to hashing it in one go.

The tool does exactly that. It reads each file with the slice method of Blob, which returns a new Blob holding just one byte range, in pieces of 4 MiB, and hands every piece to all the functions you picked before letting it go. The work happens in a web worker, a background thread that keeps the page responsive. Memory stays at roughly one slice no matter how large the file is. On small inputs, the tool also asks SubtleCrypto for the same digests and checks that the two agree.

What it cannot do is worth saying. It cannot tell you whether the checksum you pasted is genuine; that depends on where you got it. It cannot verify a signature on a checksum list, which is the step that would close that gap. And it hashes only what you give it, so a list that names a file you have not opened is reported as not opened rather than as a match. Within those limits, it turns a line most people ignore into a clear answer: these bytes are, or are not, the ones that were published.