Hash generator: MD5, SHA-256 and file checksum verification

A hash is not encryption, and cannot be reversed

This is the confusion most people arrive with, so let us clear it first. Encryption is reversible by design: with the right key you get the original back, because the original is in there. A hash is not reversible at all, and not because nobody has found the trick yet, but because the information is not there.

The fastest way to see it: a 4 GB file and the word "hello" produce exactly the same 64 characters of SHA-256. It is impossible for those 64 characters to contain the 4 GB. A hash is a fingerprint of the content, not a wrapper: it identifies without storing.

And the sites promising to "decrypt MD5"? They decrypt nothing. They hold an enormous table of ordinary texts with their hashes already computed and look yours up inside it. With 123456 they hit instantly, because it is in the table. With a long unique password they never hit, because it cannot be.

MD5 and SHA-1 are broken, and they are still here

"Broken" means something specific: two different files can be deliberately crafted to share a hash. That completely destroys any use where the hash must prove authorship or authenticity — digital signatures, certificates, passwords — and there MD5 and SHA-1 must not be used under any circumstances. For MD5 this was demonstrated in 2004 and today a collision takes seconds; for SHA-1, in 2017 with two different PDFs sharing a hash.

What it does not destroy is the job of catching accidental corruption. If your download was cut short or a byte flipped in transit, the MD5 changes anyway: making two files share a hash requires building them on purpose, and line noise builds nothing. So they stay, and for an even more down-to-earth reason: half the internet still publishes the MD5 of its downloads, and if your provider gives you an MD5, you need to compute an MD5 to compare it.

The tool labels them so you know where you stand. If you get to choose the algorithm and nobody is imposing one, use SHA-256.

Why this tool can handle a 4 GB file

The browser ships its own hashing functions, but they have two limits that rule them out here: they do not include MD5, and they only compute in one go, over a whole file loaded into memory. With 4 GB that does not fit.

So all five algorithms are implemented here in a form that accepts the file in chunks: read a piece from disk, fold it into the calculation, discard it, move on. The memory needed is one chunk's worth, whether the file is four gigabytes or forty.

There is one detail of such implementations that almost nobody tests and that breaks precisely on large files: the internal length counter. Many home-grown versions keep it in a 32-bit number, which overflows at exactly 512 MiB and returns a wrong checksum with no warning whatsoever. In other words: they fail from the size at which this tool starts being useful. Here that counter is kept differently, and it is verified by processing 513 MiB of data and checking the result against a reference implementation. Every algorithm is also checked against the test vectors published in its standard and against an independent implementation at every length from 0 to 300 bytes, which is where padding bugs hide.

When the checksum does not match

Before getting alarmed, rule out the boring explanation, which is what happens nine times out of ten: having pasted the checksum of another version, another architecture or another format of the same program. In a download table with eight rows, copying the neighbouring one is extremely easy.

The second most common cause is an interrupted download. Compare the file's size against the one the page advertises first: if they disagree, that is your answer and re-downloading fixes it.

If the size is exact and the checksum still does not match, then yes: do not run that file. And keep the limit of all this in mind: a checksum is only worth something if it comes from a trustworthy source. If it was handed to you on the same page you downloaded from, and that page were compromised, the attacker would have changed both. That is why serious projects sign the checksum file separately.

HMAC, for whoever signs requests

Anyone can compute an ordinary hash, so it proves nothing about who made it. HMAC adds a shared key: only someone holding it can produce the signature, and only someone holding it can check it. It is what many APIs require to authenticate requests — you sign the request string with your secret key and the server repeats the calculation — and what payment gateways use in their notifications, so you can verify the message came from them.

The HMAC tab accepts the key as text or as hexadecimal, since a fair number of providers hand it over that way. If what you want is to generate a key or a password rather than sign with one, that is what the password generator does. And if you need the result in Base64 to drop into a header, the Base64 tool explains that format in detail.

The limits, stated before they bite

There is no size cap: read in chunks, size affects time rather than memory. On an ordinary machine SHA-256 runs around 200-300 MB per second, so a 4 GB ISO is about twenty seconds. SHA-512 runs about six times slower — it works with 64-bit numbers that JavaScript does not have and must be emulated — so if you tick it on a big file, plan for that. Ticking several algorithms is worth it: the file is read once and all of them are fed in the same pass.

And one warning that is about use rather than size: this is not for storing passwords. These algorithms are designed to be fast, which is exactly what you do not want there: a graphics card computes billions of SHA-256 per second. Passwords need deliberately slow, salted algorithms such as bcrypt, scrypt or Argon2.