MD5 vs SHA-1 vs SHA-256 vs SHA-3: When to Use Each Hash Function

Hash functions are the workhorse of modern cryptography. They back up every TLS connection, every password storage, every file integrity check, every blockchain. The choice between MD5, SHA-1, SHA-256, and SHA-3 is one of the most common questions in security work, and the answer is usually "use SHA-256, and here is when to use something else." This post covers what a hash is for, the four common choices, the speed vs. security trade-offs, the deprecation timeline, and the right one for each common use case.

What a hash function is for

A cryptographic hash function takes an input of any size (a file, a password, a message) and produces a fixed-size output (a "digest") with three properties:

1. Deterministic. The same input always produces the same output.
2. One-way. Given a digest, it is computationally infeasible to recover the input.
3. Collision-resistant. It is computationally infeasible to find two different inputs that produce the same digest.

The combination is what makes hashes useful for:

• File integrity. A website ships a file with its SHA-256 hash; the user verifies the hash after download to confirm the file was not modified in transit.
• Password storage. The system stores hash(password), not password. To verify a login, hash the entered password and compare. The hash means the system does not need to store the plaintext.
• Digital signatures. Sign the hash of a document, not the document itself. The signature is much smaller than the document, and the hash is what the recipient actually verifies.
• Blockchain and Merkle trees. Each block contains the hash of the previous block, creating the chain. Any modification to a past block breaks every subsequent hash.
• Content-addressed storage. The hash of a file is its address (Git, IPFS). The same file has the same hash, and a different file has a different hash.

For most of these uses, the same property matters: small changes in input produce large, unpredictable changes in output. A 1-bit flip in a 1 GB file produces a completely different SHA-256 hash, which is why hashes are good at detecting modification.

The four real-world choices

MD5 (1992, 128-bit output)

MD5 is the oldest of the four and the most broken. Practical collision attacks have existed since 2004, and chosen-prefix collisions (where the attacker constructs two files with the same MD5 but different content) are now routine. The implication: MD5 is not collision-resistant in any meaningful sense, and the one-way property is also weakened for short or common inputs (a single GPU can precompute MD5 of every 8-character alphanumeric password in hours).

What MD5 is still good for: non-security checksums, file dedup (you want to know if two files are the same, not whether they have been modified maliciously), and cache keys (the chance of an accidental collision in a cache key namespace is acceptable). For any security-sensitive use, MD5 is the wrong choice.

SHA-1 (1995, 160-bit output)

SHA-1 was the standard hash for a decade (TLS, PGP, Git, code signing). The first practical collision attack (SHAttered) was published in 2017, and chosen-prefix collisions are now feasible for well-funded attackers. Major browsers and certificate authorities deprecated SHA-1 between 2016 and 2018. Git uses SHA-1 for object addressing but is migrating to SHA-256 because the collision risk is now real.

What SHA-1 is good for: not much, in 2026. The only legitimate use is checking against legacy data that was hashed before 2017. For new systems, SHA-1 is the wrong choice.

SHA-256 (2001, 256-bit output, part of SHA-2)

SHA-256 is the modern workhorse. It is the hash of TLS 1.2, the hash of Bitcoin, the hash of most file integrity checks, the hash of most password storage when combined with a KDF (PBKDF2-HMAC-SHA256, Argon2). No practical collision attack exists; the internal structure has been extensively studied and is considered secure.

The 256-bit output also matters: even with a hypothetical breakthrough, the search space is large enough that brute force is impossible. A 256-bit hash has the same theoretical security as a 256-bit symmetric key (AES-256).

What SHA-256 is good for: most things. File integrity, password storage (with a KDF), digital signatures, blockchain, content addressing, certificate fingerprints. The default choice when in doubt.

SHA-3 (2015, variable output, Keccak)

SHA-3 is the modern alternative, selected by NIST after a public competition. It uses a completely different internal structure (sponge construction) from SHA-2, which is the main reason it exists: if a future attack breaks SHA-256, SHA-3 is a hedge. SHA-3 is slower than SHA-256 in software, but the security margin is wider and the design is cleaner.

What SHA-3 is good for: new designs that want the modern standard, or systems that want a hedge against future SHA-2 attacks. Adoption is still growing — TLS 1.3 supports SHA-3, and several cryptocurrencies use it. For most existing systems, migrating from SHA-256 to SHA-3 is not worth the effort unless you have a specific reason.

The speed vs. security trade-off

Different hashes are faster or slower, and the difference matters in some cases:

• MD5: Very fast (about 1 GB/s on a single CPU core). The speed is what made it popular for file integrity; the same speed is what made it easy to attack.
• SHA-1: Fast (about 500 MB/s on a single CPU core). Slower than MD5 but still fast.
• SHA-256: Medium (about 300 MB/s on a single CPU core). Hardware-accelerated on modern CPUs (Intel SHA extensions, ARMv8 SHA); 10x faster with the extensions.
• SHA-3: Slower (about 150 MB/s on a single CPU core). Not hardware-accelerated yet. For most uses, the speed difference is not a constraint.

For most use cases, the speed difference between SHA-256 and SHA-3 is irrelevant. The one case where it matters: a system that hashes millions of files per second (a large backup system, a deduplication engine). For those, SHA-256 with hardware acceleration is the right pick. For everything else, SHA-3 is also fine.

BLAKE2 and BLAKE3: the speed-focused alternatives

Two other hashes are worth knowing about:

• BLAKE2 (2012): Faster than SHA-256 in software, comparable security, simpler design. Used in some cryptocurrency mining (Equihash, Argon2 internally). Not as widely adopted as SHA-2.
• BLAKE3 (2020): Even faster than BLAKE2, parallelizable across cores, supports tree hashing for Merkle trees natively. Newer, less battle-tested than SHA-2, but the design is clean and the speed is unmatched in software.

For new designs that need speed (file integrity for large files, content addressing for high-throughput systems), BLAKE2 or BLAKE3 are worth considering. For most uses, SHA-256 is the safer choice because of its longer track record.

For passwords: never hash directly

A common mistake: storing SHA-256(password) directly in the user database. The problem: SHA-256 is fast. A modern GPU can compute billions of SHA-256 hashes per second. An attacker who steals the database can recover most user passwords by brute-forcing common passwords, dictionary words, and simple variations in under an hour.

The fix is a key-derivation function (KDF) that is intentionally slow and includes a salt. The two modern choices:

• PBKDF2 (with SHA-256). The older standard. The "iteration count" parameter makes the hash slow. Modern recommendation: 600,000 iterations for PBKDF2-SHA256 (OWASP 2023 guidance). At this count, a single password guess takes about 0.1 seconds on a GPU, so an attacker can test about 10 passwords per second per GPU. A 12-character random password is still infeasible.
• Argon2 (id variant). The newer standard, winner of the Password Hashing Competition. Three parameters: iteration count, memory cost, and parallelism. More resistant to GPU attacks because of the memory cost. Modern recommendation: Argon2id with 19 MiB memory, 2 iterations, 1 parallelism, 32-byte salt.

For new systems, Argon2id is the right choice. For existing systems with PBKDF2, the iteration count can be increased over time as hardware speeds up.

The Password Strength Checker scores any password locally; the Password Generator creates strong random passwords; the Hash Generator computes MD5, SHA-1, SHA-256, and SHA-512 for non-password uses (file integrity, content addressing). None of these tools upload anything; the input and the result stay in your browser.

The decision tree

For most cases, the right hash is obvious. The full decision tree:

• File integrity (downloading a file, verifying a backup): SHA-256. Default.
• Content addressing (Git, IPFS, deduplication): SHA-256. SHA-1 is still common in Git but is being phased out.
• Digital signature, certificate, blockchain: SHA-256. SHA-3 if you want the modern alternative.
• Password storage: Argon2id, with PBKDF2-SHA256 as a fallback for legacy systems. Never hash directly.
• Message authentication (HMAC): HMAC-SHA256. Default.
• Speed-critical hashing (millions per second): SHA-256 with hardware acceleration, or BLAKE2/BLAKE3 for software-only speed.
• Non-security checksum (cache key, dedup): MD5 or xxHash. Speed over collision resistance.
• New design that wants a SHA-2 hedge: SHA-3. Or BLAKE3 if speed also matters.

The decision is rarely hard. The two cases that get miscategorized: passwords (use Argon2id, not SHA-256) and content addressing in a security-sensitive context (use SHA-256, not MD5, because an attacker who can construct a chosen-prefix collision can substitute a malicious file with the same MD5).

How to use the Hash Generator

1. Open the Hash Generator.
2. Type or paste the text, or drop a file.
3. The tool computes MD5, SHA-1, SHA-256, and SHA-512 locally in the browser, and shows all four results.
4. Copy the one you need, or verify a downloaded file by comparing its hash to the publisher's hash.

The whole computation runs in your browser. The input and the results are never sent to a remote service. For most use cases (verifying a downloaded file, generating a content hash), this is the right tool.

The migration story for legacy systems

If you have an existing system that uses MD5 or SHA-1, the migration is straightforward but takes time:

1. Identify all uses of MD5 and SHA-1. The codebase search takes an afternoon for most systems.
2. Replace non-security uses with the new hash immediately. File integrity checks, content addresses, cache keys. No compatibility issues — old hashes can be re-computed lazily as the data is accessed.
3. Replace security uses with a planned migration. Password storage, digital signatures, certificate fingerprints. These need careful planning because the old hash may be relied on by other systems (clients, partners, archive files).
4. Set a sunset date for the old hash. Once all uses are migrated, remove the old hash code entirely. The risk of leaving legacy hash code in the codebase is that a new developer uses it without realizing it is deprecated.

For the most common case — passwords stored as MD5 or SHA-1 in a database — the migration is to add a new "password_hash_v2" column using Argon2id, force a password reset on next login, and verify the new hash. Once all users have logged in (or been forced to reset), drop the old column. The old hashes are then in a backup that ages out per the retention policy.

A short summary

• MD5: Legacy only. Non-security checksums, cache keys, dedup. Do not use for any security-sensitive purpose.
• SHA-1: Deprecated. Do not use for new systems. Plan a migration if your existing system uses it.
• SHA-256: Default. Most things. Battle-tested, hardware-accelerated, widely supported.
• SHA-3: Modern alternative for new designs. Slower in software, but a hedge against future SHA-2 attacks.
• Argon2id (for passwords): Required. Never use SHA-256 directly for password storage. Use a slow KDF with a per-user salt.

The decision is rarely hard. SHA-256 is the right answer 90% of the time. The remaining 10% is passwords (Argon2id) and edge cases (SHA-3, BLAKE2/BLAKE3). Use the Hash Generator for non-password uses, the Password Strength Checker for password scoring, and the Password Generator for creating new passwords. None of the tools upload anything; all three run in your browser.