Paste the same text into Hash Generator and you get four different-looking strings back — MD5, SHA-1, SHA-256, SHA-512. They all do the same basic job: turn arbitrary input into a fixed-length fingerprint. But they are not interchangeable, and picking the wrong one for the wrong job is a genuinely common mistake.
Here's what each one is actually good for, and where each one has quietly failed people.
The Short Version
| Algorithm | Output length | Status in 2026 | Use it for |
|---|---|---|---|
| MD5 | 128-bit | Broken for security | Quick file-integrity checks, cache keys, non-adversarial dedup |
| SHA-1 | 160-bit | Broken for security | Legacy compatibility only (git objects, old systems) |
| SHA-256 | 256-bit | Secure | Passwords (with salting), file integrity, general-purpose hashing |
| SHA-512 | 512-bit | Secure | Same as SHA-256, slightly faster on 64-bit hardware, larger output |
Why "Broken" Doesn't Mean "Doesn't Work"
MD5 and SHA-1 still produce a valid-looking hash every time — the algorithms run fine. "Broken" means something specific: researchers have demonstrated collisions — two different inputs that produce the identical hash. For MD5, collisions can be generated in seconds on ordinary hardware. For SHA-1, Google's SHAttered project produced a practical collision back in 2017.
That matters enormously in some contexts and not at all in others:
Where it matters: anything where an attacker could benefit from crafting a malicious file that hashes identically to a legitimate one — code-signing, certificate validation, password storage, anywhere the hash is used as a trust anchor against an adversary.
Where it doesn't matter: checking whether a download got corrupted in transit, generating a cache key, deduplicating files in a personal backup tool. Nobody is trying to attack your download progress bar.
The Password Storage Trap
This is the mistake that shows up in real breach postmortems: hashing a password with plain MD5 or SHA-256 and calling it secure. All four algorithms in this comparison — including SHA-512 — are designed to be fast. Fast is exactly the wrong property for password hashing, because it's also what lets an attacker try billions of guesses per second against a leaked hash dump.
If you're storing passwords, none of these four are the right tool. Use a purpose-built password hashing function instead — bcrypt, scrypt, or Argon2 — which are deliberately slow and tunable. SHA-256/512 are for verifying data integrity, not for protecting secrets against guessing attacks.
When MD5 Is Still Completely Fine
Despite being "broken," MD5 remains genuinely useful for one thing: confirming a file wasn't corrupted or accidentally altered, where nobody is deliberately trying to fool the check. Its speed and short 32-character output make it convenient for:
- Verifying a large download completed correctly
- Quick deduplication of files in a personal script
- Cache-busting keys in build tooling
The line to remember: MD5 answers "did this change by accident?" fine. It cannot answer "can I trust this came from who I think it did?" — that requires collision resistance it no longer has.
SHA-256 vs SHA-512 — Does It Matter Which You Pick?
For most general-purpose use, either is secure and the choice barely matters. Two practical differences:
- SHA-512 is often faster on 64-bit systems — it operates on 64-bit words, which modern CPUs handle natively, so it can outperform SHA-256 despite producing a longer output.
- SHA-256 has a shorter, more commonly expected output — many APIs, git-adjacent tools, and checksums default to SHA-256 as the convention, so it's the safer default when interoperability matters more than raw speed.
If you don't have a specific reason to pick one, SHA-256 is the more universally expected default in 2026.
Quick FAQ
Can two different files ever produce the same hash by accident? Theoretically yes (a "collision"), but for SHA-256/512 the odds are astronomically small — far less likely than a hardware failure corrupting your comparison. This is different from a deliberately engineered collision, which is what breaks MD5/SHA-1 for security purposes.
Is a longer hash always more secure? Not automatically — security depends on the algorithm's design resisting collision attacks, not just output length. SHA-512's length gives it a larger theoretical security margin, but SHA-256 is not considered "weaker" for realistic use in 2026.
Why does git still use SHA-1? Historical inertia — git adopted SHA-1 before its weaknesses were public, and migrating a distributed version control system's core identifier format is a massive undertaking. Newer git versions are transitioning toward SHA-256 support.
Should I salt a hash? Salting (adding random data before hashing) matters specifically for password storage, to stop precomputed rainbow-table attacks — but as covered above, use bcrypt/Argon2 for passwords, not a salted SHA-256.
Related Free Tools
- Hash Generator — generate MD5, SHA-1, SHA-256, and SHA-512 from any text, all at once
- Base64 Encoder — for encoding, not hashing — the two get confused often
- Password Generator — generate strong random passwords instead of hand-picking them
- JWT Decoder — see hashing applied in a real signature-verification context