Pick a hash function for a new system in 2026 and you will eventually land on the same fork in the road: SHA-256, the workhorse behind Bitcoin and most of the web’s TLS traffic, or SHA-3, the NIST-standardized sponge construction built as an independent backup after cracks appeared in older designs. Both are secure. Both carry NIST’s blessing. But they are not interchangeable, and the choice affects throughput, hardware cost, and how your system ages as quantum computing matures. This comparison walks through the specs, the benchmark numbers from three separate sources, real production deployments, and a migration path if you decide to switch.

What Is SHA-256?

SHA-256 belongs to the SHA-2 family, published by NIST in FIPS 180-4. It builds on a Merkle-Damgård construction: the message gets padded, split into 512-bit blocks, and each block runs through a compression function that updates a running 256-bit state. The design traces back to SHA-1 and MD5, though NIST reworked the internal round function and added more mixing to close the weaknesses that eventually broke its predecessors.

The algorithm outputs a fixed 256-bit digest regardless of input size, targets 128-bit collision resistance, and 256-bit preimage resistance. It has run in production since 2001 with no practical break against the full-round version. That track record, combined with hardware support baked into nearly every modern CPU, is why SHA-256 became the default hash for TLS certificates, Bitcoin’s proof-of-work, and HMAC-based API authentication across AWS, Stripe, and most REST APIs that need signed requests.

SHA-256 sits in the middle of the wider SHA-2 family, which also includes SHA-224, SHA-384, SHA-512, and two truncated variants, SHA-512/224 and SHA-512/256. All of them share the same Merkle-Damgård skeleton described in NIST’s SHA-2 specification, just with different word sizes and output lengths. SHA-256 became the default pick in that family not because it is the strongest mathematically, SHA-512 has a larger internal state, but because 256 bits of output lines up cleanly with common key sizes, fits neatly into a 32-bit register width, and became the reference implementation that most early libraries shipped first.

What Is SHA-3?

SHA-3 is not a patch on SHA-2. NIST ran an open competition starting in 2007, specifically because Merkle-Damgård hashes like SHA-1 and SHA-2 share a family of theoretical weaknesses (length-extension attacks among them), and the agency wanted a structurally different backup in case SHA-2 ever fell. Keccak, designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche, won in 2012. NIST standardized it as SHA-3 in FIPS 202, published in 2015.

Keccak uses a sponge construction instead of Merkle-Damgård. Data gets absorbed into a 1600-bit internal state through a permutation function, then squeezed out to produce the digest. SHA3-256 uses a capacity of 512 bits, which gives it the same 128-bit collision resistance and 256-bit preimage resistance target as SHA-256, but through a different mathematical structure that is not vulnerable to length-extension attacks. The sponge design also enables extendable-output functions like SHAKE128 and SHAKE256, which can produce a digest of any requested length, something SHA-256 cannot do natively.

On March 12, 2025, NIST’s Crypto Publication Review Board confirmed it would move forward with an editorial update to FIPS 202 and a companion revision of SP 800-185, which governs SHA-3’s derived functions (SHAKE, cSHAKE, KMAC). The changes are organizational, not cryptographic. NIST is not weakening or strengthening the algorithm, just cleaning up the documentation, which tells you the agency still treats SHA-3 as a settled, stable standard a decade after publication.

The name itself causes confusion. SHA-3 is not a successor to SHA-2 in the way SHA-2 replaced SHA-1, it is a parallel standard NIST maintains alongside SHA-2, not instead of it. The agency’s own SHA-3 project page frames it explicitly as a backup in case cryptanalysis ever undermines the entire SHA-2 family at once, a scenario that has not happened but that motivated the entire Keccak competition in the first place. IETF formalized SHA-3 usage in TLS and related protocols through RFC 8702, which defines how to use SHAKE128 and SHAKE256 for digital signatures, though adoption of that RFC in mainstream TLS stacks remains limited compared to SHA-256-based signature schemes.

SHA-256 vs SHA-3: Full Specification Comparison

The table below lines up every spec that matters when you are choosing between the two for a new system.

SpecSHA-256SHA-3 (SHA3-256)
NIST standardFIPS 180-4FIPS 202
Year published20012015
ConstructionMerkle-DamgårdSponge (Keccak permutation)
Internal state size256-bit1600-bit
Block size512 bits1088-bit rate (for SHA3-256)
Output size256 bits (fixed)224/256/384/512-bit, or arbitrary via SHAKE
Collision resistance target128 bits128 bits
Preimage resistance target256 bits256 bits
Length-extension vulnerableYes (needs HMAC to mitigate)No, by design
Extendable-output functionNot supportedYes, via SHAKE128/SHAKE256
Native CPU hardware supportWidespread (Intel SHA Extensions, ARMv8 Crypto Extensions)Rare; mostly RISC-V research cores and select embedded co-processors
Known practical attacks (2026)None on full round versionNone on full round version
Primary real-world usersBitcoin, TLS/PKI, HMAC APIsEthereum (Keccak-256 variant), select federal systems

One nuance worth flagging: Ethereum’s Keccak-256 is not identical to the standardized SHA3-256. Ethereum adopted Keccak before NIST finalized the padding scheme in FIPS 202, so the two differ at the padding-byte level even though they share the same underlying permutation. Anyone building on Ethereum needs the original Keccak-256, not a NIST-compliant SHA3-256 library, or hashes will not match.

Benchmark Results: Which One Is Actually Faster?

Speed is where the two algorithms pull apart the most, and the gap depends heavily on whether the CPU has dedicated hash instructions.

A 2025 benchmark on an AMD EPYC 4245P (Zen 5) with SHA-NI enabled measured SHA-256 throughput at 822 MB/s versus 246 MB/s for SHA3-256 on 64-byte inputs, a gap that held between 3.3x and 3.5x across input sizes from 64 bytes up to 1 MB. That is the clearest real-world number available: on current server-class x86 hardware, SHA-256 runs roughly three and a half times faster than SHA-3 when both get to use their respective hardware paths, which favor SHA-256 far more heavily.

Software-only comparisons tell a similar story from a different angle. Daniel Bernstein’s cycle-accurate measurements put SHA3-256 at 11.7 to 12.25 cycles per byte on typical x86-64 hardware without special instructions, roughly matching NIST’s own reference figure of about 12.6 cycles per byte for the Keccak-f[1600] permutation. Optimized implementations using AVX-512VL on Skylake-X hardware bring that down to around 6.4 cycles per byte, and AVX2 gets to roughly 7.8 cycles per byte on Skylake. Across other x86, POWER, and ARM chips without those extensions, SHA3-256 typically lands between 8 and 15 cycles per byte, and older CPUs can see 25 to 40 cycles per byte.

Embedded hardware flips the picture. A 2025 microarchitecture study of custom SHA-3 instructions for RISC-V cores found that adding a dedicated Keccak round instruction produced average speedups up to 46.31x for Keccak-based software and about 8.02x for general RISC-V workloads using SHA-3. For long SHA-512 style inputs, the same custom instructions cut execution cycles from tens of billions down to hundreds of millions. That result matters because it shows the SHA-256 speed advantage is not fundamental to the algorithm, it is a consequence of Intel and Arm having shipped SHA-2 acceleration in silicon for a decade while SHA-3 acceleration remains mostly a research topic outside a handful of embedded chips.

On resource-constrained hardware without any acceleration, the gap narrows further in relative terms but stays in SHA-256’s favor. A comparative study of Keccak implementations on an ARM Cortex-M4 measured SHA3-256 at roughly 77 cycles per byte, with SHA3-224 close behind at about 72.4 cycles per byte using an instruction-set extension. A 32-bit MIPS platform with a coprocessor extension for SHA-3 reached about 137.9 cycles per byte, underscoring how much embedded SHA-3 performance depends on whether the chip vendor bothered to add dedicated silicon.

Here is the three-source summary in one place:

SourcePlatformSHA-256SHA-3Result
2025 Zen 5 hardware benchmarkAMD EPYC 4245P, SHA-NI on822 MB/s246 MB/sSHA-256 is 3.3x-3.5x faster
Bernstein / NIST cycle measurementsGeneric x86-64, no extensions~2-3 cycles/byte (SHA-NI equipped)11.7-12.6 cycles/byteSHA-256 wins by a wide margin without acceleration too
2025 RISC-V custom instruction studyRISC-V core with dedicated Keccak instructionBaselineUp to 46.31x speedup vs. unaccelerated SHA-3Hardware support closes the gap entirely

Security Margins and Attack Resistance

Both algorithms remain unbroken at full rounds as of 2026. Cryptanalysis on both continues, but it focuses on reduced-round variants and structural properties, not exploitable weaknesses in the versions anyone actually deploys. NIST’s own review activity around FIPS 202 in 2024 and 2025 was editorial, not a response to any discovered flaw.

The practical security difference comes down to structure, not strength. SHA-256’s Merkle-Damgård design is vulnerable to length-extension attacks: given hash(message), an attacker can compute hash(message + attacker-controlled-suffix) without knowing the original message, which has burned developers who used raw SHA-256 for message authentication instead of HMAC-SHA256. SHA-3’s sponge construction is immune to length extension by design, so SHA3-256 can be used directly as a MAC without the HMAC wrapper, though most existing systems still use HMAC out of habit and library support.

SHA-3 was also explicitly designed to behave like a random oracle under standard cryptographic assumptions, a property SHA-2 was never engineered to guarantee. That gives SHA-3 a larger structural safety margin on paper, even though both hit the same nominal 128-bit collision and 256-bit preimage targets. In practice, this is closer to an insurance policy than a day-to-day advantage. It matters most if a future cryptanalytic breakthrough targets Merkle-Damgård constructions specifically, since SHA-3’s different internal design would not share that weakness.

History gives this scenario some weight. MD5 and SHA-1 both fell to practical collision attacks after years of academic pressure chipped away at their internal structure, and both share the same Merkle-Damgård lineage SHA-256 uses today. No comparable weakness has surfaced in SHA-256 after two and a half decades of scrutiny, and its larger 256-bit state gives it far more headroom than SHA-1’s 160-bit output ever had. Still, the reasoning that pushed NIST to standardize a structurally different backup in 2015 has not gone away: a single design family securing the majority of the internet’s integrity checks is a concentration risk, independent of how strong that one family currently looks.

Quantum Resistance: How Both Hold Up Against Grover’s Algorithm

Neither SHA-256 nor SHA-3 is a post-quantum cryptography algorithm in the sense that ML-KEM or ML-DSA are. But hash functions age better against quantum attacks than RSA or elliptic curve schemes, because Grover’s algorithm only offers a quadratic speedup against brute-force search, not the exponential break that Shor’s algorithm delivers against factoring and discrete log problems.

Under Grover-style quantum search, both SHA-256 and SHA3-256 drop to roughly 128 bits of preimage security and about 64 bits of collision security, since quantum attacks effectively halve the classical security exponent. Both remain well within the range NIST considers secure against realistic quantum adversaries for the foreseeable future. The one structural edge SHA-3 holds is flexibility. Because it is a sponge with a tunable capacity, a future SHA-3 variant could increase its security margin simply by widening the capacity and output size. SHA-256’s fixed 256-bit output has no equivalent upgrade path without moving to SHA-512 or a different algorithm entirely.

This is a different conversation from the post-quantum migration happening around RSA and elliptic curve cryptography. NIST’s finalized post-quantum standards, ML-KEM for key exchange and ML-DSA for digital signatures, replace algorithms that Shor’s algorithm can break outright on a sufficiently large quantum computer. Hash functions were never in that danger zone to begin with, so neither SHA-256 nor SHA-3 appears on any NIST deprecation timeline tied to quantum risk. Teams planning a post-quantum migration should focus that effort on key exchange and signature algorithms, not on swapping hash functions, since the hash layer already has an adequate quantum security margin at current output sizes.

Real-World Adoption: Where Each Algorithm Actually Runs

Specs matter less than where an algorithm actually ships. Here is where each one shows up in production in 2026.

  • Bitcoin proof-of-work: Bitcoin’s mining algorithm, described in Satoshi Nakamoto’s original whitepaper, runs SHA-256 twice on every block header (SHA-256d), and the entire security model of the network rests on how expensive SHA-256 is to compute at scale. Changing this would require a hard fork touching every miner on Earth, which is why Bitcoin will run SHA-256 indefinitely regardless of what NIST recommends.
  • TLS and PKI certificates: SHA-256 is the default signature hash in TLS 1.2 and TLS 1.3 certificate chains across OpenSSL, BoringSSL, and every major browser’s certificate validation path. Certificate authorities issuing under the CA/Browser Forum’s baseline requirements sign with SHA-256, and moving that ecosystem to SHA-3 would require coordinated updates across every browser vendor and CA, which nobody is currently pushing for.
  • Ethereum and EVM chains: Ethereum uses Keccak-256, the pre-standardization variant of SHA-3’s permutation, to derive account addresses, hash transaction data, and compute storage trie roots. Every EVM-compatible chain inherited this choice, so Keccak-256 runs on more blockchain transaction volume today than any standardized SHA3 variant does.
  • AWS API request signing: AWS Signature Version 4, the scheme behind every authenticated call to S3, DynamoDB, and the rest of the AWS API surface, uses HMAC-SHA256 to sign requests. That single design decision means SHA-256 processes a meaningful share of the internet’s API traffic every day.
  • NIST and federal systems: FIPS 202 gives federal agencies an approved second hash family independent of SHA-2, which matters for systems that need algorithm diversity as a defense-in-depth requirement. SP 800-185’s SHA-3-derived functions, including KMAC, are used where a MAC construction that avoids HMAC’s extra hashing step is preferred.
  • RISC-V and embedded silicon: Academic and early commercial RISC-V designs are adding dedicated Keccak round instructions specifically to make SHA-3 viable in IoT and embedded contexts, where SHA-256’s incumbency advantage from x86/Arm hardware support does not apply the same way.

How SHA-256 and SHA-3 Compare to Other Modern Hashes

SHA-256 and SHA-3 are not the only two options on the table in 2026, and it helps to place them next to the newer generation of hash functions that have shown up in performance-sensitive tooling. BLAKE3, released in 2020, was built explicitly for speed, using a Merkle tree structure that parallelizes across CPU cores in a way neither SHA-256 nor SHA-3 can. A 1 GB file benchmark comparing OpenSSL’s SHA-256 implementation against a modern BLAKE3 tool found BLAKE3 running roughly 2.5x faster than OpenSSL’s SHA-256 and about 9x faster than the older sha256sum utility, which puts BLAKE3 well ahead of both algorithms covered in this piece on raw throughput.

That does not make SHA-256 or SHA-3 obsolete. BLAKE3 has not gone through the same multi-decade NIST standardization process, has no FIPS validation status, and remains locked out of compliance-driven environments (federal systems, payment processing, most regulated industries) that specifically require a NIST-approved algorithm. SHA-256 and SHA-3 both check that box. BLAKE3 wins on speed for teams free to choose based purely on performance, checksumming tools, content-addressed storage systems, and package managers being common examples, while SHA-256 keeps its grip on anything touching TLS, PKI, or compliance-bound infrastructure regardless of the throughput gap.

The Cost of Compute: What the Speed Gap Means at Cloud Scale

Neither hash function carries a license fee, but the throughput gap translates directly into compute cost for any workload that hashes at volume, think certificate transparency logs, blockchain indexers, or backup deduplication systems. If SHA-3 runs 3.3x slower than SHA-256 on the same hardware, a hashing-bound job needs roughly 3.3x more vCPU-hours to finish the same amount of work, and cloud providers bill compute by the hour regardless of which algorithm is running.

ResourceProviderCurrent price
4-vCPU compute instance (Graviton3, on-demand, us-east-1)AWS EC2 c7g.xlarge$0.1450/hour
4-vCPU compute instance (on-demand, us-east4)Google Cloud c3-standard-4$0.201608/hour
4-vCPU compute instance (on-demand, East US)Azure Standard_F4s_v2$0.1690/hour
Cryptographic sign/MAC operations, per 10,000AWS KMS$0.15
Cryptographic operations, per 10,000 (standard keys)Google Cloud KMS$0.03
Standard/RSA-2048 operations, per 10,000Azure Key Vault$0.03
Advanced RSA-3072/4096 and ECC operations, per 10,000Azure Key Vault$0.15

None of the three major managed KMS services price SHA-256 and SHA-3 operations differently today, they bill by operation count or key type, not by hash algorithm. The real cost driver is raw compute time on self-hosted workloads. A backup deduplication pipeline hashing 10 TB a day on a $0.145/hour Graviton3 instance pays a small, fixed compute bill with SHA-256. Swap in SHA3-256 without hardware acceleration, and that same job needs over three times the instance-hours to keep pace, which shows up directly in the monthly cloud invoice.

Hardware Acceleration: Why the SHA Extensions Gap Matters

Intel added SHA Extensions to mainstream x86 chips starting with Goldmont in 2016, and AMD followed shortly after. Arm shipped equivalent SHA-2 acceleration in the ARMv8 Cryptography Extensions years earlier. Both instruction sets accelerate SHA-1 and SHA-256 specifically, not SHA-3. That decision, made over a decade ago when SHA-3 adoption was still uncertain, is the single biggest reason SHA-256 outruns SHA-3 on almost every consumer and server CPU sold today.

SHA-3 can close a meaningful chunk of that gap with AVX-512 or AVX2 vectorization, dropping from roughly 12 cycles per byte down to 6.4 cycles per byte on Skylake-X hardware, but that still trails SHA-256’s SHA-NI-accelerated throughput by a wide margin. The RISC-V research showing 46x speedups from a dedicated Keccak instruction demonstrates the fix is straightforward at the silicon level, nobody with mainstream market share has shipped it yet. Until a major chipmaker adds native SHA-3 acceleration, the performance gap documented in the benchmarks above will persist regardless of which algorithm has the better on-paper security story.

Common Implementation Mistakes With Both Algorithms

Most real-world security problems tied to either hash function come from misuse, not from any weakness in the algorithm itself. A handful of mistakes show up repeatedly in code review.

The most common SHA-256 mistake is using raw SHA-256 concatenation to authenticate a message, hash(secret + message), instead of HMAC-SHA256. Because SHA-256 is vulnerable to length extension, an attacker who sees a valid hash can often compute a valid hash for a longer message with attacker-controlled data appended, without ever learning the secret key. This exact pattern caused real vulnerabilities in early API designs, and it remains a finding security auditors flag routinely. The fix is simple: always use HMAC-SHA256, never raw concatenation, for anything resembling message authentication.

The most common SHA-3 mistake, ironically, is skipping HMAC out of a sense that it is unnecessary, then discovering a library or protocol expects the standard HMAC-wrapped format for interoperability. While SHA3-256 is technically safe to use directly as a MAC, most existing authentication middleware, API gateways, and client libraries expect an HMAC construction regardless of the underlying hash. Mixing conventions across a distributed system creates compatibility headaches that have nothing to do with cryptographic strength and everything to do with format mismatches between services written by different teams at different times.

A second SHA-3 mistake, specific to blockchain work, is treating Keccak-256 and SHA3-256 as interchangeable. They are not. Using the wrong variant produces a different digest for the same input, which silently breaks address derivation, signature verification, or Merkle proof validation on any EVM-compatible chain. Every major Ethereum library (web3.py, ethers.js, web3.js) ships the correct Keccak-256 implementation by default, but a team rolling custom cryptographic code from a generic SHA-3 library will hit this mismatch immediately.

A third mistake applies to both: assuming a fast general-purpose hash is appropriate for password storage. Neither SHA-256 nor SHA-3 includes the deliberate slowness or memory-hardness that password hashing requires, and using either one directly to store user credentials leaves the system exposed to GPU-accelerated cracking at speeds measured in billions of guesses per second. That job belongs to Argon2 or bcrypt, not a general-purpose cryptographic hash.

Migration Guide: Moving From SHA-256 to SHA-3

Switching hash algorithms in production is rarely worth doing unless you have a specific reason (a length-extension exposure in existing code, a compliance requirement for algorithm diversity, or a new system with no legacy compatibility burden). If you decide to move, here is the practical path.

  1. Audit every call site. Grep the codebase for hashlib.sha256, CryptoJS.SHA256, or equivalent calls, and separate integrity-checking uses from authentication (MAC) uses, since the migration path differs for each.
  2. Check library support. OpenSSL 3.0 and later, Python’s hashlib, Node’s built-in crypto module, and Go’s golang.org/x/crypto/sha3 package all support SHA3-256 natively. Confirm your specific runtime version before assuming support.
  3. Decide on HMAC vs. native MAC. If you are currently using HMAC-SHA256 for authentication, you can either keep the HMAC wrapper with SHA3-256 inside it, or switch to KMAC, the SHA-3-native MAC defined in SP 800-185, which skips the extra hashing round HMAC requires.
  4. Plan for a dual-write period. For anything with stored hashes (password reset tokens, file checksums, database indexes keyed on hash values), run both algorithms in parallel for a transition window so existing data does not need immediate rehashing.
  5. Benchmark on your actual hardware. Run OpenSSL’s built-in benchmark before committing.
openssl speed sha256 sha3-256

That single command reports throughput for both algorithms on the exact CPU your service runs on, which matters more than any generic benchmark given how much SHA-NI availability swings the numbers. OpenSSL’s speed documentation covers the full set of flags if you need to test specific block sizes or thread counts to match your production traffic pattern.

Watch for three failure points during the migration that catch teams off guard. First, digest length assumptions: if any code path hardcodes a 32-byte buffer for a hash output, SHA3-256 still fits since both produce 32-byte digests, but SHA3-384 or SHA3-512 will not, so audit anywhere a team might reach for a stronger variant later. Second, hex versus base64 encoding mismatches between old and new hash storage columns tend to surface only after the dual-write period ends and someone tries to compare values across formats. Third, any downstream service that validates hash format via regex, expecting exactly 64 hex characters for SHA-256, needs no changes for SHA3-256 since the output length matches, but teams should still update validation logic explicitly rather than relying on the coincidence.

import hashlib

data = b"migration test payload"

sha256_digest = hashlib.sha256(data).hexdigest()
sha3_digest = hashlib.sha3_256(data).hexdigest()

print("SHA-256:", sha256_digest)
print("SHA3-256:", sha3_digest)

Python’s hashlib exposes both under the same interface, which is typical across modern languages and makes the code-level migration close to a one-line change. The real cost is everywhere else: schema updates, re-signing existing data, and coordinating with any downstream consumer that hardcodes hash length or format assumptions.

SHA-256: Pros and Cons

  • Pro: Fastest option on nearly all consumer and server hardware thanks to a decade of SHA-NI and ARMv8 Crypto Extension deployment.
  • Pro: Universal library and tooling support, with two and a half decades of production hardening.
  • Pro: Locked into Bitcoin and most of the TLS/PKI ecosystem, so it is not going anywhere regardless of what NIST recommends next.
  • Con: Vulnerable to length-extension attacks if used without HMAC.
  • Con: Fixed 256-bit output with no built-in mechanism to extend the security margin without switching to SHA-512 or a different family.
  • Con: Shares a Merkle-Damgård lineage with SHA-1, which some auditors flag as a diversification risk even without any known break.

SHA-3: Pros and Cons

  • Pro: Immune to length-extension attacks by construction, so it can serve directly as a MAC without an HMAC wrapper.
  • Pro: Structurally independent from SHA-2, giving genuine algorithm diversity for compliance and defense-in-depth requirements.
  • Pro: Sponge design supports extendable-output functions (SHAKE128/256) for use cases needing variable-length digests.
  • Con: Roughly 3.3x slower than SHA-256 on mainstream hardware due to the lack of dedicated CPU acceleration.
  • Con: Far smaller ecosystem footprint, since most existing infrastructure, tooling, and documentation assumes SHA-2.
  • Con: Ethereum’s Keccak-256 variant is not byte-compatible with standardized SHA3-256, which trips up developers who assume they are identical.

Use-Case Recommendations

  • General-purpose application hashing (file integrity, checksums, HMAC auth): Use SHA-256. The speed advantage, library maturity, and hardware acceleration make it the practical default unless you have a specific reason to move.
  • High-throughput backup or deduplication pipelines: Use SHA-256. The 3.3x throughput gap translates directly into cloud compute cost at scale, and there is no compliance reason to pay that premium for most storage workloads.
  • New systems requiring algorithm diversity for compliance: Use SHA-3 alongside SHA-256, not instead of it. Running both in parallel for critical signatures satisfies defense-in-depth requirements without betting the entire system on one construction family.
  • Building or interacting with Ethereum and EVM-compatible chains: Use Keccak-256 specifically, not standardized SHA3-256. Confirm your library implements the pre-FIPS-202 padding Ethereum expects, or address derivation will silently produce wrong results.
  • Embedded or IoT devices with custom silicon: Consider SHA-3 if the chip includes dedicated Keccak acceleration. The RISC-V research showing 46x speedups means SHA-3 can outperform unaccelerated SHA-256 on the right hardware.
  • Variable-length digest requirements (key derivation, streaming applications): Use SHA-3’s SHAKE128 or SHAKE256, since SHA-256 has no native equivalent for arbitrary-length output.

The Verdict: Which Should You Use in 2026?

For most engineering teams, SHA-256 remains the right default in 2026. It is 3.3x to 3.5x faster on the hardware you already run, per the 2025 Zen 5 benchmark, it has broader library and tooling support, and it underpins infrastructure (Bitcoin, TLS/PKI, AWS request signing) that is not migrating away regardless of what any single team decides. Unless you have hit a specific length-extension exposure, a compliance mandate for algorithm diversity, or you are building on Ethereum where Keccak-256 is mandatory, switching to SHA-3 adds compute cost without a corresponding practical security gain, since both remain unbroken at full rounds.

SHA-3 earns its place as a deliberate second choice. Pick it when you specifically need structural independence from Merkle-Damgård constructions, when length-extension resistance matters for your protocol design, or when your hardware includes the dedicated acceleration that erases its speed disadvantage. NIST built SHA-3 as an insurance policy, not a replacement, and the adoption numbers through 2026 reflect exactly that positioning: dominant in one major ecosystem (Ethereum, via Keccak-256), present in federal systems that require it, and largely absent everywhere else that SHA-256 already does the job.

The practical takeaway for a team shipping code this quarter: default to SHA-256 wrapped in HMAC for anything authentication-related, reach for SHA-3 only when a specific requirement calls for it by name, and treat the two as complementary tools rather than competitors fighting for the same job. The data backs a default, not an exclusion. Both algorithms will keep running in production long after 2026, just in different corners of the stack.

Frequently Asked Questions

Is SHA-3 more secure than SHA-256?

Not in a practical sense. Both target the same 128-bit collision resistance and 256-bit preimage resistance, and neither has a known break at full rounds. SHA-3’s sponge construction gives it a larger structural safety margin and immunity to length-extension attacks, which matters as a hedge against future cryptanalysis, but it does not make SHA-3 more secure for everyday use today.

Why is SHA-256 faster than SHA-3 on most computers?

Intel and Arm added dedicated hardware instructions (SHA Extensions and ARMv8 Crypto Extensions) that accelerate SHA-256 specifically, starting around 2016. SHA-3 never got the same mainstream hardware treatment, so it runs mostly in software on consumer and server CPUs, which is why the 2025 Zen 5 benchmark measured SHA-256 at roughly 3.3x to 3.5x the throughput of SHA3-256.

Does Bitcoin use SHA-3?

No. Bitcoin uses SHA-256 exclusively, applying it twice per block header (a pattern called SHA-256d). Bitcoin’s proof-of-work design predates SHA-3’s 2015 standardization, and changing the mining algorithm would require a network-wide hard fork that no significant part of the Bitcoin community is pushing for.

Is Ethereum’s Keccak-256 the same as SHA-3?

No, and this trips up a lot of developers. Ethereum adopted the Keccak algorithm before NIST finalized the padding scheme in FIPS 202, so Keccak-256 and standardized SHA3-256 produce different digests for the same input despite sharing the same underlying permutation. Libraries need to implement the specific pre-standardization variant to match Ethereum’s address and hash computations.

Can quantum computers break SHA-256 or SHA-3?

Not with any quantum algorithm known today. Grover’s algorithm offers only a quadratic speedup against hash preimage search, dropping both SHA-256 and SHA3-256 to roughly 128-bit effective preimage security under quantum attack, which both standards bodies still consider secure. This is a much smaller impact than Shor’s algorithm has on RSA or elliptic curve cryptography, where quantum computers could eventually break the underlying math entirely.

Should I use SHA-256 or SHA-3 for password hashing?

Neither. Password hashing needs a deliberately slow, memory-hard function like Argon2 or bcrypt, designed specifically to resist GPU and ASIC cracking attempts. SHA-256 and SHA-3 are both fast general-purpose hashes, which is exactly the wrong property for storing passwords securely.

Do I need HMAC with SHA-3 the way I do with SHA-256?

Not strictly. SHA-3’s sponge construction is immune to length-extension attacks, so SHA3-256 can serve as a MAC directly, and SP 800-185 defines KMAC specifically for this purpose. Most existing systems still wrap SHA-3 in HMAC anyway, largely out of library convention and to keep authentication code consistent across algorithms.

Which cloud providers charge more for SHA-3 operations?

None of the major managed key services (AWS KMS, Google Cloud KMS, Azure Key Vault) price operations differently based on the underlying hash algorithm. They bill per operation count or key type. The real cost difference shows up in self-hosted, compute-bound hashing workloads, where SHA-3’s lower throughput means more vCPU-hours to process the same volume of data.