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

"Just use a hash" is common advice that skips the actual question: which one, and why. The answer depends entirely on whether you're defending against an adversary or just checking for accidental corruption — and conflating the two is how outdated hash choices end up in places they shouldn't be.

Generate any of them in your browser (free, instant)

The Hash Generator on keptlocal computes MD5, SHA-1, SHA-256, SHA-384, and SHA-512 simultaneously as you type, entirely in your browser.

The short answer

Default to SHA-256 unless you have a specific reason not to. It's fast, universally supported, has no known practical collision weakness, and is what most modern systems (Git's newer object format, TLS certificates, package manager checksums) have standardized on. The rest of this comes down to when the older algorithms are still legitimately fine to use.

What "broken" actually means here

Both MD5 and SHA-1 are broken in a specific, technical sense: researchers demonstrated practical methods to construct two different files that produce the identical hash — a "collision." That capability matters enormously if a hash is being used to prove a file hasn't been tampered with by someone who might want to trick you (a malicious download disguised as a legitimate one, a forged digital signature). It matters far less if you're just checking whether a file got corrupted during an ordinary transfer, or deduplicating files in your own storage — nobody is trying to deliberately engineer a matching hash in that scenario.

When each one still makes sense

• MD5 — legacy checksum verification (older software mirrors still publish MD5 sums), quick internal deduplication, matching against systems that only accept MD5. Never for anything where a malicious actor might try to forge a match.
• SHA-1 — largely superseded, though still present internally in older Git repositories. New projects should not choose it deliberately.
• SHA-256 — the default choice for almost everything in 2026: file integrity checks, package manager lockfiles, TLS certificate fingerprints, Bitcoin's proof-of-work, general application use.
• SHA-384 / SHA-512 — used where a system specifically calls for a larger digest, often for marginal extra cryptographic headroom; functionally similar to SHA-256 for most practical purposes.

The one thing none of these should be used for

Password storage. This is worth repeating because it's a common and serious mistake: general-purpose hash functions (MD5, SHA-1, SHA-256, and friends) are deliberately fast — designed to hash gigabytes of data quickly. That speed is a liability for password storage specifically, because it makes brute-forcing a stolen password database computationally cheap. Password storage needs a function designed to be slow and resource-intensive on purpose, with built-in per-password salting: bcrypt, scrypt, or Argon2 (the current recommended default). If you're building anything that stores user credentials, this is the one place where "just use SHA-256" is actively bad advice.

Privacy: what happens to your input

Every algorithm runs locally — SHA-family hashes through the browser's native Web Crypto API, MD5 through a small local JavaScript implementation. Nothing you type is transmitted anywhere.

Generate any of these hashes now with keptlocal's free Hash Generator — no upload, no signup.