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

"Just hash it" is common advice, but which hash you reach for matters enormously — and a few of the popular ones are cryptographically broken. This guide explains what a hash function actually does, why MD5 and SHA-1 should no longer be trusted for anything security-related, when SHA-256 is the right call, and the things hashing is emphatically not for.

What a hash function is

A cryptographic hash function takes any input — a word, a file, a gigabyte of data — and produces a fixed-size string of bytes called a digest. The same input always yields the same digest, and even a one-bit change to the input produces a completely different result.

Two properties make a hash cryptographic:

• One-way — given a digest, you can't feasibly work backwards to the original input.
• Collision-resistant — you can't feasibly find two different inputs that produce the same digest.

When a hash function fails the second property, it's considered broken, because attackers can craft two inputs that hash identically.

MD5: fast, ubiquitous, and broken

MD5 produces a 128-bit digest and is everywhere — file checksums, legacy systems, cache keys. It's also cryptographically broken: practical collision attacks have existed for years, and you can generate two distinct files with the same MD5 digest on a laptop.

That means MD5 must never be used where collisions matter: digital signatures, certificates, deduplication of untrusted files, or integrity checks against a motivated attacker. The one place it's still defensible is as a non-security checksum — a quick "did this file get corrupted in transit?" check where nobody is trying to fool you. For that narrow case its speed is a feature.

SHA-1: also broken, also deprecated

SHA-1 (160-bit) was the successor to MD5 and is now in the same boat. A real-world collision was demonstrated publicly (two different PDFs with the same SHA-1 digest), and browsers and certificate authorities have deprecated it. Treat SHA-1 like MD5: fine for legacy non-security checksums you can't change, unacceptable for anything new.

SHA-256 and SHA-512: the sensible default

For security purposes, use the SHA-2 family — most commonly SHA-256 (256-bit digest) or SHA-512 (512-bit). They have no known practical collision attacks and are the standard choice for file integrity verification, digital signatures, content-addressed storage, and as building blocks in larger protocols.

SHA-256("hello") =
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

If you simply need a trustworthy digest and aren't sure which to pick, SHA-256 is the safe answer. SHA-512 isn't "more secure" in a way that matters for most uses, but it can be faster on 64-bit hardware and produces a longer digest.

Hashing is one-way — it is not encryption

This confusion causes real bugs: hashing is not encryption. Encryption is reversible with a key; hashing is deliberately a dead end. You can't "decrypt" a SHA-256 digest back to its input — there's no key, and the operation throws information away. So-called "hash decrypters" online are just precomputed lookup tables for common inputs; they don't reverse the math.

Hashing is NOT how you store passwords

Here's the trap. A plain fast hash — even SHA-256 — is a poor way to store passwords. Because hashes are fast, an attacker who steals your database can try billions of guesses per second, and identical passwords produce identical digests.

Password storage needs a slow, salted algorithm designed for the job: bcrypt, scrypt, or Argon2. These are deliberately expensive to compute and salt each password individually, so precomputed tables and bulk guessing become impractical. If you're storing user passwords, reach for bcrypt or Argon2 — not a raw SHA call.

HMAC: a keyed hash for integrity and authentication

When you need to prove a message came from someone who holds a shared secret and wasn't tampered with, you want HMAC (Hash-based Message Authentication Code). HMAC combines a hash function with a secret key, so only parties who know the key can produce or verify the tag. It's what signs webhook payloads, API requests, and JWT (HS256) signatures. Critically, HMAC fixes a subtle weakness in naively concatenating a secret with data, which is why you should use HMAC rather than rolling your own keyed hash.

It runs in your browser

Hashing often involves sensitive input — file contents, secrets, tokens. The hash tools here compute everything in your browser using the Web Crypto API, so your data never leaves your machine. Use the general Hash Generator for any algorithm, or the dedicated MD5, SHA-256, and SHA-512 generators. For keyed authentication, the HMAC Generator takes a secret and a message.

Try it

Compute a digest with the free Hash Generator — no signup, and nothing leaves your browser. Need a keyed tag for webhook or API verification? Use the HMAC Generator.