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

MD5 and SHA-256 both turn any input into a fixed-length fingerprint — but treating them as interchangeable is one of the most common security mistakes in software. One of them is cryptographically broken; the other underpins Bitcoin, TLS certificates and modern software signing. Here is the practical difference, and which one to use for each job.

What a hash function actually promises

A cryptographic hash makes three promises: the same input always produces the same output (deterministic), you cannot work backwards from the output to the input (pre-image resistance), and — critically — you cannot find two different inputs that produce the same output (collision resistance).

MD5 outputs 128 bits (32 hex characters). SHA-256, part of the SHA-2 family, outputs 256 bits (64 hex characters). The length difference matters, but it is not the real story.

Why MD5 is considered broken

MD5’s collision resistance collapsed in 2004, when researchers demonstrated two different inputs hashing to the same value. Today, generating an MD5 collision takes seconds on a laptop. That has real consequences:

• An attacker can craft a malicious file with the same MD5 as a legitimate one, defeating integrity checks.
• Forged certificates using MD5 collisions were demonstrated in practice (the Flame malware abused exactly this).
• No standards body considers MD5 acceptable for signatures, certificates or password storage.

SHA-256 has no known practical collision attack. Brute-forcing it would require on the order of 2¹²⁸ operations — beyond any conceivable hardware.

So is MD5 useless?

Not quite — it survives in non-security roles where speed matters and no attacker is in the picture:

• Change detection / cache keys. Deciding whether a file changed between two of your own systems.
• Deduplication. Bucketing identical files in storage you control.
• Legacy checksums. Some download mirrors still publish MD5 sums; verifying them is better than nothing, but insist on SHA-256 where offered.

The rule: if a malicious actor could benefit from forging a collision, MD5 is disqualified. If it is just you detecting accidental change, MD5 is fine and fast.

Where SHA-256 is the right answer

• File integrity for downloads — verifying an installer matches the vendor’s published checksum.
• Digital signatures and certificates — the backbone of TLS.
• API request signing (HMAC-SHA256) — authenticating webhooks and API calls.
• Blockchain and content addressing — Bitcoin, Git (migrating from SHA-1), IPFS.

You can generate and compare both instantly with our free Hash Generator — it computes MD5, SHA-1, SHA-256 and SHA-512, plus Base64, JWTs and HMAC-SHA256, entirely in your browser. Paste text or drop a file; nothing is uploaded, which is exactly what you want when the input is sensitive.

The special case everyone gets wrong: passwords

Here is the twist — neither MD5 nor SHA-256 should hash passwords directly. Both are designed to be fast, and fast is fatal for password storage: a modern GPU computes billions of SHA-256 hashes per second, tearing through leaked databases with dictionary attacks. Passwords need deliberately slow, salted algorithms: bcrypt, scrypt or Argon2, which are tunably expensive to brute-force.

So: SHA-256 for integrity and signatures, Argon2/bcrypt for passwords, MD5 only for casual change-detection. For encrypting data (rather than fingerprinting it), see our AES encryption tool — hashing and encryption are different jobs, and our hash generator guide explains the distinction in depth.

Quick decision table

Task	Use
Verify a downloaded file	SHA-256
Sign API requests / webhooks	HMAC-SHA256
Store passwords	Argon2 / bcrypt (never plain MD5 or SHA-256)
Detect accidental file changes internally	MD5 or SHA-256
Anything an attacker could forge	SHA-256

Bottom line: default to SHA-256 everywhere security matters, keep MD5 only for harmless bookkeeping, and never hash passwords with either.