MD5 vs SHA-256 vs bcrypt: Which Hash to Use and When

What a hash function is

A hash function takes an input of any size — a single word, a 4 GB PDF, an entire database dump — and returns a fixed-length string called a digest, or simply "the hash". SHA-256, for instance, always spits out 256 bits, which is 64 hexadecimal characters, whether you feed it the letter "a" or the complete works of Shakespeare.

Three properties define a good cryptographic hash:

• Deterministic: the same input always produces the same digest.
• Avalanche effect: flip a single bit of the input and almost the entire output changes.
• Collision resistant: it must be infeasible to find two different inputs with the same hash.

The avalanche effect is obvious with an example. Here is the MD5 of two passwords that differ by one digit:

One character changed and the whole digest is different — no visible resemblance between the two. You can reproduce this right now in the MD5 Hash Generator: type both words and compare.

Hashing is not encryption (and why that matters)

This is the most common confusion, and it leads to bad security decisions. Encryption is a two-way operation: you scramble data with a key and, with the same key (or its pair), unscramble it back. The goal is reversible confidentiality.

Hashing is one-way. There is no "un-hashing". The digest ba7816bf... does not store the original input anywhere — it destroys it by design. That is why you should never "encrypt passwords": passwords should be hashed, precisely because you never need to read them back. To check a login, you hash whatever the user typed and compare it against the stored digest.

MD5 and SHA-1: why they are retired for security

MD5 was created by Ron Rivest in 1991 and produces 128 bits (32 hex characters). SHA-1, from 1995, produces 160 bits (40 characters). Both held up the internet for over a decade — and both are broken for any security use.

The problem is collision resistance. In 2004, researchers demonstrated practical MD5 collisions; today you can generate one in seconds on a laptop. SHA-1 lasted longer, until the 2017 "SHAttered" attack (Google + CWI) produced two different PDFs with exactly the same SHA-1 hash. A more dangerous chosen-prefix collision followed in 2020 for roughly 45,000 US dollars of compute.

In practice this means an attacker can forge a malicious file with the same digest as a legitimate one. That is why MD5 and SHA-1 were pushed out of TLS certificates, digital signatures and password systems. MD5 still has legitimate non-cryptographic uses — a quick check for accidental file corruption, or a cache key — but never where an adversary can cheat.

SHA-256 and the SHA-2 family: checksums and integrity

The SHA-2 family, published by NIST in 2001, is today's standard for integrity. The most-used members are SHA-256 (256 bits / 64 hex) and SHA-512 (512 bits / 128 hex). There is no practical collision attack against them — this is what protects the HTTPS certificates you rely on every day and Bitcoin transactions.

Compare the digests of the string abc across three algorithms to feel the size difference:

SHA-512 is not "more secure" for everyday work — SHA-256 is already robust — but because it operates on 64-bit words, it is often faster on modern 64-bit CPUs. Generate and compare them in the SHA-256 Hash Generator and the SHA-512 Hash Generator. There is also SHA-3 (Keccak), standardized in 2015 with a completely different internal construction — a backup in case SHA-2 ever falls.

bcrypt, scrypt and Argon2: hashing passwords

Here is the key twist: for passwords, you do not want SHA-256. You want a deliberately slow algorithm. bcrypt, built in 1999 on top of the Blowfish cipher, was designed for exactly this. A bcrypt hash looks like this:

$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW

• $2b$ — identifies the bcrypt version.
• 12 — the cost factor: it means 2¹² = 4,096 iterations. Each +1 doubles the work.
• the next 22 characters — the salt, randomly generated and embedded in the hash itself.
• the rest — the actual password digest.

scrypt (2009) and Argon2 (winner of the 2015 Password Hashing Competition) went further: on top of being slow, they are memory-hard, meaning they demand a lot of RAM. That specifically frustrates attackers who use cheap GPUs and ASICs to crack millions of passwords in parallel. Today OWASP recommends Argon2id; bcrypt remains solid and ubiquitous. You can generate and verify a hash in the Bcrypt Hash Generator.

Why passwords need slow hashing and salt

Run the numbers. A modern GPU computes billions of SHA-256 hashes per second. If your password store leaks with SHA-256 digests, an attacker burns through a whole dictionary and billions of combinations in hours. With bcrypt at cost 12, the same GPU manages maybe a few thousand attempts per second — the difference between cracking the password in an afternoon and taking centuries.

The salt solves a different problem. Without it, two people using "123456" would share the same digest, and an attacker could use a rainbow table (a precomputed lookup) to reverse millions of hashes at once. With a random per-user salt, every hash is unique and precomputed tables become useless. Many teams add a pepper too — a secret kept outside the database — as an extra layer.

Verifying file integrity in practice

When you download a Linux ISO or an installer, the site usually publishes the expected SHA-256 next to the link. The workflow is simple:

1. Download the file.
2. Compute its SHA-256 locally.
3. Compare it, character by character, with the published value.

If they match, the file arrived intact; if they differ by a single digit, it was corrupted in transit or tampered with. The File Hash (Checksum) tool does this calculation right in the browser, without uploading anything to a server. One caveat: a checksum is only as trustworthy as the page that publishes it — an attacker who controls the site can swap both the file and the hash.

The same idea protects what your site loads from external CDNs. The integrity attribute of a <script> tag stores a hash (SHA-384, for example) of the expected file; the browser recomputes it and refuses to load if it does not match. This is Subresource Integrity, and you generate that value in the SRI Hash Generator.

Frequently asked questions

Can I use SHA-256 to store passwords?

Technically it works, but it is a bad idea. SHA-256 is too fast — exactly what an attacker wants. Use bcrypt, scrypt or Argon2id, which are slow and salted by default. Keep SHA-256 for integrity and checksums, not for passwords.

Can you "decrypt" an MD5 hash?

No, because hashing is not encryption and there is no key to reverse. What exists are databases of precomputed hashes for common passwords. If your password is weak, it may be in those tables; a long, unique, salted password is not.

Is MD5 completely useless today?

For security, yes. For detecting accidental file corruption or serving as a cache key, it is still fast and good enough — as long as no adversary has any interest in forging a collision.

Why do I get two different hashes for the same file?

It is almost always a different algorithm (MD5 vs SHA-256) or a difference in text encoding (an extra line break, spaces, UTF-8 vs Latin-1). Hash the raw binary file, not a copy re-saved by your editor, and use the exact same algorithm on both sides.

What is the bcrypt cost factor?

It is a number that sets how many iterations the algorithm runs: cost 12 equals 2¹² = 4,096 rounds. Raising the cost makes the hash slower to compute — good against attackers, but you should tune it so it does not overload your server on every login (somewhere around 200 to 300 ms per hash is usually a good balance).