What a Hash Actually Guarantees (and What It Doesn't)
"MD5 is broken" gets repeated so often that it's easy to assume every hash you've ever generated, every checksum, every stored password, is one search away from being cracked wide open. That's not quite what "broken" means here, and lumping hashing in with encryption (or, worse, with encoding) makes the fear much bigger than the actual risk. "Decrypt this hash" is a request that doesn't quite make sense. Hashing was never designed to be reversed in the first place. Here's what a hash function is actually built to guarantee.
The three properties a hash function is actually designed around
A cryptographic hash is built to be deterministic (the same input always produces the same output), to exhibit the avalanche effect (flipping even a single bit of input should scramble roughly half the output bits, a property formally tested for in hash function design), and to be one-way (computationally infeasible to reconstruct the input purely from the output). None of those three properties is about reversibility. They're about consistency, unpredictability, and one-directional computation.
Hashing is not encryption, and the difference matters
Encryption is explicitly designed to be reversed, with the right key. A hash function has no decrypt operation at all. It was never built to go backward. "Decrypting a hash" is a category error for exactly this reason: at best, an attacker can guess candidate inputs and check whether they happen to produce the same hash, or look the output up in a precomputed table of known hash values (a "rainbow table"). That's also precisely why password-hashing systems add a random per-user "salt" before hashing. It defeats precomputed-table attacks by making every user's hash unique even for an identical password.
It's also worth separating hashing from a third thing it sometimes gets mixed up with: encoding, like Base64. Encoding isn't security at all, it's just a reversible representation change, and anyone can decode it in one step with no key and no guessing required. Hashing (one-way, no key), encryption (two-way, needs a key), and encoding (two-way, needs no key) are three different tools solving three different problems, and "is this secure" has a different answer for each one.
MD5 and SHA-1's real, documented weakness
MD5 and SHA-1 are broken specifically for collision resistance. Researchers have demonstrated constructing two different inputs that hash to the identical output. The best-known public case is "SHAttered," a real 2017 SHA-1 collision jointly demonstrated by Google and CWI Amsterdam. That's a distinct property from reversibility: a collision attack finds *some* colliding input, not the specific original input behind a given hash, and it doesn't mean either algorithm can be reversed.
Why the collision weakness still matters in practice
Collision resistance specifically matters for use cases like digital signatures, where an attacker who can craft two different documents sharing one signature could substitute a malicious document for a legitimate signed one. It matters far less for something like a basic file-integrity checksum, which is why MD5 still shows up for quick checksums even though it's long been considered unsuitable for anything security-critical, SHA-256 and SHA-512 are the current standard where collision resistance genuinely matters.
What to actually do about it
If the goal is confirming a download wasn't corrupted in transit, any hash algorithm works, including MD5. Accidental corruption isn't a motivated attacker crafting a collision, so the broken property doesn't come into play. If the goal is something a motivated attacker could exploit by forging a matching hash, a digital signature, code signing, verifying a file from an untrusted source, use SHA-256 or SHA-512 and skip MD5 and SHA-1 entirely, since collision resistance is exactly what's been broken in both. And if the underlying worry is "can this hash be decrypted," the answer is no, by design, for any of them: the only way to test a guess against a hash is to hash the guess yourself and compare, which is why an unsalted hash (not the specific algorithm) is usually the real risk in a leaked password database.
Generate MD5, SHA-1, SHA-256, and SHA-512 hashes of your own text with the hash generator.