Methodology & Sources — BLAKE3 vs SHA-256

Benchmark methodology

The benchmark runs entirely in your browser. No data is sent to any server. Four algorithms are tested across four data sizes (1 KB, 100 KB, 1 MB, 10 MB).

Algorithms tested

BLAKE3 (single-threaded) — hash-wasm WebAssembly implementation
BLAKE3 (multi-core) — Same WASM library, parallelized across Web Workers (one per CPU core). Each worker hashes an independent chunk; this measures parallelism overhead and scaling, not full Merkle tree assembly.
SHA-256 (WASM) — hash-wasm WebAssembly implementation. Fair software-vs-software comparison with BLAKE3.
SHA-256 (Web Crypto) — Browser's native crypto.subtle.digest() API. On devices with Intel SHA-NI or ARMv8 Crypto Extensions, this is hardware-accelerated. On older CPUs, it's native compiled code (faster than WASM but not hardware-accelerated). Requires HTTPS.

Timing methodology

Warm-up: 2 calls discarded before measurement to ensure JIT compilation and WASM initialization are complete.
Batched timing: Small data sizes (1 KB, 100 KB) are timed in batches (500 and 50 ops respectively) to overcome browser timer resolution limits (~0.1ms). Per-op time is derived by dividing batch time.
Individual timing: Large data sizes (1 MB, 10 MB) are timed individually per operation.
Median reported: All timings sorted, median used as the representative value. This resists outliers from garbage collection, tab throttling, or OS scheduling.
Throughput: Calculated as data_size / median_time, reported in MB/s or GB/s.
Verification: After each data size, all algorithms hash the same random data and output prefixes are displayed. SHA-256 WASM and Web Crypto outputs are compared to confirm they match.

Known limitations

Multi-core BLAKE3 splits data across workers but does not assemble a full Merkle tree. This means multi-core results represent parallel chunk hashing, not the full BLAKE3 tree hash.
Web Worker message-passing overhead is significant at small data sizes, making multi-core slower than single-threaded for 1 KB and 100 KB inputs.
The WASM BLAKE3 implementation does not use WASM SIMD instructions. Enabling SIMD could significantly widen the BLAKE3 advantage.
Web Crypto API batches are run with Promise.all() to avoid unfair per-call async overhead, but this may slightly overstate Web Crypto throughput compared to sequential calls.
Browser throttling (background tabs, low-power mode) can affect results. Run with the tab in the foreground for best accuracy.

Sourcing for factual claims

Every factual claim on the main page has been reviewed. Below are the primary sources for each section.

SHA-256 architecture & history

Claim	Source
SHA-256 designed 2001, by NSA, published by NIST	NIST FIPS 180-4
Sequential Merkle-Damgard construction	FIPS 180-4 Section 6.2; Merkle (1979); Damgard (1989)
Length extension vulnerability	Duong & Rizzo (2009); RFC 6234

BLAKE3 architecture & properties

Claim	Source
Designed 2020 by O'Connor, Aumasson, Neves, Wilcox-O'Hearn	BLAKE3 paper
Merkle tree structure, parallel processing	BLAKE3 specification, Section 5
Immune to length extension (finalization flags)	BLAKE3 specification, Section 5.1
Verified streaming	Bao project
Built-in keyed hashing, KDF, PRF modes	BLAKE3 specification, Section 5.1 (flag definitions)
Open source (CC0 / Apache 2.0)	BLAKE3 GitHub

SHA-256 weaknesses (theoretical)

Claim	Source
Joux multicollisions (2^k collisions at k × 2^(n/2) cost)	Joux, "Multicollisions in Iterated Hash Functions," CRYPTO 2004
Herding / Nostradamus attacks	Kelsey & Kohno, Eurocrypt 2006
Long-message second preimage attacks	Kelsey & Schneier, Eurocrypt 2005
Grover's algorithm halves preimage resistance	Grover (1996); Brassard, Hoyer, Tapp (1998)

SHA-256 real-world usage

Use case	Source
TLS/SSL certificates	CA/Browser Forum Baseline Requirements
4G LTE / 5G key derivation	3GPP TS 33.401 (LTE); TS 33.501 (5G)
Bitcoin double-SHA-256	Bitcoin whitepaper (Nakamoto, 2008)
Docker image digests	OCI Image Specification
Git SHA-256 migration	Git hash function transition plan
iMessage	Apple Platform Security Guide
Signal Protocol / WhatsApp	Signal Protocol specifications
AWS Signature Version 4	AWS SigV4 documentation
TOTP (2FA)	RFC 6238 (default: HMAC-SHA-1; SHA-256 optional)
WPA2 WiFi	IEEE 802.11i (uses PBKDF2-SHA-1, not SHA-256)
PBKDF2 password hashing	NIST SP 800-63B; NIST SP 800-132
DKIM email signing	RFC 6376; RFC 8301

Caveats & editorial choices

This site advocates for BLAKE3 adoption. We believe the technical case is strong, but some claims involve editorial judgment. Here's where we draw the line.

"Structurally stronger"

The hero section calls BLAKE3 "a faster, structurally stronger alternative." BLAKE3 has the same output size and security level (256-bit preimage, 128-bit collision) as SHA-256. "Structurally stronger" refers to architectural properties: immunity to length extension attacks, built-in domain separation, and avoidance of Merkle-Damgard generic weaknesses. SHA-256 has survived 25 years of intense cryptanalysis with no practical breaks — the most scrutiny any hash function has ever received. We chose "structurally stronger" over "more secure" because the two functions have equal security levels; BLAKE3's advantages are in design, not in raw cryptographic strength.

Double-SHA-256 rationale

We say Bitcoin's double-SHA-256 is "likely a defense against the length extension attack." This is the most commonly cited explanation, but Satoshi Nakamoto never stated the reason explicitly. It may also be general defense-in-depth.

BLAKE3 as a SHA-256 replacement

BLAKE3 is cryptographically sound and faster in software. However, it lacks NIST standardization, FIPS certification, and the decades of cryptanalysis that SHA-256 has undergone. In regulated contexts (government, finance, healthcare), SHA-256 or SHA-3 remain the mandated choices. Our claim that "BLAKE3 qualifies" applies to non-regulated applications where performance matters and standards compliance is not required.

Web Crypto as "hardware-accelerated"

We label the Web Crypto API implementation "SHA-256 (HW)" in benchmark results. On devices with Intel SHA-NI or ARMv8 Crypto Extensions, the browser does use hardware acceleration. On older CPUs without these instructions, Web Crypto is native compiled code — faster than WASM but not truly hardware-accelerated. The label is accurate for most modern phones and recent laptops.

Correction log

We fact-checked every claim on this site and corrected the errors we found. Transparency matters.

March 2026 (second pass)

Hero section: Changed "faster, more secure alternative" to "faster, structurally stronger alternative." BLAKE3 and SHA-256 have the same security level (256-bit); "more secure" overstated the case. "Structurally stronger" accurately describes BLAKE3's architectural advantages without implying SHA-256 is insecure.

Weaknesses section heading: Changed "SHA-256 is Weak" to "SHA-256 is showing its age" and "six known weaknesses" to "six limitations" with categorization (2 security, 2 performance, 1 design, 1 future risk). The original heading conflated security vulnerabilities with performance gaps and universal properties.

SHA-256 comparison card: Changed "can't parallelize" to "can't parallelize a single message" — multiple independent messages can be parallelized, and non-standard tree-hashing wrappers exist. Changed "Needs hardware acceleration to stay fast" to "Relies on hardware acceleration to match modern alternatives" — SHA-256 achieves ~200–500 MB/s in pure software, which is perfectly usable.

Length extension section: Removed "early AWS signature schemes" from the list of real-world exploits. AWS Signature V2 used HMAC (immune to length extension), and no confirmed AWS-specific length extension exploit could be sourced.

Quantum section: Revised BLAKE3 comparison text. Previously implied that longer BLAKE3 outputs increase preimage resistance post-quantum — this is incorrect, as the 256-bit internal state is the bottleneck regardless of output length. Now accurately frames the speed advantage without a false security claim.

Everywhere takeaway: Added "Why it still dominates" counterpoint acknowledging SHA-256's 25-year cryptanalysis track record, NIST/FIPS certification, ubiquitous hardware support, and the rational case for continued use in regulated contexts.

March 2026 (first pass)

Two-factor authentication section: Originally stated TOTP codes use "HMAC-SHA-256." Corrected to "HMAC-SHA-1 by default (RFC 6238), though newer systems increasingly support HMAC-SHA-256." The TOTP standard defaults to SHA-1, not SHA-256.

Passwords & WiFi section: Originally stated "PBKDF2-SHA-256 secures WPA2 WiFi passwords." Corrected: WPA2 uses PBKDF2 with HMAC-SHA-1 (4,096 iterations) per IEEE 802.11i. PBKDF2-SHA-256 is used in macOS FileVault and enterprise systems, not WPA2.

Email & code signing section: Changed "Every signed PDF" to "Most modern signed PDFs" — legacy PDFs may use SHA-1, and the spec supports SHA-384/512.

Bitcoin section: Changed "A workaround for" to "Likely a defense against" the length extension attack — the reason for double-SHA-256 was never explicitly confirmed by Satoshi Nakamoto.

Device detection (data.js): iPhone 7 Plus was incorrectly labeled as A11 Bionic. Corrected to "A10 Fusion / A11 Bionic" to reflect both possible models sharing the same screen resolution signature.

Inline source citations: Added source links to all ten use case cards in the "SHA-256 is everywhere" section.