MD5 vs SHA-256: How Hashing Works (and Why MD5 Is Broken)

A cryptographic hash function turns any input - a password, a file, a whole disk image - into a short, fixed-length string of characters called a digest. The same input always gives the same digest, but you cannot work backwards from the digest to the original. This guide explains how hashing works, why the popular MD5 and SHA-1 algorithms are now considered broken, when SHA-256 is the right choice, and the one mistake almost everyone makes: hashing passwords with a plain, fast hash. You can try any of these algorithms on real text in the Hash Generator.

What is a hash function?

A cryptographic hash function takes data of any size and produces a digest of a fixed length. MD5 always outputs 128 bits (32 hex characters); SHA-256 always outputs 256 bits (64 hex characters), no matter whether you feed it one letter or a gigabyte. Good hash functions share four properties:

• One-way (irreversible): given a digest, there is no practical way to recover the input.
• Deterministic: the same input always produces the same digest, every time, on every machine.
• Fixed-length: the output size is constant regardless of input size.
• Avalanche effect: changing a single bit of the input changes roughly half the output bits, so the new digest looks completely unrelated.

They are also fast to compute - which is excellent for checking files but, as we will see, a serious problem for passwords.

The avalanche effect in action

The avalanche effect is what makes a hash useful for spotting tampering. Hashing the word "hello" with SHA-256 gives 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. Hashing "Hello" - just one capital letter different - gives 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969. There is no resemblance between the two outputs. That is why even a tiny change to a downloaded file produces a totally different checksum, instantly revealing corruption or interference.

Hashing is not encryption

This is the most common confusion. Encryption is a two-way process: you encrypt plaintext with a key, and someone with the right key can decrypt it back to the original. Hashing has no key and no reverse operation. There is no "unhash" function and no secret that turns a digest back into its input - the information needed to reconstruct the original is simply gone. So if a tool claims to "decrypt" an MD5 hash, it is not reversing anything; it is guessing inputs, hashing each one, and checking for a match. Hash when you need to verify or fingerprint data; encrypt when you need to get the original back later.

Why MD5 and SHA-1 are broken

A hash function's core security promise is collision resistance: it should be infeasible to find two different inputs that produce the same digest. Both MD5 (128-bit) and SHA-1 (160-bit) have failed this test, and not just in theory.

• MD5 collisions can be generated in seconds on an ordinary laptop. Attackers have used this to forge digital certificates and craft malicious files that share a hash with a benign one.
• SHA-1 was broken in practice in 2017, when researchers produced two different PDF files with the same SHA-1 digest (the "SHAttered" attack), and cheaper attacks have followed.

Because of this, MD5 and SHA-1 must never be used for anything security-related: digital signatures, TLS certificates, code signing, or verifying that a file came from a trusted source. They remain acceptable only as non-security checksums - for example, detecting accidental disk or network corruption, or as fast keys for deduplication, where no attacker is trying to engineer a collision.

SHA-256 and the SHA-2 family

SHA-256 is part of the SHA-2 family (which also includes SHA-224, SHA-384 and SHA-512) and produces a 256-bit digest. It has no known practical collision or preimage attacks and is currently considered secure for general cryptographic use. You will find SHA-256 working quietly everywhere: in TLS certificates that secure HTTPS connections, in software and code signing, in Git's newer object format, in the proof-of-work that underpins Bitcoin, and in trustworthy file-integrity checks. When you need a hash for security in 2026, SHA-256 (or SHA-512 for extra margin) is the sensible default. You can compare MD5, SHA-1 and SHA-256 outputs side by side for the same input in the Hash Generator.

Common uses for hashing

Outside of passwords, cryptographic hashes solve a handful of everyday problems:

• File integrity and checksums: a download site publishes the SHA-256 of a file; you hash your copy and compare. If the digests match, the file is intact and unaltered.
• Deduplication: storage systems hash each chunk of data and store identical chunks only once, since matching digests mean matching content.
• Digital signatures: rather than sign a large document directly, software signs its hash. This is exactly why the underlying hash must be collision-resistant - if two documents share a digest, one signature would validate both.
• Content addressing: systems like Git name objects by their hash, so the identifier itself proves the content has not changed.

Why you should not hash passwords with a plain hash

Here is the critical point. The very things that make SHA-256 great for file checks - it is fast and, used plainly, has no salt - make it dangerous for storing passwords. Speed is the enemy: a modern GPU can compute billions of SHA-256 hashes per second, so an attacker who steals your database can brute-force common and weak passwords almost instantly. And because plain hashing involves no salt, identical passwords produce identical digests, which lets attackers use precomputed rainbow tables to look up common inputs without any guessing at all. Remember, you can never "reverse" a hash - but you do not have to when guessing is this cheap.

The fix is to use a slow, salted key-derivation function (KDF) built specifically for passwords:

• bcrypt, scrypt, or Argon2 - all are deliberately slow and have a tunable work factor, so you can make each guess cost real time and memory.
• A unique random salt per password - stored alongside the hash - so two users with the same password get completely different stored values, which defeats rainbow tables entirely.
• Argon2 (specifically Argon2id) is the current recommended choice for new systems; bcrypt remains a solid, widely supported option.

In short: never store passwords as plain SHA-256 or MD5. Use Argon2, bcrypt or scrypt with a per-user salt.

Quick decision guide

To pick the right tool: use SHA-256 for file integrity, digital signatures and any security check; treat MD5 and SHA-1 as non-security checksums only, never for signatures or certificates; and use Argon2, bcrypt or scrypt with a salt for passwords. If you just need to fingerprint some text or verify a file, paste it into the Hash Generator to see its MD5, SHA-1 and SHA-256 digests instantly - and if you instead need to convert data to and from a transport-safe text format, that is encoding, not hashing, which is what the Base64 Encoder / Decoder is for.