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

MD5, SHA-256, and SHA-512 are all cryptographic hash functions — they take any input and produce a fixed-length fingerprint. But only two of them are still safe to use, and counterintuitively, the biggest one isn't always the slowest. Here's exactly when to reach for which.

At a Glance

The same input — the string hello — produces a wildly different output in each:

MD5:     5d41402abc4b2a76b9719d911017c592                                  (128 bits / 32 hex chars)
SHA-256: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824  (256 bits / 64 hex chars)
SHA-512: 9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca7
         2323c3d99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043  (512 bits / 128 hex chars)

Same input, three completely different fingerprints. Change a single bit of the input and every output changes too — that's the avalanche property all three share.

What Each Algorithm Was Designed For

MD5 (1992, Ron Rivest): designed as a fast 128-bit hash for general-purpose checksums and digital signatures. It dominated the 90s and early 2000s. Cryptographically broken since 2004 — researchers have demonstrated practical collisions, meaning two different inputs that produce the same MD5. Still useful as a non-security checksum.

SHA-256 (2001, NSA, published by NIST): part of the SHA-2 family. 256-bit output, designed to replace SHA-1 once weaknesses appeared. The current default for digital signatures, certificate fingerprints, blockchain proof-of-work (Bitcoin), and Git commit identifiers (in newer Git). No practical attacks known.

SHA-512 (2001, same family): SHA-2 with a wider internal state (64-bit words) and a 512-bit output. Same security guarantees as SHA-256 against the attacks we know about, with a larger margin against future ones. Counterintuitively faster than SHA-256 on 64-bit hardware.

Side-by-Side Comparison

The Critical Security Section

In 2004, Wang et al. demonstrated practical MD5 collisions — two different files with the same MD5 hash, computable in hours on a laptop. By 2008, researchers used this to forge a rogue Certificate Authority. By 2012, the Flame malware used MD5 collisions to impersonate Microsoft Update.

What this means in practice:

• Never use MD5 for: passwords, digital signatures, TLS certificates, code signing, anything where an attacker chooses or influences the input.
• MD5 is still acceptable for: file deduplication, cache keys, content-addressable storage, non-adversarial integrity checks (catching accidental corruption, not malicious tampering), legacy-compat where you control both ends.

The distinction is whether an attacker benefits from finding a collision. For a deduplication index of your own files, no. For a "this file hasn't been tampered with" claim, absolutely yes — use SHA-256 instead.

If you need to compute any of these for a file or string, the Hash Generator does all three in your browser.

SHA-256 vs SHA-512: The Counterintuitive Choice

You'd assume SHA-512 is twice as slow as SHA-256 because it produces twice as much output. It's the opposite on modern hardware.

SHA-512 was designed around 64-bit word operations. On a 64-bit CPU (every server and modern laptop since ~2008), one SHA-512 round processes twice the data per native instruction compared to SHA-256, which uses 32-bit words. Net result: SHA-512 is typically 20–50% faster than SHA-256 on x86-64 and ARM64 for the same input.

The numbers flip on 32-bit and embedded hardware (microcontrollers, older ARM, some IoT devices), where SHA-512 has to emulate 64-bit operations and SHA-256 wins handily.

A practical rule:

• Server, laptop, or modern phone → SHA-512 is faster, often noticeably.
• Embedded device, microcontroller, anything 32-bit → SHA-256 is faster.
• Need shorter output for storage or display → SHA-256.
• No specific perf or output-length constraint → SHA-256, because it's what most ecosystems expect.

There's also SHA-512/256 — SHA-512 internals truncated to a 256-bit output. It gives you SHA-512's speed advantage with SHA-256's output size, and slightly better security margins. Less common in practice; SHA-256 won the ecosystem war.

What About Passwords?

None of these. MD5, SHA-256, and SHA-512 are designed to be fast, which is exactly the wrong property for storing passwords. A modern GPU can compute billions of SHA-256 hashes per second, which means a leaked password database is brute-forced in hours.

Use a password hashing function designed to be deliberately slow and memory-hard:

• Argon2id — current best practice, winner of the 2015 Password Hashing Competition.
• bcrypt — battle-tested since 1999, still safe for most use cases.
• scrypt — memory-hard alternative.

Plain SHA-256 of a password is one of the most common cryptographic mistakes in the wild. If you're choosing a password to hash, the Password Generator helps with the input side; the storage side needs a password hashing function, not a general-purpose hash.

Common Pitfalls

"I'll just hash twice for extra security." Double-hashing (SHA-256(SHA-256(x))) doesn't meaningfully improve security against any known attack and can introduce length-extension issues. If you're worried about length-extension attacks specifically, use SHA-512/256 or HMAC-SHA-256.

"I'll truncate SHA-256 to 16 bytes to save space." That gives you a 128-bit hash, which is fine for non-security use but provides only 64-bit collision resistance. Probably acceptable for cache keys; not acceptable for security claims.

"MD5 is faster, so I'll use it for non-security stuff to save CPU." True for tiny inputs, but the difference is rarely measurable in real workloads. SHA-256 hashing is rarely a bottleneck — disk I/O is. Default to SHA-256 unless you've measured a problem.

"I'll compare hashes with ==." In a constant-time-sensitive context (e.g., comparing an HMAC to a user-supplied value), use a constant-time comparison function. Standard == short-circuits and leaks timing information. Not relevant for "is this file corrupted?" — only for "is this signature valid?"

Decision Rubric

• File integrity check, non-adversarial (download verification, deduplication) → SHA-256 default; MD5 if you specifically need its speed and the threat model is benign.
• Digital signatures, certificate fingerprints, blockchain, code signing → SHA-256 (or SHA-512 if your ecosystem prefers it).
• High-throughput hashing on 64-bit servers → SHA-512.
• Embedded device or 32-bit hardware → SHA-256.
• Password storage → none of the above. Use Argon2id or bcrypt.
• HMAC for API authentication → HMAC-SHA-256 (the standard everyone implements).

FAQ

Is MD5 actually broken or just theoretically broken? Practically broken. Collision attacks have been used in real-world malware (Flame, 2012) and rogue CA forgery. Preimage attacks (recovering input from hash) are still infeasible, which is why MD5 still works for non-collision-sensitive uses like deduplication.

Why does SHA-1 not appear here? Because it's also broken (Google demonstrated a SHA-1 collision in 2017 with the SHAttered attack) and there's almost no reason to choose it today over SHA-256. It survives in some legacy contexts (Git object IDs, some old TLS certificates) but new designs should skip it.

Should I be worried about SHA-256 being broken next? Not in the next decade. SHA-2 is structurally different from SHA-1 and MD5, and no significant weaknesses have been found in 25 years of analysis. SHA-3 (Keccak) exists as a hedge against the unlikely event of a SHA-2 break, but isn't in widespread use because SHA-256 is still considered safe.

What's the difference between SHA-256 and SHA-2? SHA-2 is the family; SHA-256 is the specific 256-bit variant. SHA-2 also includes SHA-224, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. When people say "SHA-2" they almost always mean SHA-256.

Can I shorten a SHA-256 hash by base64-encoding it? Yes — base64 is more compact than hex (43 characters instead of 64 for the same 256 bits). It's purely a display choice; the underlying hash is identical.