Why MD5 and SHA-1 Are Still Everywhere, and Wrong for Passwords

"Hashing" sounds like one thing, and that's exactly what makes it easy to get wrong. In practice it covers two genuinely different jobs - checking whether a file arrived intact, and protecting a password against someone who steals the database it's stored in - and an algorithm that's completely fine for the first job is actively dangerous for the second. Knowing which job you're actually doing is most of what matters here.

What a hash actually does

A hash function takes any input, of any length, and produces a fixed-length string of characters - the same input always produces the exact same output, and even a one-character change produces a completely different one. It's one-way: there's no way to run the process backward and recover the original text from the digest alone. That property is genuinely useful for two very different reasons - proving two things are identical without comparing them byte for byte, and (in the security context) storing a check value for a secret without storing the secret itself. The catch, covered below, is that not every hash function is built the same way, and the differences matter a great deal for the second use.

Why MD5 and SHA-1 refuse to die

Both are decades old, both are fast, and both are baked into an enormous amount of existing tooling: package managers and download pages that still publish an MD5 or SHA-1 checksum next to a file, git's own commit identifiers (historically SHA-1), deduplication systems that fingerprint files by content, cache keys that just need "did this input change" rather than any security guarantee. None of that requires the property MD5 and SHA-1 actually lost.

What "broken" actually means here

MD5 and SHA-1 are cryptographically broken specifically for collision resistance - an attacker's ability to deliberately construct two different inputs that hash to the same value on purpose. That matters a great deal when you're trusting the hash to prove nobody tampered with something adversarially. It does not affect their reliability for accidental-difference detection, where nobody is engineering the input against you: a checksum catching a corrupted download, a cache key based on content that changed by accident, a deduplication fingerprint. "Broken for one specific attack" and "useless for everything" are not the same claim, and treating them as the same is how a real checksum use case ends up unfairly avoiding a perfectly fine tool.

A cache key is the clearest everyday example: you hash a piece of content so you can look it up quickly later, and the only thing that matters is "does this content match what's already cached." Nobody is trying to trick your cache into serving the wrong thing on purpose by engineering a collision - the specific failure mode MD5's weakness enables just isn't present in that scenario, which is exactly why MD5 remains a fast, reasonable choice for it.

The actual wrong move: hashing a password with any of these five

This is the one that matters. MD5, SHA-1, and the entire SHA-2 family (SHA-256, SHA-384, SHA-512) are all fast by design - that's a feature for a checksum and a serious liability for a password. If a database of hashed passwords leaks, an attacker doesn't need to break the hash function's math at all - they just need to hash a large list of common passwords and password-cracking dictionaries with the same fast algorithm and compare the results. Modern hardware is very good at exactly this kind of repetitive computation, which is precisely why a fast general-purpose hash offers a leaked password database almost no real protection on its own. Real password storage needs a hash that's deliberately slow and memory-hard, purpose-built to make that kind of brute-force attempt expensive: bcrypt, scrypt, or Argon2, each paired with a random salt so two identical passwords still produce different stored values. None of the five algorithms this tool offers were designed for that job, and none of them should ever be asked to do it.

The one-line rule that covers almost every case

If you're checking that something didn't change by accident, any of these five algorithms will do the job honestly - pick SHA-256 if you have no other reason to pick a specific one. If you're storing a secret that a person will need to prove they know later - a password, specifically - none of these five is the right tool at all, and reaching for one is the single most common misuse of a hash function in real applications.

What this tool is actually for

Hash generator computes an MD5, SHA-1, SHA-256, SHA-384, or SHA-512 digest of text you type or paste, live, entirely in your browser. It's built for the first job above - checksums, cache keys, matching a value a tutorial or a system already published - not the second. The how-to guide covers the actual steps, and this comparison goes through when MD5 is genuinely fine to use and when SHA-256 is the safer default.