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

Cryptographic hash functions underpin almost everything in modern software security. They protect code signatures, verify file downloads, power Bitcoin’s proof-of-work, and secure TLS certificates. Yet two of the three most-used algorithms, MD5 and SHA-1, are cryptographically broken. Researchers demonstrated MD5 collisions in 2004 (Wang & Yu, CRYPTO 2004), and Google’s SHAttered attack produced the first SHA-1 collision in 2017 (Stevens et al., Google/CWI Amsterdam, 2017).

Knowing which algorithm to reach for, and which ones to stop using entirely, matters now more than ever. This guide breaks down each algorithm, explains what “cryptographically broken” actually means in practice, and tells you exactly when each one is appropriate.

developer tools

Key Takeaways

MD5 is cryptographically broken for security use since 2004, but remains safe for non-security checksums.
SHA-1 collisions were demonstrated in 2017 (SHAttered attack). Major certificate authorities stopped issuing SHA-1 certificates that same year.
SHA-256 is the current standard: used in Bitcoin, TLS 1.3, code signing, and NIST-approved applications.
Never use MD5 or SHA-1 for passwords, digital signatures, or certificates. Use bcrypt or Argon2 for passwords.
BLAKE3 (2020) is the fastest modern alternative, outperforming SHA-256 on most hardware.

Generate and Compare Hash Outputs Right Now

Paste any string below to see MD5, SHA-1, SHA-256, and SHA-512 outputs side by side. The length difference alone tells you a lot about each algorithm.

Try it Hash Generator

Uppercase output

Click to upload or drag and drop

Any file up to 100MB

Hashes

Waiting for input

Computing hashes in your browser...

Start typing to generate MD5, SHA-1, SHA-256, and SHA-512 hashes.

MD5 is included for compatibility and checksum workflows. For security-sensitive use cases, prefer the SHA-256 or SHA-512 outputs.

Open full tool

hash generator tool

What Is a Cryptographic Hash Function?

A cryptographic hash function takes any input and produces a fixed-length output called a digest, or hash. NIST defines four core properties in FIPS 180-4 (NIST, 2015): the output is fixed-length, the process is one-way (you can’t reverse it), it’s deterministic (same input always gives the same output), and even a one-bit change in the input produces a completely different hash.

That last property has a name: the avalanche effect. Change a single character in a document and every bit in the output flips, on average. This is what makes hashes useful for detecting tampering.

There are two properties attackers try to break. A “collision” means finding two different inputs that produce the same hash. A “preimage attack” means working backwards from a hash to find any matching input. Both attacks break the security guarantees completely.

character encoding and binary data

Citation capsule: NIST FIPS 180-4 defines cryptographic hash functions as one-way, deterministic functions with fixed-length output (NIST, 2015). The avalanche effect means any single-bit change in the input produces a completely different digest, enabling reliable tamper detection.

What Is MD5 and Why Is It Broken?

MD5 produces a 128-bit digest (32 hexadecimal characters). It was designed by Ron Rivest and published in 1992 (RFC 1321, IETF, 1992). For over a decade it was ubiquitous. Then in 2004, Xiaoyun Wang and Hongbo Yu demonstrated the first practical MD5 collision, finding two different inputs with identical hashes in under an hour on a standard PC (Wang & Yu, CRYPTO 2004).

That single result ended MD5’s usefulness for any security-critical purpose.

What MD5 collision attacks mean in practice

A collision means an attacker can craft a malicious file that produces the exact same MD5 hash as a legitimate one. They present the legitimate file for signing, then swap in the malicious version later. The hashes match. The signature validates. The tampered file appears authentic.

This isn’t theoretical. Researchers used MD5 collisions to forge a rogue CA certificate in 2008 (Sotirov et al., 2008), enabling them to impersonate any HTTPS website. The attack worked against live certificate infrastructure.

Where MD5 is still acceptable

MD5 and SHA-1 are cryptographically broken

Do not use MD5 or SHA-1 for digital signatures, certificate hashing, password storage, or any use case where an attacker could exploit a collision. Both algorithms have had practical collisions demonstrated against real-world infrastructure. For non-security tasks like file deduplication or checksums in a trusted environment, they’re still acceptable.

Citation capsule: Xiaoyun Wang and Hongbo Yu demonstrated the first practical MD5 collision in 2004, finding two different inputs with identical 128-bit hashes in under an hour on a standard desktop computer (Wang & Yu, CRYPTO 2004). This broke MD5 for all security-critical applications.

What Is SHA-1 and When Was It Deprecated?

SHA-1 produces a 160-bit digest (40 hexadecimal characters). NIST published it in 1995 as part of the Secure Hash Standard (FIPS 180-1, NIST, 1995). It replaced MD5 in many security applications and dominated TLS certificates throughout the 2000s and early 2010s. The CA/Browser Forum required all publicly trusted certificate authorities to stop issuing SHA-1 certificates by January 1, 2017.

That deadline came just in time. On February 23, 2017, a team from Google and CWI Amsterdam published SHAttered, the first known SHA-1 collision in history (Stevens et al., 2017). Two distinct PDF files, different content, identical SHA-1 hashes. The attack required approximately 9.2 quintillion SHA-1 computations and ran on Google’s infrastructure.

SHA-1 in Git

Git still uses SHA-1 as its default object identifier. Every commit hash, tree hash, and blob hash you’ve ever seen in a Git repository is a SHA-1 digest. This is a known architectural limitation. The Git project has been migrating to SHA-256 since version 2.29 (Git, 2020), but the transition is still in progress and most repositories remain SHA-1 based.

The practical risk in Git is lower than in certificate contexts. Git’s usage is not a signature scheme, and the attack vectors differ. But the migration is the right direction.

SSL and TLS certificates explained

Citation capsule: Google and CWI Amsterdam researchers published the SHAttered attack on February 23, 2017, producing the first known SHA-1 collision (Stevens et al., 2017). The attack required 9.2 quintillion SHA-1 computations. The CA/Browser Forum had already required certificate authorities to stop issuing SHA-1 certificates by January 2017.

What Is SHA-256 and Why Is It the Current Standard?

SHA-256 produces a 256-bit digest (64 hexadecimal characters). It belongs to the SHA-2 family, published by NIST in 2001 and standardized in FIPS 180-4 (NIST, 2015). No collision has ever been found. As of 2026, SHA-256 is the algorithm of choice for TLS certificates, code signing, software package verification, and Bitcoin’s proof-of-work mining function.

SHA-256’s security margin is substantial. Its 256-bit output means there are 2^256 possible digests. Exhausting even a fraction of that space is computationally infeasible with any hardware that exists or is expected to exist, even accounting for quantum computing with current projections.

SHA-256 in Bitcoin

Bitcoin’s proof-of-work uses double SHA-256 (SHA-256 applied twice) to hash block headers. Miners must find an input whose double SHA-256 output starts with a required number of leading zeroes. As of 2024, the Bitcoin network performs approximately 600 exahashes per second (Blockchain.com, 2024), meaning 600 quintillion SHA-256 computations every second. No collision or preimage attack has emerged under this industrial-scale pressure.

SHA-256 vs SHA-224

SHA-224 is a truncated variant of SHA-256 with a different initialization vector, producing a 224-bit output. It offers a smaller digest for constrained environments while inheriting SHA-256’s security properties. NIST includes both in FIPS 180-4. For most applications, SHA-256 is the better default.

password hashing and security

Citation capsule: SHA-256 is NIST-approved under FIPS 180-4 and has no known collision vulnerabilities (NIST, 2015). Bitcoin’s proof-of-work runs double SHA-256 at approximately 600 exahashes per second globally (Blockchain.com, 2024), placing SHA-256 under extraordinary real-world pressure with zero successful attacks.

How Do SHA-256, SHA-512, MD5, and SHA-1 Compare?

Here’s the full side-by-side comparison including SHA-512 and BLAKE3. Security status, output size, speed, and appropriate use cases all differ significantly between these algorithms.

Algorithm	Output Size	Security Status	Relative Speed	Best Use Case
MD5	128 bits / 32 hex chars	Broken (collisions since 2004)	Fastest	Non-security checksums only
SHA-1	160 bits / 40 hex chars	Broken (collision 2017)	Fast	Legacy systems, Git (deprecated)
SHA-256	256 bits / 64 hex chars	Secure (no known attacks)	Moderate	TLS, code signing, certificates
SHA-512	512 bits / 128 hex chars	Secure (no known attacks)	Faster than SHA-256 on 64-bit	Large data, 64-bit hardware
BLAKE3	256 bits (variable) / 64 hex chars	Secure (no known attacks)	Fastest modern option	High-throughput hashing, new projects

SHA-512: bigger output, often faster

SHA-512 might seem slower because of its larger 512-bit output. On 64-bit CPUs, it’s actually faster than SHA-256 for large inputs. SHA-512 processes data in 64-bit word operations, which maps directly to modern 64-bit processor registers. On 32-bit hardware or small microcontrollers, SHA-256 wins. For server-side applications on any modern x86-64 machine, SHA-512 is worth considering for bulk data hashing.

BLAKE3: the fast modern alternative

BLAKE3 was released in 2020 by Jack O’Connor, Jean-Philippe Aumasson, Samuel Neves, and Zooko Wilcox-O’Hearn (BLAKE3 team, 2020). It’s parallelizable by design, meaning it uses all available CPU cores. On multi-core hardware, BLAKE3 outperforms SHA-256 by 3-10x on large inputs. It has a strong security proof and is used in projects including the Zig compiler and Bao content-addressed storage. NIST has not yet standardized BLAKE3, so it’s not appropriate for FIPS-regulated environments.

Should You Use MD5 or SHA-1 for Password Storage?

No, never. Not MD5. Not SHA-1. Not SHA-256 either. All three are the wrong tool for passwords. Fast hash functions are a liability for password storage because attackers can test billions of guesses per second. A single NVIDIA RTX 4090 cracks MD5-hashed passwords at 165 billion attempts per second (Hashcat Benchmarks, 2024).

Password hashing requires deliberately slow algorithms that are designed to resist brute-force attacks. The right options are:

bcrypt - intentionally slow, adjustable work factor, widely supported. Default choice for most web applications.
scrypt - memory-hard, more resistant to GPU/ASIC acceleration than bcrypt.
Argon2 - winner of the Password Hashing Competition (PHC, 2015), the current recommendation from OWASP and NIST SP 800-63B (NIST, 2020). Three variants: Argon2d, Argon2i, Argon2id (use Argon2id for most cases).

Password hashing rule of thumb

If your hashing function completes in under 1 millisecond, it’s too fast for passwords. bcrypt with work factor 12 takes roughly 250ms, which is acceptable for logins and punishing for bulk cracking. Set your work factor so hashing takes 100-300ms on your server hardware.

password cracking times and brute force math

Citation capsule: A single RTX 4090 GPU cracks MD5-hashed passwords at 165 billion attempts per second (Hashcat Benchmarks, 2024). NIST SP 800-63B recommends Argon2, bcrypt, or scrypt for password storage (NIST, 2020). General-purpose hash functions like SHA-256, no matter how secure, are unsuitable for passwords because of their speed.

Which Hash Algorithm Should You Choose?

The right algorithm depends entirely on what you’re protecting and the threat model you’re working against. Here’s a direct decision guide.

For digital signatures and certificates

Use SHA-256 or SHA-384. NIST SP 800-131A (NIST, 2019) disallows SHA-1 for digital signatures as of 2014 and has deprecated MD5. The CA/Browser Forum requires SHA-256 minimum for all public TLS certificates. If you’re signing code, packages, or documents, SHA-256 is the baseline, SHA-384 if you need a higher security margin.

For file integrity verification and checksums

SHA-256 is the safe default. MD5 and SHA-1 checksums still appear in software distribution (Linux package managers, older download pages) and are fine in that context because you’re not defending against an adversary who controls the upstream file. You’re just checking for transmission errors. But SHA-256 has become the standard even here, and there’s no reason to use MD5 for new systems.

For high-throughput hashing in new projects

BLAKE3. It’s faster than MD5 on modern multi-core hardware while providing full cryptographic security. Use it for content-addressed storage, large file deduplication, or any performance-sensitive hashing that isn’t bound to FIPS compliance.

For FIPS-regulated environments

SHA-256, SHA-384, or SHA-512 (FIPS 180-4), or SHA-3 (FIPS 202). BLAKE3 is not NIST-approved. SHA-3 (Keccak) is the NIST-standardized alternative to SHA-2, published as FIPS 202 (NIST, 2015). It uses a completely different internal construction (sponge construction vs. Merkle-Damgard), which means vulnerabilities in SHA-2’s structure wouldn’t automatically affect SHA-3.

Frequently Asked Questions

Is MD5 safe for file checksums in 2026?

MD5 is safe for detecting accidental corruption, like verifying a downloaded ISO matches what the server sent. It’s not safe if an attacker could substitute a malicious file with the same MD5 hash. For most checksum use cases (download verification, change detection in trusted pipelines), MD5 works fine. For anything adversarial, use SHA-256.

Why does Git still use SHA-1 if it’s broken?

Git’s SHA-1 usage predates the SHAttered attack, and migrating a distributed version control system’s object model is a massive compatibility challenge. The Git project started the SHA-256 migration in version 2.29 (Git, 2020), but most hosting platforms and tooling still default to SHA-1. The collision risk in Git’s specific threat model is lower than in certificate contexts, but the migration is the right call.

What’s the difference between SHA-2 and SHA-3?

SHA-2 is a family (SHA-224, SHA-256, SHA-384, SHA-512) designed by the NSA, standardized by NIST in FIPS 180-4. SHA-3 is a separate algorithm (Keccak), designed by Bertoni, Daemen, Peeters, and Van Assche, standardized by NIST in FIPS 202 (NIST, 2015) after a public competition. They’re both secure and NIST-approved. SHA-3 uses a sponge construction that differs fundamentally from SHA-2, providing a hedge against any structural weakness in Merkle-Damgard designs.

Can quantum computers break SHA-256?

Grover’s algorithm gives quantum computers a quadratic speedup on brute-force search, effectively halving the security level. A 256-bit hash drops to roughly 128 bits of effective security against a quantum attacker, which still remains computationally infeasible with any foreseeable hardware. SHA-256 is considered quantum-resistant for the near term. SHA-384 or SHA-512 provide larger margins if that’s a concern.

Should I migrate from SHA-1 in Git right now?

If you’re maintaining a public open-source project, check whether your hosting platform supports SHA-256 repositories (GitHub does not yet as of early 2026). For new private repositories, Git’s --object-format=sha256 flag is available since version 2.29. For existing repositories, migration tooling is still maturing. The risk in a typical codebase is low enough that there’s no urgent need to migrate before tooling stabilizes.

The Bottom Line

Hash algorithm choice is one of the easier security decisions once you know the history. MD5 and SHA-1 are broken for security use. The research is settled, the real-world attacks happened, and there’s no reason to use them in new systems for signatures, certificates, or any adversarial context.

SHA-256 is the right default for the vast majority of use cases. It’s NIST-approved, battle-tested, and supported by every platform. Use SHA-512 when you’re on 64-bit hardware and hashing large volumes. Use BLAKE3 when you need maximum speed in non-FIPS environments. And use bcrypt, scrypt, or Argon2id when you’re hashing passwords.

explore all developer tools