Hash Generator

What a hash function is

A hash function turns any amount of data into a short fixed-length value, and does it the same way every time. The same input always gives the same digest, a single changed byte gives a completely different one, and the output size never changes, which is what makes it useful as a fingerprint for data you want to compare without storing or sending the data itself.

What it is not is reversible. There is no "decrypt" for a hash: the function throws information away, which is the point. A digest can be looked up in a table of pre-computed common inputs, which is exactly how leaked password databases get cracked, but it cannot be run backwards. If you need to recover the original, you wanted encryption, not hashing.

Which algorithm to use for what

• SHA-256 the sensible default. Fast, unbroken, and what almost everything standardises on: certificates, Git objects since the transition, blockchain, signed tokens.
• SHA-512 the same design with a bigger word size. Often faster than SHA-256 on 64-bit hardware, and the right choice when you want margin rather than compatibility.
• SHA-384 SHA-512 truncated. It exists because some standards require a 384-bit digest; nothing else recommends it.
• SHA-1 broken since 2017, when a practical collision was published. Still everywhere in Git history and old certificates, so you need to be able to compute it, but never to prove anything with it.
• MD5 broken much earlier and much worse: collisions take seconds on a laptop. Still the checksum printed on download pages, so it remains worth having, purely to match a published value.

Checking a download, which is the honest use of a broken hash

A checksum next to a download answers one question: did the file arrive intact. For that, even MD5 works, because a transfer error is random and will not produce a colliding file by accident. Paste the published digest into the compare field, hash your copy, and see whether they match.

What a checksum on the same page as the download does not tell you is whether the file is genuine. Anyone who can replace the file can replace the digest beside it, which is why serious projects sign the checksum file with a key rather than just printing it. If the digest and the file come from the same place and the same trust, you have verified transport, not authorship.

And a mismatch is almost never an attack. In order of likelihood: you hashed the text of the page rather than the file, the file is still downloading, an editor added a trailing newline, or the line endings changed between Windows and Unix. One invisible byte of difference changes every character of the digest, which is why the comparison is useful and also why it is unforgiving.

When two tools disagree

• A trailing newline the most common cause by far. Most editors add one when they save; echo adds one unless you pass -n. The digest of "abc" and of "abc\n" have nothing in common.
• The encoding text has to become bytes before it can be hashed. This tool uses UTF-8; a tool defaulting to Latin-1 will agree with it on plain ASCII and disagree the moment there is an accent.
• Line endings a file written on Windows has \r\n where a Unix one has \n. Same text, different bytes, different hash, and a reason to hash the file rather than its pasted contents.
• Upper against lower case hex cosmetic. 8F and 8f are the same byte, and the comparison here ignores the difference.
• Hashing the file against hashing the text a file carries exactly its bytes; pasting its contents into a text box can normalise whitespace or strip a BOM. For a checksum, use the file.

Hashing, salting, and why passwords are different

None of these algorithms is the right way to store a password, and that is worth saying plainly because it is the single most common misuse. They are built to be fast, and fast is exactly wrong: an attacker with a leaked database wants to try billions of guesses, and a fast hash helps them.

• Salt a random value stored alongside each password hash, so two people with the same password get different digests and one pre-computed table cannot crack both.
• A slow hash bcrypt, scrypt or Argon2. Deliberately expensive, tunable as hardware gets faster, and what a password should actually go through.
• HMAC a hash with a key, for proving a message came from someone who has the key. This is what signs a JWT; a bare hash proves nothing about origin.
• Collision two inputs with the same digest. The reason MD5 and SHA-1 are retired: a collision can be constructed on purpose, so a matching digest no longer means matching content.
• Checksum against cryptographic hash CRC32 catches accidental corruption and is trivial to forge. SHA-256 catches both, which is why only one of them belongs in a signature.