What a hash is for
A hash turns any amount of data into a short, fixed-length fingerprint. The same input always produces the same fingerprint, and any change at all (one byte, one space) produces a completely different one.
That makes hashes good for three jobs:
- Checking that data arrived intact, by comparing the fingerprint with the published one.
- Spotting duplicates without comparing the whole contents.
- Proving a value hasn’t changed, when combined with a key, as JWTs do.
It’s a one-way trip. A hash can’t be turned back into the text.
Which algorithm to use
| Algorithm | Length | Use it for |
|---|---|---|
| MD5 | 32 hex characters | Non-security checksums only; broken since 2004 |
| SHA-1 | 40 | Legacy systems and git object ids; broken for security since 2017 |
| SHA-256 | 64 | The sensible default for anything new |
| SHA-384 | 96 | When a standard or a certificate requires it |
| SHA-512 | 128 | Like SHA-256, often faster on 64-bit machines |
“Broken” has a specific meaning here: researchers can build two different inputs that share a hash. That destroys any use where the hash proves authenticity, such as signatures or software downloads. It doesn’t stop MD5 being useful for catching an accidental corruption, which is why you’ll still see it published alongside downloads.
Hashing is not encryption, and not password storage
Not encryption: there’s no key and no way back. If you need to recover the original later, you want encryption, not a hash.
Not password storage: plain SHA-256 of a password is a well-known mistake. These algorithms are designed to be fast, and an attacker with a leaked database will try billions of guesses per second. Passwords need a deliberately slow, salted algorithm (bcrypt, scrypt or Argon2) where every password also gets its own random salt, so two identical passwords don’t share a hash.
Why your hash doesn’t match
Almost every mismatch comes down to the bytes, not the algorithm:
- A trailing newline. Files usually end with one; a text box doesn’t.
abcandabc\nhave nothing in common as hashes. - Line endings. A file written on Windows uses
\r\n, one from macOS or Linux uses\n. - A byte-order mark, an invisible three-byte marker some editors put at the start of a file.
- Encoding. This page hashes the UTF-8 bytes, which is what almost everything uses today. A system hashing UTF-16 will produce a different result for anything non-English.
- Copy-paste damage, like a leading space or a line break inserted by an email client.
Hashing the file itself, instead of pasting its contents, sidesteps all of this: a dropped file is hashed byte for byte, the same way sha256sum or certutil -hashfile would read it, with no encoding or copy-paste step in between.
When you paste a hash to check, the box also tells you when the length matches a known algorithm but the value doesn’t, which means the algorithm is right and the input differs.
Hex, and other ways to write a hash
A hash is bytes. Hex is the usual way to print them: two characters per byte, which is why SHA-256 shows as 64 characters. Some tools print the same bytes as Base64 instead, which is shorter, and some insert colons every two characters. Those are the same fingerprint in different clothes, and pasting any of them into the check box works, since spaces, colons and an algorithm prefix are ignored.