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

If you're choosing a hash algorithm — for file integrity, API signatures, TLS, password storage, or anything else — you've probably encountered MD5, SHA-1, SHA-256, and SHA-512. They sound similar, they all produce hex strings, but they are not interchangeable. Some are broken. Some are deprecated by NIST. And one common misconception leads developers to use the wrong tool entirely.

This guide breaks down each algorithm: what it produces, where it's still appropriate, where it isn't, and how to make the right choice for your use case.

What Is a Cryptographic Hash Function?

A cryptographic hash function takes input of any size and produces a fixed-size output called a digest or hash. Four properties define a secure cryptographic hash:

1. Deterministic — the same input always produces the same output
2. One-way (preimage resistance) — given the output, you cannot reconstruct the input
3. Avalanche effect — changing one bit of input changes roughly half the output bits
4. Collision resistance — it should be computationally infeasible to find two inputs that produce the same output

When collision resistance breaks down, an algorithm is considered cryptographically broken — even if it's still fast and deterministic.

MD5 — Fast, Ubiquitous, and Broken

MD5 (Message Digest 5) was designed by Ron Rivest in 1991. It produces a 128-bit (32 hex character) digest.

echo -n "hello" | md5sum
# 5d41402abc4b2a76b9719d911017c592

The problem with MD5: Collision attacks have been publicly known since 2004. In 2008, researchers demonstrated that MD5 collisions could be used to create fraudulent SSL certificates. MD5 is no longer considered collision-resistant.

Where MD5 is still used (legitimately):

• Non-security checksums for detecting accidental data corruption (not tampering)
• Legacy database password fields (though this is a migration problem, not a design choice)
• File deduplication where security is not a concern
• Generating cache keys in non-adversarial contexts

Where MD5 must not be used:

• Digital signatures
• SSL/TLS certificate fingerprints (deprecated by all major CAs)
• Any context where a collision would be harmful
• Password hashing (use bcrypt, Argon2, or scrypt instead)

NIST deprecated MD5 for all federal uses in 2012. Any system you build today should not introduce new MD5 usage.

SHA-1 — Deprecated but Still Everywhere

SHA-1 (Secure Hash Algorithm 1) was designed by the NSA and published by NIST in 1995. It produces a 160-bit (40 hex character) digest.

echo -n "hello" | sha1sum
# aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d

SHA-1 was the internet's workhorse for over a decade — used in SSL/TLS, SSH, PGP, Git, and code signing.

The collision problem: Theoretical weaknesses were identified by Wang et al. in 2005. In 2017, Google's Project Zero published SHAttered — the first real-world SHA-1 collision, producing two different PDF files with the same SHA-1 hash. The attack cost approximately $110,000 in cloud computing at the time of publication. By 2020, it was within reach of a well-funded attacker.

NIST formally deprecated SHA-1 in 2011 and disallowed it for generating digital signatures after 2013.

Where SHA-1 persists (and what to do about it):

• Git: Git uses SHA-1 for commit, tree, and blob hashes. This is a known issue — Linus Torvalds has noted that Git doesn't require collision resistance for its security model (it uses SHA-1 as a content address, not a security guarantee). Git is migrating to SHA-256 (git's experimental --object-format=sha256), but the ecosystem hasn't fully moved. For most Git users: not a practical concern, but watch for progress.
• Legacy TLS certificates: All major browsers stopped accepting SHA-1 signed certificates in 2017. If you see SHA-1 in a certificate fingerprint today, that cert needs to be replaced.
• Old SSH host keys: Some older servers still use SHA-1 in their RSA key fingerprints. These should be migrated to ED25519 or ECDSA.

SHA-256 — The Modern Standard

SHA-256 is part of the SHA-2 family, published by NIST in 2001. It produces a 256-bit (64 hex character) digest.

echo -n "hello" | sha256sum
# 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

SHA-256 is the algorithm you should use for the vast majority of hashing tasks today. It's:

• Collision-resistant — no known practical collision attacks
• NIST-approved — recommended for use through 2030 and beyond (as of current NIST SP 800-131A)
• Hardware-accelerated — most modern CPUs have SHA-NI instructions that make SHA-256 extremely fast
• Universally supported — every cryptographic library, OS, and language runtime includes SHA-256

Where SHA-256 is the right choice:

• File integrity verification (checksums, manifests)
• Digital signatures (as the hash in RSA-SHA256, ECDSA-SHA256)
• HMAC-SHA256 for API request signing and webhook verification
• TLS 1.2 and 1.3 handshakes
• Certificate fingerprints
• Bitcoin proof-of-work (double SHA-256)
• Merkle trees in blockchain and version control
• JWT signatures using HS256 or RS256

import hashlib

data = b"hello"
digest = hashlib.sha256(data).hexdigest()
print(digest)
# 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

// Node.js
const crypto = require('crypto');
const hash = crypto.createHash('sha256').update('hello').digest('hex');
console.log(hash);
// 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

SHA-512 — When to Go Bigger

SHA-512 is also in the SHA-2 family. It produces a 512-bit (128 hex character) digest.

echo -n "hello" | sha512sum
# 9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca72323c3d99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043

SHA-512 is not "twice as secure" as SHA-256 in any practical sense. Both are currently unbroken. The difference is mostly architectural:

• SHA-512 uses 64-bit word operations. On 64-bit CPUs, it can actually be faster than SHA-256 for large inputs because it processes more data per operation. On 32-bit hardware, SHA-512 is significantly slower.
• Larger output — if you need more than 256 bits of output (unusual), SHA-512 gives it to you natively
• SHA-512/256 is a truncated variant that uses SHA-512 internals but outputs 256 bits — it can be faster than SHA-256 on 64-bit machines while maintaining the same output size

When SHA-512 makes sense:

• Password-derived key generation where you want maximum entropy (though Argon2 is better for passwords)
• Applications running on 64-bit servers processing large files (SHA-512 may outperform SHA-256)
• Systems that need to match an existing standard requiring SHA-512 (some banking/government protocols)
• When regulatory requirements specify it

For most applications, SHA-256 and SHA-512 are equivalent in security. Choose SHA-256 as the default.

Head-to-Head Comparison

Which Algorithm Should You Use?

For file integrity and checksums

Use SHA-256. It's the standard for software distribution checksums (e.g., sha256sum in Linux, Windows Get-FileHash). Some projects also publish SHA-512 checksums — either is fine, SHA-256 is more interoperable.

# Generate a SHA-256 checksum
sha256sum large-file.iso > large-file.iso.sha256

# Verify
sha256sum --check large-file.iso.sha256

For digital signatures

Use SHA-256 as the hash component. Most signature schemes are specified as RSA-SHA256, ECDSA-SHA256, or Ed25519 (which uses SHA-512 internally). Never use MD5 or SHA-1 for new signatures.

For HMAC / API request signing

Use HMAC-SHA256. It's the standard for AWS Signature V4, GitHub webhooks, Stripe webhook validation, and most modern APIs. HMAC-SHA512 is also secure, but HMAC-SHA256 is more common and universally supported.

For passwords

Don't use any of these directly. SHA-256 is too fast — an attacker with a GPU can compute billions of SHA-256 hashes per second, making brute-force trivial against common passwords.

Use a slow, password-specific algorithm instead:

• bcrypt — widely supported, self-tuning via cost factor, still the default for most web frameworks
• Argon2id — NIST's current recommendation (winner of the Password Hashing Competition), resistant to GPU and side-channel attacks
• scrypt — memory-hard, good alternative to Argon2 where Argon2 isn't available

For TLS certificates

SHA-256 is required. All certificates and signatures in TLS 1.2 and TLS 1.3 use SHA-256 or stronger. Any certificate using SHA-1 is rejected by modern browsers and needs to be reissued.

For legacy systems you're maintaining

If an existing system uses MD5 or SHA-1 in a non-security context (log fingerprints, cache keys, deduplication) and migration is expensive, you can leave it. But create a plan to migrate — especially if that system ever becomes security-sensitive.

Common Misconceptions

"SHA-256 can be decrypted." No. SHA-256 is a one-way function — there is no decryption. Sites that claim to "decrypt SHA-256" are using rainbow tables (precomputed hash→input lookup tables for common strings like passwords and phrases). If you hash a weak or common password, it can be looked up. If you hash arbitrary data, it cannot be reversed. This is why you must not use SHA-256 alone for passwords — combine it with a salt at minimum, or use bcrypt/Argon2.

"A longer hash is always more secure." Not necessarily. SHA-512 and SHA-256 are currently both unbroken. Choosing SHA-512 over SHA-256 for file checksums adds complexity without adding practical security today.

"MD5 is fine for non-security use." Mostly true, but it's becoming a habit problem. If developers see MD5 in a codebase, they may assume hashing is handled and add MD5 to a security-sensitive path. Using SHA-256 everywhere avoids this confusion.

"SHA-1 is broken so Git is insecure." Git's security model doesn't rely on collision resistance the same way TLS does. Git uses SHA-1 as a content identifier — an attacker would need commit access to submit a colliding object, at which point they've already compromised the repository. That said, Git is migrating to SHA-256, and new repositories can opt in today.

Generate Hashes Instantly

Use our online tools to generate SHA-256, SHA-512, SHA-1, and MD5 hashes without any software:

• SHA-256 Generator — file checksums, integrity verification
• SHA-512 Generator — high-entropy output
• SHA-1 Generator — legacy compatibility
• MD5 Generator — non-security checksums
• HMAC-SHA256 Generator — message authentication with a secret key

All processing happens in your browser — no data is sent to any server.

Key Takeaways

• MD5: broken for security, still usable for non-security checksums — don't introduce new MD5 usage
• SHA-1: deprecated, has real-world collisions — migrate away from it in any security context
• SHA-256: the correct default for nearly everything — checksums, signatures, HMAC, TLS
• SHA-512: not meaningfully more secure than SHA-256 today, but can be faster on 64-bit for large inputs
• Passwords: never use any SHA variant alone — use bcrypt, Argon2id, or scrypt
• "SHA-256 decrypt" is a misnomer — hashes are one-way, only rainbow tables can reverse weak inputs