What a cryptographic hash actually is
A cryptographic hash function takes data of any size — a password, a file, a whole disk image — and produces a fixed-size fingerprint of it. Hash "hello" or hash a 4 GB video and you still get exactly the same number of output characters. Three properties make these functions useful:
- Deterministic: the same input always produces the same hash, on any machine, forever. That is what lets two parties compare fingerprints.
- Avalanche effect: change a single bit of the input and roughly half the output bits flip, in an unpredictable way. There is no "close" — the new hash looks completely unrelated.
- One-way: given a hash, there is no practical way to compute the input that produced it.
That last point causes a common misconception. People talk about "decrypting an MD5 hash," but hashing is not encryption — there is no key and no reverse operation. Hashing throws information away. When an online tool claims to "decrypt" a hash, it is really just looking the value up in a giant precomputed table of common inputs. That works for password123; it does not work for a long random string, because the original simply isn't stored anywhere to recover.
MD5: fast, familiar, and broken
MD5 produces a 128-bit digest, written as 32 hexadecimal characters. It is very fast and still shows up everywhere — download pages, legacy systems, quick scripts. The problem is that MD5 is cryptographically broken. Researchers demonstrated practical collision attacks (two different inputs producing the same hash) as far back as 2004, and the attacks have only gotten cheaper since; a collision can now be produced on a laptop in seconds.
A collision means an attacker can craft two files — say a harmless document and a malicious one — that share an identical MD5. Any system trusting MD5 to prove a file is unaltered can be deceived. So MD5 is fine only for non-security work where nobody is trying to fool you: deduplicating files, generating cache keys, sharding data, or catching accidental corruption during a copy. For anything an adversary might attack, treat MD5 as off-limits.
SHA-256: the current default
SHA-256 is a member of the SHA-2 family, published by NIST. It produces a 256-bit digest — 64 hexadecimal characters — and has no known practical collision attack. It is the default choice for file-integrity verification, digital signatures, TLS certificates, blockchain, and Git's newer object format. When you need a hash to mean "this data is exactly what I expect, and nobody could have forged it," SHA-256 is the baseline.
| Algorithm | Output bits | Hex length | Speed | Collision status | Recommended use |
|---|---|---|---|---|---|
| MD5 | 128 | 32 | Fastest | Broken (since 2004) | Non-security checksums, dedup, cache keys |
| SHA-1 | 160 | 40 | Fast | Broken (collision in 2017) | Deprecated — avoid for new work |
| SHA-256 | 256 | 64 | Fast enough | No practical attack | Integrity, signatures, certificates |
SHA-1 sits in between and is worth a mention only as a warning: it was the standard for years, but a real collision was produced in 2017, so it is now deprecated for security. The lesson is that "currently unbroken" is the only status that matters, and that status changes over time.
The same input, both ways
Nothing makes the difference clearer than hashing one short string. Take the input hello:
| Algorithm | Hash of "hello" |
|---|---|
| MD5 | 5d41402abc4b2a76b9719d911017c592 |
| SHA-256 | 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 |
The MD5 is exactly 32 characters; the SHA-256 is exactly 64. Both are completely deterministic — hash "hello" anywhere and you get those same strings. Change it to "Hello" and, thanks to the avalanche effect, the output is unrecognisably different. You can reproduce both values with the free MD5 generator and the hash generator, which supports SHA-256 and other algorithms.
Choosing the right hash for the job
The decision almost always comes down to who you are defending against.
- Verifying a download: use SHA-256. Compare the hash you compute against the one the publisher lists with a checksum tool. Only fall back to MD5 if MD5 is the only value the publisher provides — and even then, treat it as a guard against accidental corruption, not a malicious swap.
- Digital signatures and certificates: use SHA-256 or stronger. These rely on collision resistance to bind a signature to specific content, so a broken hash undermines the whole guarantee.
- Message authentication: don't hash a secret and the message together by hand — use HMAC with SHA-256, which is the correct construction for verifying both integrity and authenticity with a shared key.
- Passwords: use neither raw. This one is important enough for its own section.
Why passwords need a different tool entirely
It is tempting to store sha256(password) and call it secure. It isn't. The very thing that makes SHA-256 good for files — raw speed — is a liability for passwords. If your database leaks, an attacker can compute billions of SHA-256 hashes per second on commodity GPUs, racing through dictionaries and common patterns until they match your stored values. A fast hash gives them no friction.
Passwords need a slow, salted key derivation function (KDF): bcrypt, scrypt, or Argon2. These are engineered to be deliberately expensive — tunable to take a fraction of a second per hash — so that a legitimate login is unaffected but mass guessing becomes wildly impractical. The salt (a unique random value per password) ensures identical passwords produce different stored hashes, defeating precomputed lookup tables. scrypt and Argon2 add memory cost too, blunting the GPU advantage further. The rule is simple: never protect passwords with MD5, SHA-1, or SHA-256 alone.
The takeaway
Hash choice isn't about which algorithm is "best" in the abstract — it's about matching the tool to the threat. MD5 still has honest, useful jobs, but security isn't one of them. SHA-256 is the dependable modern default for proving data hasn't been tampered with. And passwords are their own category, demanding a function built to be slow on purpose. Get those three rules right and you'll avoid the mistakes that show up in real breaches.
Frequently asked questions
- Can you reverse or decrypt an MD5 or SHA-256 hash?
- No. Hashes are one-way functions, not encryption, so there is no key that turns a hash back into the original input. Tools that appear to "decrypt" a hash are really looking the value up in a precomputed table of known inputs and their hashes, which only works for short or common strings.
- Is MD5 safe to use for anything?
- Only for non-security tasks where an attacker has no incentive to forge a match: file deduplication, cache keys, sharding, or a quick checksum against accidental corruption. Because practical collision attacks against MD5 have existed since 2004, it must never be used for security — not for integrity against a malicious party, signatures, or passwords.
- Why shouldn't I hash passwords with SHA-256?
- SHA-256 is designed to be fast, which is exactly wrong for passwords. An attacker who steals your database can try billions of guesses per second against a fast hash. Passwords need a slow, salted key derivation function such as bcrypt, scrypt, or Argon2, which are deliberately expensive to compute and make large-scale guessing impractical.
- What is the avalanche effect?
- The avalanche effect means a tiny change in the input — even a single bit — produces a completely different, unpredictable output. Both MD5 and SHA-256 have it, which is why changing one character of a file flips roughly half the bits of the resulting hash and lets you detect any modification.
This guide is general educational information about hashing. Always follow current, authoritative cryptographic guidance and your platform's security recommendations for production systems.