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

A hash function is a one-way mathematical operation. Feed it any input — a single character, a 4 GB video, a password — and you get back a fixed-size digest. The same input always produces the same digest. Change even one bit of the input and the output changes completely (the avalanche effect).

This is not encryption. Encryption is reversible: you encrypt with a key and decrypt with a key. Hashing is irreversible by design. You cannot "decrypt" a hash; you can only try inputs and compare digests. That distinction matters enormously for password storage — storing an encrypted password is dangerous because anyone who obtains the key can decrypt it. A hash has no key to steal.

Three properties define a secure hash function:

• Pre-image resistance — given a digest, it must be infeasible to find any input that produces it.
• Second pre-image resistance — given an input, it must be infeasible to find a different input with the same digest.
• Collision resistance — it must be infeasible to find any two distinct inputs that produce the same digest.

MD5 was designed in 1991 and was considered strong for its era. By 2004, researchers demonstrated practical collisions — two different inputs producing identical MD5 digests. By 2008, a team forged a rogue SSL certificate using MD5 collisions. The algorithm is cryptographically dead for security purposes.

Specifically, MD5 fails collision resistance. An attacker with modest hardware can generate a collision in seconds. This makes MD5 unsuitable for:

• Digital signatures (an attacker can swap a signed document for a malicious one with the same hash)
• Certificate fingerprints
• Password storage (even ignoring collisions, its speed makes brute-force trivial — modern GPUs can compute billions of MD5 hashes per second)

Where MD5 remains perfectly acceptable:

• Non-security checksums — verifying a file download was not corrupted in transit (where the threat model is accidental corruption, not an active attacker)
• Cache keys and content-addressed lookups — uniqueness is likely even if not guaranteed; speed matters
• Deduplication in internal systems — same reasoning

The key question: Does it matter if an attacker can craft a collision? If yes, do not use MD5. If you only care about accidental corruption, MD5 is fast and fine.

SHA-256 is part of the SHA-2 family, standardized by NIST in 2001. It produces a 256-bit digest and, as of 2025, has no known practical collision attacks. The SHA-2 family also includes SHA-224, SHA-384, and SHA-512, differing only in output size and internal word length. SHA-256 is the right default for most applications.

SHA-256 is still fast — a modern CPU can hash hundreds of megabytes per second, and a GPU can compute hundreds of millions of SHA-256 hashes per second. That speed is great for file integrity checks and terrible for password storage (more on that below).

SHA-3 (Keccak) is the newest NIST standard, using a completely different internal structure (sponge construction vs. Merkle-Damgård). It is not faster than SHA-256 in software but provides structural diversity — if a theoretical flaw were ever found in SHA-2's construction, SHA-3 would not share it. For new projects with no constraints, SHA-256 is still the pragmatic pick; SHA-3 is a reasonable alternative if you want future-proofing.

SHA-256 is cryptographically strong, but it was designed for speed. That is exactly the wrong property for a password-hashing function. An attacker who obtains your password database can try billions of guesses per second against a SHA-256 hash on commodity hardware. A single RTX 4090 can attempt roughly 10 billion SHA-256 operations per second.

The correct tools for password storage are purpose-built slow hashing algorithms:

• bcrypt — deliberately slow, has a cost factor you can increase as hardware improves, widely supported, battle-tested since 1999. A cost factor of 12 takes ~300ms per hash on modern hardware — acceptable for login, brutal for an attacker running billions of guesses.
• Argon2 (winner of the 2015 Password Hashing Competition) — configurable time cost, memory cost, and parallelism. Memory-hardness is its key advantage: it requires large amounts of RAM per hash attempt, which limits how many guesses an attacker can run simultaneously even on GPU clusters. Argon2id is the recommended variant.
• scrypt — also memory-hard, older than Argon2, still widely used.

These functions also handle salting automatically. A salt is a random value unique to each user, prepended to the password before hashing. Without salts, identical passwords produce identical hashes, which allows attackers to precompute a lookup table (a rainbow table) of common passwords. With a 16-byte random salt, precomputation becomes infeasible. bcrypt and Argon2 generate and store the salt in the output string — you do not need to manage it separately.

The practical rule: never store passwords with MD5, SHA-1, SHA-256, or any general-purpose hash, salted or not. Use bcrypt with cost ≥ 10, or Argon2id with at minimum 64 MB memory and 3 iterations.

Here is how to choose a hash function for common tasks:

1. Verifying a file download or backup integrity — SHA-256 is the modern standard; you will see it on most Linux distro download pages. MD5 is still acceptable if the site only offers that, since the threat is accidental corruption, not adversarial tampering.
2. Generating a unique key for caching or deduplication — SHA-256 is fast enough and collision-free in practice. MD5 works but there is no compelling reason to choose it for new code.
3. Digital signatures, certificates, code signing — SHA-256 minimum. SHA-384 or SHA-512 for high-value systems. Never MD5 or SHA-1.
4. HMAC (message authentication codes) — HMAC-SHA256 is the standard choice for API authentication tokens and webhook signature verification.
5. Password storage — Argon2id if your runtime supports it; bcrypt otherwise. No general-purpose hash function, ever.
6. Checksums inside a document or data format you control — SHA-256 for anything new; CRC32 if you need speed over security and the standard already uses it.

When in doubt, SHA-256 is the safe default for everything except password storage. It is fast, well-understood, hardware-accelerated on modern CPUs (via the SHA-NI instruction set), and has no known weaknesses.

The hash generator tool on this site lets you compute MD5, SHA-1, SHA-256, SHA-384, SHA-512, and other digests instantly in your browser. No data is sent to a server — the hashing runs locally in JavaScript using the Web Crypto API for SHA variants and a native implementation for MD5. This makes it safe to test with real file names, configuration strings, or API tokens you want to verify.

Typical workflows where it is useful:

• Pasting a downloaded file's expected SHA-256 checksum from a vendor page and computing the hash of your local copy to confirm they match.
• Generating a SHA-256 hash of a string to use as a cache key or ETag value during development.
• Quickly checking whether two strings are identical without comparing them character by character (if their hashes match, they are the same).
• Exploring how the avalanche effect works: hash hello, then hash Hello and observe that the outputs share no obvious pattern despite a single-character change.