SHA-1 vs SHA-256 vs SHA-512: Choosing the Right Hash Algorithm in 2026
Open a TLS certificate, a Git object database, a Bitcoin block header, a Linux package manager, and a Docker image manifest — you will find a SHA hash in every one. But not the same SHA. SHA-1, SHA-256, SHA-384, SHA-512, SHA-3: the family spans three decades, two design lineages, and a pivotal collision attack that broke the oldest member in production.
This guide maps the entire family so you can pick the right algorithm for your use case without second-guessing yourself.
Quick Decision Tree
Before diving into the details, here is the one-table summary most developers actually need:
| Your Situation | Best Choice | Reason |
|---|---|---|
| TLS/HTTPS certificate | SHA-256 (minimum), SHA-384 for high-security | Mandated by CA/Browser Forum Baseline Requirements |
| JWT signing (HMAC or RSA) | SHA-256 (HS256/RS256) | Universal support; SHA-384/512 for compliance regimes |
| Software integrity checksum | SHA-256 | Industry default; widely understood |
| Archival or long-lived integrity | SHA-512 | Larger output, safe margin for the decades ahead |
| Content addressing (IPFS, OCI) | SHA-256 | De-facto standard for content-addressed storage |
| Git (reading/writing existing repos) | SHA-1 for existing; SHA-256 for new via --object-format=sha256 | Git is mid-migration; SHA-1 still dominates |
| Interoperating with Ethereum | Keccak-256 (not NIST SHA-3) | Ethereum uses the pre-standardization Keccak variant |
| Defense-in-depth or classified systems | SHA-384 or SHA-512 | NSA Suite B; pairs with AES-256-GCM |
| New code, no legacy constraints | SHA-3 (SHA3-256) | Different design lineage; no length-extension vulnerability |
| Password storage | None of the above | Use bcrypt, Argon2id, or scrypt — SHA is too fast |
The SHA Family at a Glance
| Algorithm | Standard | Output Bits | Hex Chars | Year | NIST Status | Primary Use Today |
|---|---|---|---|---|---|---|
| SHA-1 | FIPS 180-4 | 160 | 40 | 1995 | Deprecated (2011), withdrawn for digital signatures | Git legacy, fingerprints |
| SHA-256 | FIPS 180-4 | 256 | 64 | 2001 | Current | TLS, JWT, Bitcoin, checksums |
| SHA-384 | FIPS 180-4 | 384 | 96 | 2001 | Current | Suite B, high-security TLS |
| SHA-512 | FIPS 180-4 | 512 | 128 | 2001 | Current | Archival, LUKS, HMAC-SHA-512 |
| SHA-3 (any variant) | FIPS 202 | 224/256/384/512 | varies | 2015 | Current | Alternative lineage, hardware acceleration |
SHA-1 and SHA-2 (the 256/384/512 group) share a Merkle-Damgard construction. SHA-3 uses a sponge construction — a distinction that matters more than it might appear, covered below.
SHA-1: Broken but Not Dead
SHA-1 was the workhorse of the 2000s. SSL certificates, S/MIME email, PGP fingerprints, and Git all converged on it. Then in February 2017, Google and CWI Amsterdam published SHAttered: a chosen-prefix collision attack that produced two distinct PDF files with identical SHA-1 hashes. The attack required roughly 6.5 × 10^19 SHA-1 evaluations — expensive in 2017, affordable today with cloud compute.
NIST had already deprecated SHA-1 for digital signatures in 2011 (NIST Special Publication 800-131A). The SHAttered demonstration accelerated the cleanup: browsers stopped trusting SHA-1 TLS certificates by 2017, and the CA/Browser Forum made SHA-256 mandatory for new issuances.
What SHA-1 is still used for:
- Git object database: Git was designed around SHA-1 as a fast content hash, not a security primitive. The repository format hardcodes 40-hex object IDs. A migration path to SHA-256 (
git init --object-format=sha256) exists but adoption is slow because every hosted platform, every CI tool, and every existing clone would need to migrate in sync. - Legacy system fingerprints: Old SSH host-key fingerprints, PGP key fingerprints, and certificate serial number schemes still expose SHA-1 values. These are informational, not security-critical in most contexts.
What to do: Do not use SHA-1 for anything new. For Git, the collision risk is low for typical software development workflows (an attacker would need to control both files in the collision), but new projects using --object-format=sha256 are the right long-term direction.
Generate a SHA-1 hash in your browser: SHA-1 Generator.
SHA-256: The Workhorse
SHA-256 is the algorithm that runs the internet in 2026. Every TLS certificate issued by a public CA uses SHA-256 for its signature hash. Every JWT signed with HS256, RS256, or ES256 uses SHA-256 internally. Bitcoin’s proof-of-work is double-SHA-256. Docker content hashing is SHA-256. npm package integrity uses SHA-256.
The reasons are practical:
- Security margin: 256 bits of output means 2^128 operations for a brute-force preimage attack — beyond any conceivable hardware for the foreseeable future. The actual security level is slightly lower due to birthday-bound collision attacks (2^128 operations), still unassailable.
- Hardware acceleration: SHA-256 is implemented in silicon on every Intel Goldmont+ CPU (SHA-NI extension), every Apple silicon chip, every ARMv8 processor, and dedicated ASICs in network appliances and storage controllers. When the hardware path is taken, SHA-256 throughput exceeds that of many faster-seeming software alternatives.
- Ubiquitous library support: Every TLS library, every JWT library, every language standard library implements SHA-256. You will not hit a compatibility wall.
For content addressing, integrity verification, and most signing workflows, SHA-256 is the right default unless a specific standard requires otherwise.
Generate a SHA-256 hash in your browser: SHA-256 Generator.
SHA-384: The TLS Specialty
SHA-384 is SHA-512 truncated to 384 bits. It was created to provide a 192-bit security level (half the output size is the collision resistance floor) and included in NSA Suite B cryptography alongside AES-256-GCM and P-384 elliptic-curve keys.
Two properties make SHA-384 specifically attractive for TLS:
- Length-extension immunity at this output size: SHA-256 and SHA-512 are vulnerable to length-extension attacks — an attacker who knows
H(secret || message)can computeH(secret || message || extension)without knowing the secret. SHA-384 and SHA-512/256 are truncated from the full internal state, so length extension does not apply. If you are using raw SHA hashes as MACs (instead of HMAC), SHA-384 is safer. - Suite B compliance: Organizations required to meet NSA/CNSA (Commercial National Security Algorithm) suite requirements must use SHA-384 or SHA-512 alongside RSA-3072+, ECDH P-384, and AES-256. If your customer is a US federal agency or a contractor operating under FIPS 140-3 requirements, SHA-384 may be mandated.
SHA-384 is not meaningfully more secure than SHA-256 for most use cases — the practical gap between 128-bit and 192-bit collision resistance is theoretical at current compute levels. Choose it when compliance or the Suite B pairing requires it, not for generic use.
Generate a SHA-384 hash in your browser: SHA-384 Generator.
SHA-512: When You Need More Bits
SHA-512 produces a 512-bit (128-hex-character) digest. On 64-bit hardware it is often faster than SHA-256 because the algorithm operates on 64-bit words rather than 32-bit words — SHA-256’s internal schedule uses 32-bit arithmetic, while SHA-512’s uses 64-bit arithmetic that maps more efficiently onto modern CPUs.
Benchmarks on 64-bit hardware (indicative; browser Web Crypto API):
| Algorithm | Approximate Throughput |
|---|---|
| SHA-1 | ~600 MB/s |
| SHA-256 | ~500 MB/s |
| SHA-384 | ~700 MB/s |
| SHA-512 | ~700 MB/s |
| SHA-3-256 | ~300 MB/s |
Note: SHA-384 and SHA-512 share the same internal compression function, so they run at the same speed. SHA-256 is slower on 64-bit because its 32-bit word size means more iterations to process each 512-bit message block. On 32-bit or constrained hardware, SHA-256 is faster.
SHA-512 is well-suited for:
- Archival integrity: Checksums meant to survive decades benefit from the larger output margin.
- Full-disk encryption: Linux LUKS uses SHA-512 as the default key derivation PBKDF hash (as a component of PBKDF2, not as a standalone hash).
- HMAC-SHA-512: Used in some JWT signing schemes (HS512) and API authentication where larger MACs are preferred.
- Generating large amounts of pseudorandom data: Applications that hash a seed and need many output bits can use SHA-512 to reduce the number of hash calls.
Generate a SHA-512 hash in your browser: SHA-512 Generator.
SHA-3: A Different Design Philosophy
SHA-3 is not SHA-2 with a larger output. It is a fundamentally different algorithm based on a sponge construction called Keccak, designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. NIST selected it as the winner of a seven-year public competition (2007–2012) intended to produce a hash family that could serve as a backup if weaknesses were found in SHA-2’s Merkle-Damgard construction.
The sponge construction works differently from Merkle-Damgard:
- The input is padded and split into blocks.
- Each block is XORed into the first part of a large internal state (the “rate”), then the entire state is permuted with the Keccak-f permutation.
- After absorbing all input, the output is “squeezed” out of the rate portion of the state.
Because the output is extracted from only part of the state, and because the capacity portion is never directly exposed, sponge constructions are inherently immune to length-extension attacks without truncation.
SHA-3 standard variants (FIPS 202):
| Variant | Output Bits | Security Level |
|---|---|---|
| SHA3-224 | 224 | 112-bit |
| SHA3-256 | 256 | 128-bit |
| SHA3-384 | 384 | 192-bit |
| SHA3-512 | 512 | 256-bit |
| SHAKE128 | variable | 128-bit |
| SHAKE256 | variable | 256-bit |
SHA-3 vs SHA-2 in practice:
SHA-3 is not yet widely deployed in protocols designed before 2015 — TLS, JWT, and most internet infrastructure still use SHA-2. SHA-3 is appearing in post-quantum signature schemes (CRYSTALS-Dilithium, SPHINCS+ use SHA-3 internally), new protocol designs that want a different-lineage backup, and hardware where the Keccak permutation accelerates well. In pure software, SHA-3 is roughly 40% slower than SHA-256 on x86.
Generate a SHA-3 hash in your browser: SHA-3 Generator.
The Ethereum Keccak-256 Distinction
A critical gotcha: Ethereum does not use NIST SHA-3. Ethereum was designed while the Keccak competition was ongoing and before NIST finalized FIPS 202. The Ethereum Virtual Machine uses the original Keccak-256 submission, which uses different padding than the finalized NIST SHA-3 standard.
Specifically:
- NIST SHA3-256 appends
0x06padding before the final block. - Original Keccak-256 (as used by Ethereum) appends
0x01padding.
The same input produces different hashes. Calling NIST SHA3-256 and calling Ethereum’s keccak256 are not interchangeable. Most languages have both: in Python, hashlib.sha3_256() is NIST SHA-3; for Keccak-256 as Ethereum uses it, you need a library like pysha3 (which implements keccak_256). In JavaScript, the js-sha3 library exposes both. The SHA-3 Generator implements NIST SHA3-256 — if you need Ethereum Keccak-256 hashes, use an Ethereum-specific tool.
Performance Benchmarks
Numbers below are indicative for the browser Web Crypto API on a modern x86-64 laptop. Actual throughput varies with hardware, message size, and whether the platform uses a hardware acceleration path.
| Algorithm | Streaming throughput (64-bit) |
|---|---|
| SHA-1 | ~600 MB/s |
| SHA-256 | ~500 MB/s |
| SHA-384 | ~700 MB/s |
| SHA-512 | ~700 MB/s |
| SHA-3-256 | ~300 MB/s |
For small messages (API tokens, checksums under a few KB), all algorithms complete in under 2 µs — the difference is invisible. For large data (tarballs, disk images), SHA-384/512 beat SHA-256 on 64-bit systems because they operate on 64-bit words. SHA-3 is slower in pure software; prefer SHA-2 in throughput-critical code unless hardware Keccak acceleration is available. SHA-1 throughput is never a reason to use it.
Common Pitfalls
Encoding mismatches
SHA operates on bytes. If you hash the string "hello" in a browser where JavaScript encodes it as UTF-16 rather than UTF-8, you get a different digest than a Python script that uses str.encode("utf-8"). Always normalize to UTF-8 before hashing text.
A consistent pattern:
const encoder = new TextEncoder(); // UTF-8
const data = encoder.encode(inputString);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);Missing salting for MACs
Using a raw SHA hash as a message authentication code (H(secret || message)) is vulnerable to length-extension attacks on SHA-256 and SHA-512. Use HMAC (RFC 2104) instead: HMAC-SHA256(key, message). HMAC wraps the hash with an inner and outer keyed pad that prevents extension attacks.
Length-extension on SHA-256
If you are constructing an API signature as SHA256(secret + payload), an attacker who knows the resulting hash can compute SHA256(secret + payload + attacker_extension) without knowing the secret. Fix: use HMAC, or use SHA-3 (immune by construction), or use SHA-384/SHA-512/256 (immune due to truncation).
Confusing Keccak-256 with NIST SHA-3
As described above: Ethereum uses Keccak-256 with 0x01 padding; NIST SHA3-256 uses 0x06 padding. They produce different outputs from the same input. Verify which variant your library implements before integrating with Ethereum contracts or Solidity ABI encoding.
Using SHA for passwords
SHA algorithms are designed to be fast. That is exactly the wrong property for password storage: a GPU cluster can compute billions of SHA-256 hashes per second, making a dictionary attack against a SHA-hashed password database practical. For passwords, use a memory-hard key derivation function: Argon2id (recommended), bcrypt, or scrypt. Never store passwords as raw SHA hashes, even salted.
Frequently Asked Questions
What is the difference between SHA-1 and SHA-256?
SHA-1 and SHA-256 are both Merkle-Damgard hash functions standardized in FIPS 180-4, but SHA-256 produces a 256-bit digest versus SHA-1’s 160-bit digest. More importantly, SHA-1 has been broken: a real-world collision attack (SHAttered, 2017) demonstrated two distinct PDF files with the same SHA-1 hash. SHA-256 has no known collision attacks and provides a 128-bit collision resistance level. Use SHA-256 for anything requiring integrity guarantees; do not use SHA-1 for new work.
Is SHA-512 faster than SHA-256?
On 64-bit hardware, yes, often by 30–40% for large inputs. SHA-512 uses 64-bit word arithmetic, which modern CPUs process natively. SHA-256 uses 32-bit word arithmetic, requiring twice as many operations per message block on the same hardware. On 32-bit platforms or constrained microcontrollers, SHA-256 is faster. For short messages (under a few KB), the difference is imperceptible.
Should I migrate from SHA-1 to SHA-256?
For digital signatures, TLS certificates, and code signing: yes, absolutely — SHA-1 is deprecated and actively broken. For Git repositories: the migration path exists (git init --object-format=sha256) but adoption is slow due to ecosystem coordination requirements; the collision risk for typical repository use is low. For informational fingerprints (SSH host key display): the security exposure is minimal, but migrating to SHA-256 is good hygiene.
Can SHA-256 be reversed?
No. SHA-256 is a one-way function by design. Given a hash, you cannot mathematically recover the original input. What attackers can do is run a dictionary or brute-force attack: hash millions of candidate inputs and compare. For low-entropy inputs (short strings, common passwords, sequential numbers), pre-computed rainbow tables make this practical. For high-entropy inputs (random UUIDs, large files), reversal is not computationally feasible. This is why SHA alone is inappropriate for passwords — you need a slow, salted KDF.
When should I use SHA-3 instead of SHA-2?
SHA-3 is appropriate when: (a) you want a hash from a different design lineage as insurance against future SHA-2 weaknesses; (b) your protocol requires length-extension immunity without using HMAC; (c) you are implementing post-quantum signature schemes that specify SHA-3 internally; or (d) you have hardware acceleration for Keccak and need throughput. For most everyday use cases (TLS, JWT, checksums), SHA-256 has broader ecosystem support and is the pragmatic default. SHA-3 is not more secure than SHA-2 at equivalent output sizes — it is a different bet on long-term security.
Why does Ethereum use Keccak-256 instead of NIST SHA-3?
Ethereum was designed in 2013–2014, before NIST published FIPS 202 (August 2015) finalizing the SHA-3 standard. At the time, the Keccak submission was considered the likely winner, and Ethereum’s authors used it directly. When NIST finalized the standard, they changed the domain-separation padding from 0x01 (Keccak original) to 0x06, producing different output from the same input. Ethereum was already deployed with the original Keccak padding and could not change it. So “Ethereum keccak256” and “NIST SHA3-256” are different algorithms despite sharing the same underlying Keccak-f permutation.
Try the tools: SHA-1 · SHA-256 · SHA-384 · SHA-512 · SHA-3 — all run in your browser, no data leaves your machine.