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

"Just use SHA-256, MD5 is broken" is close enough to correct as a default rule that it's worth following blindly most of the time - but it's not the whole story, and there's one common situation where MD5 is still the actually correct choice, not the outdated one.

The visible difference: output length

MD5 produces a 128-bit digest, shown as 32 hexadecimal characters. SHA-256 produces a 256-bit digest, 64 hex characters - twice as long. That difference alone isn't the reason to prefer one over the other; a longer string by itself doesn't make a hash function better. The reason that actually matters is what each algorithm's collision resistance looks like today.

The difference that actually matters: collision resistance

SHA-256 has no known practical way to deliberately construct two different inputs that hash to the same output. MD5 does - constructing an MD5 collision on purpose is a solved, practical problem today, which is exactly why MD5 is considered broken for any use where someone might have a reason to engineer a matching pair against you.

When MD5 is still the genuinely correct choice

If a system, a tutorial, or a legacy tool still publishes its checksum in MD5 - and plenty still do, because changing a published checksum format is its own migration - matching that value means computing MD5 yourself, not "upgrading" to SHA-256 and getting a number that will never match. This isn't MD5 being fine "despite" being broken; it's simply the correct tool for a job (matching an existing published value) where nobody is trying to deliberately fool you with a crafted collision. The same logic applies to deduplicating a pile of files by content fingerprint, or a cache key where the only requirement is "different input, (almost certainly) different key" - MD5's speed is a genuine advantage there, and nobody's adversarially engineering your cache inputs.

When to default to SHA-256 instead

Anywhere the input could plausibly be chosen by someone with a reason to fool you - verifying a downloaded file actually matches what a vendor published as protection against a tampered mirror, generating any value you're making a security or integrity claim about to someone else, or simply "I don't have a specific reason to pick something else" - SHA-256 is the safer, more future-proof default. It costs essentially nothing extra to compute for the file and text sizes this tool handles, so there's rarely a real reason not to reach for it first.

What about SHA-1, SHA-384, and SHA-512

SHA-1 sits in the same broken-for-collisions category as MD5, just with a longer digest - it still shows up in older git internals and legacy checksums, and the same "match what's already published" logic applies to it as to MD5. SHA-384 and SHA-512 are SHA-256's larger siblings, offering more headroom than almost any everyday text-hashing task actually needs; reach for them specifically when a system you're integrating with asks for one by name, not by default.

A quick way to decide, if you're still not sure

Ask one question: could someone with a reason to fool me have chosen this input on purpose? If the answer is genuinely no - you generated the text yourself, or it's simply "some content, changed or not" with nobody adversarial in the picture - MD5 or SHA-1 will do the job and are a little cheaper to compute. If the answer is yes, or you're not sure, or you're about to tell someone else "this hash proves the file is what I say it is," SHA-256 is the answer, no further thought required, and it costs you nothing meaningful to default to it going forward.

What none of these five should ever be used for

Whichever algorithm fits the checksum job in front of you, none of the five - including SHA-256 - is a safe way to store a password. That's a completely different use case with a completely different correct answer (bcrypt, scrypt, or Argon2, always salted), covered in full in the background piece. Mixing up the two use cases is the single most common way a hash function gets misused in a real application, and it's worth double-checking which job you're actually doing before you commit to an algorithm.

Verifying a real download against a published checksum

A concrete, common scenario: you've downloaded a file and the publisher lists a SHA-256 (or MD5) checksum on the download page. This tool hashes text, not files, so it cannot check a binary download, and even a pasted text file can differ from the file on disk (a trailing newline, Windows line endings). For a real download, run shasum -a 256 file (or certutil -hashfile file SHA256 on Windows) and compare that digest with the published one. If they match character for character, the file is exactly what the publisher intended; if even one character differs, something changed in transit.

For the mechanics of computing a digest, see the how-to guide. And whichever algorithm you pick, remember it's for checksums and cache keys, never for storing a password - see why. Or try it now.