What this SHA3-256 generator does
This tool computes the SHA3-256 hash of any text, returning a 256-bit value as 64 hexadecimal characters. SHA-3 is the most recent NIST-standardised hash family (FIPS 202) and uses a completely different internal structure from SHA-2, making it a genuinely independent security primitive for protocols that want structural diversity or length-extension immunity.
How SHA3-256 works: the Keccak sponge
SHA-3 is built on the sponge construction over the Keccak-f[1600] permutation. Unlike SHA-2’s Merkle-Damgård structure, a sponge has no separate compression function — instead it absorbs input into a large state and squeezes output out of it.
State: 1600 bits arranged as a 5×5 matrix of 64-bit lanes.
Rate and capacity for SHA3-256: rate = 1088 bits (136 bytes), capacity = 512 bits. The capacity determines the security level; 512 bits of capacity gives 256 bits of collision resistance via the birthday bound.
Padding: The input is padded with the FIPS 202 multi-rate padding rule — append 0x06, zero-pad to a multiple of 136 bytes, then set the highest bit of the last byte to 1 (OR 0x80). The 0x06 byte is the domain-separation suffix that distinguishes SHA3-256 from Keccak-256 (0x01) and SHAKE functions (0x1f).
Absorption: The padded message is XOR’d into the state 136 bytes at a time, and after each block the Keccak-f[1600] permutation runs 24 rounds of five step mappings:
- θ (theta) — XOR each lane with the parity of two adjacent columns.
- ρ (rho) — rotate each lane by a lane-specific offset.
- π (pi) — permute lane positions.
- χ (chi) — non-linear mixing within each row.
- ι (iota) — XOR a round constant into lane (0,0).
Squeezing: After all blocks are absorbed, the first 256 bits of the state are squeezed out as the digest.
Browsers do not implement SHA-3 natively in the Web Crypto API, so this tool runs the Keccak permutation in pure JavaScript using BigInt arithmetic for correct 64-bit lane operations.
Key difference from Keccak-256 (Ethereum)
The table below shows why SHA3-256 and Keccak-256 give different outputs for the same input:
| Property | SHA3-256 | Keccak-256 (Ethereum) |
|---|---|---|
| Padding suffix byte | 0x06 | 0x01 |
| FIPS standard | Yes (FIPS 202) | No (pre-standard) |
| Length-extension safe | Yes | Yes |
| Empty string digest | a7ffc6f8...8f8434a | c5d24601...5d85a470 |
Reference values
| Input | SHA3-256 digest |
|---|---|
| (empty) | a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a |
abc | 3a985da74fe225b2045c172d6bd390bd855f086e3e9d525b46bfe24511431532 |
message | f4f6779a153d411b173d7b4f97670e2fcf5fcf0fc697f16c7c81aabc8cb68d05 |
Verify the tool by typing abc and checking the digest matches.
Length-extension immunity
SHA-2 functions (SHA-256, SHA-512) are vulnerable to length-extension attacks when used naively as MACs. An attacker who knows SHA256(secret || message) and the length of the secret can compute SHA256(secret || message || padding || extension) without knowing the secret. SHA-3 is immune to this because the capacity bits (hidden from the output) cannot be reconstructed from the digest, so no extension is possible. If you use a hash as a MAC, use HMAC-SHA-256 or switch to SHA3-256 directly.
When to choose SHA3-256
- Structural diversity — if you want a second independent hash in a protocol alongside SHA-256 (e.g., for dual-hash signatures), SHA3-256 is the natural companion since it uses a completely different construction.
- Length-extension immunity without HMAC — SHA3-256 can safely be used as
SHA3-256(key || message)without the HMAC wrapper. - Post-quantum caution — some analysis suggests sponge-based designs handle certain quantum-adversary models differently from Merkle-Damgård designs.
- Not for Ethereum — if you are computing Ethereum addresses, event topics, or function selectors, you need Keccak-256, not SHA3-256.