MD5 vs SHA-256 vs SHA-512

All three show up constantly — a Git-adjacent tool prints an MD5, a download page lists a SHA-256 checksum, a security doc mentions SHA-512 — and it's tempting to treat them as interchangeable "the hash." They're not. They come from different eras, make different tradeoffs, and one of them shouldn't be trusted for anything adversarial anymore.

At a glance

MD5: what "broken" actually means

MD5 isn't broken in the sense that it stopped working — feed it the same input twice and you'll always get the same 128-bit digest, exactly as designed. It's broken in the sense that matters for security: since 2004, it's been computationally practical to construct two different inputs that hash to the same MD5 digest — a collision — in seconds on ordinary hardware. That specifically breaks any use case where an adversary benefits from producing a lookalike: forging a certificate, crafting a malicious file with the same checksum as a trusted one, or getting a deduplication system to treat two different uploads as identical.

MD5's preimage resistance — given a digest, finding any input that produces it — hasn't suffered the same practical break. But that distinction is a poor reason to keep using it: every major standards body (NIST included) has deprecated MD5 outright, and SHA-256 costs you nothing extra to use instead. The one place MD5 remains genuinely fine is verifying accidental corruption — confirming a file wasn't mangled by a flaky download — where there's no adversary trying to exploit a collision, only bit flips to catch.

SHA-256 vs. SHA-512: same family, different word size

Both belong to the SHA-2 family and share the same overall design, but they're not just "the same algorithm at two output sizes." SHA-256 operates on 32-bit words across 64 rounds; SHA-512 operates on 64-bit words across 80 rounds, with roughly double the internal state. They're independent implementations of the same construction, not one truncated from the other — though SHA-2 also defines SHA-224 and SHA-384, which are truncated variants of SHA-256 and SHA-512 respectively.

The surprising part: SHA-512 can be faster

It's reasonable to assume the algorithm that produces a digest twice the size costs twice the compute. In practice, on 64-bit hardware, it's often the opposite. Hashing 1 MiB of random data 200 times on ordinary 64-bit hardware:

md5     ->  791 MiB/s
sha1    ->  991 MiB/s
sha256  ->  500 MiB/s
sha512  ->  717 MiB/s

SHA-512 outran SHA-256 by a wide margin. The reason is that SHA-256's 32-bit word operations don't use a 64-bit CPU's native register width, while SHA-512's 64-bit words do — so despite doing more total work per block, SHA-512 gets more of it done per CPU cycle. Exact numbers will vary by hardware and crypto library, but the general shape — SHA-512 competitive with, or faster than, SHA-256 on modern 64-bit hardware — holds broadly, and is exactly why SHA-512/256 (SHA-512's internals, truncated to a 256-bit output) exists as an option when you want SHA-256's digest size with SHA-512's speed.

How much security margin do you actually need?

For an n-bit hash, collision resistance tops out around n/2 bits due to the birthday bound — so SHA-256 gives you roughly 128 bits of collision resistance, and SHA-512 roughly 256. 128 bits is already so far beyond any brute-force attack that's physically conceivable that SHA-256 isn't the weak link in any realistic system built today. SHA-512's extra margin matters less for "is this safe right now" and more for long time horizons and defense in depth — hashing enormous data volumes over years, or wanting headroom against cryptanalytic advances decades out.

None of these belong in password storage

MD5, SHA-256, and SHA-512 are all built to do one thing well: hash large amounts of datafast. That's exactly the wrong property for password storage, where fast means an attacker with a stolen database can brute-force millions of guesses per second. Password hashing needs a deliberately slow, salted algorithm — bcrypt, scrypt, or Argon2 — never a raw general-purpose hash function, regardless of which one.

Practical guidance

• Default to SHA-256 for integrity checks, content fingerprints, HMAC signatures (it's the "256" in a JWT's HS256), and general-purpose hashing where you're not sure what to pick.
• Reach for SHA-512 when you're hashing large volumes on 64-bit server hardware and the throughput difference matters, or when a spec/protocol specifically calls for it.
• Only use MD5 against legacy tooling that hasn't moved on, or for non-adversarial accidental-corruption checks — never where tampering is a realistic threat.
• Never use any of the three for passwords. Use bcrypt, scrypt, or Argon2.

Try it yourself

Generate all three (plus SHA-1) from any text with Hash Generator, or check whether a piece of text matches a hash someone gave you with Hash Verifier, which auto-detects the algorithm from the hash's length. Both run entirely in your browser — nothing you type is ever sent anywhere.