MD5 vs SHA-256 vs Bcrypt: Which Hash Should You Actually Use?

"Just hash it" hides a decision that matters. MD5, SHA-256 and bcrypt are all hash functions, but using the wrong one — especially for passwords — is a security bug, not a style choice. Here's the short, practical map.

What a hash actually is

A hash turns any input into a fixed-length fingerprint, one-way: you can't reverse it back to the input. The same input always produces the same hash, and a tiny change produces a completely different one. That's why hashes are used for integrity checks and password storage — but the three families have very different properties.

MD5 — fast, broken for security

MD5 produces a 128-bit hash and is extremely fast. That speed, plus known collision attacks, makes it unsafe for passwords or signatures. It's still fine for non-security uses: detecting accidental file corruption, deduplicating files, cache keys. Generate one with the MD5 hash generator — just never use it to protect anything.

SHA-256 / SHA-512 — integrity and signatures

The SHA-2 family (use the SHA-256 generator or SHA-512 generator) is the modern default for verifying that a download, document or API payload wasn't tampered with. It's collision-resistant and trusted across TLS, Git and blockchains. But it's also fast — which is exactly why it's still the wrong tool for raw password storage.

Bcrypt — the one for passwords

Passwords need a slow, salted hash so attackers can't test billions of guesses per second. Bcrypt is deliberately expensive and bakes in a random salt and an adjustable cost factor, so you can make it slower as hardware gets faster. For passwords, use bcrypt (or argon2/scrypt) — never plain MD5 or SHA.

The one-line rule

Checksum a file? MD5 or SHA-256. Verify integrity or sign data? SHA-256. Store a user's password? Bcrypt, always. For other developer tasks, the SHA-1 generator, CRC32 checksum and UUID generator cover the rest — all running in your browser, nothing transmitted.