How to use the SHA-3 Hash Generator
Generate SHA-3 or Keccak hashes in four steps:
1
Select the variant
Choose SHA3-224, SHA3-256, SHA3-384, or SHA3-512 for NIST-standard output. For Ethereum compatibility, select Keccak-256 (labeled 'ETH').
2
Enter your text
Type or paste any text. The hash is computed using js-sha3 with auto-hash enabled.
3
Choose output format
Select hex lowercase, HEX uppercase, or Base64.
4
Copy the result
Click Copy to grab the hash. The info banner clarifies whether you selected a NIST SHA-3 or Keccak variant.
When to use this tool
Use SHA-3 when you need algorithm diversity or Ethereum-compatible hashing:
- →Generating Ethereum transaction hashes, function selectors, and event signatures (use Keccak-256 variant, not SHA3-256)
- →Computing Solidity keccak256() compatible hashes for smart contract testing and ABI encoding verification
- →Building systems that require cryptographic algorithm diversity — using SHA-3 alongside SHA-2 for defense in depth
- →Government and high-security applications that mandate FIPS 202 (SHA-3) compliance
- →Post-quantum resistant cryptographic systems where SHA-3's sponge construction provides different security properties than SHA-2
- →Research and educational purposes — understanding how Keccak's sponge construction differs from SHA-2's Merkle–Damgård construction
Frequently asked questions
Q:What is the difference between SHA-3 and Keccak-256?
SHA-3 (FIPS 202) and Keccak-256 both use the Keccak sponge construction but apply different padding rules. When NIST standardized Keccak as SHA-3 in 2012, they changed the padding scheme from Keccak's original multi-rate padding to a new suffix-based padding. As a result, SHA3-256('hello') and Keccak-256('hello') produce completely different hash values from the same input. Ethereum chose to use the original pre-NIST Keccak padding, so all Ethereum hashing (transaction IDs, address derivation, keccak256() in Solidity) uses Keccak-256 — not NIST SHA3-256. Always select the Keccak-256 variant when computing Ethereum-compatible hashes.
Q:Why was SHA-3 created if SHA-256 is still secure?
SHA-3 was created for cryptographic algorithm diversity, not because SHA-2 was broken. NIST launched the SHA-3 competition in 2007 partly in response to theoretical concerns about SHA-2's Merkle–Damgård construction (the same structural lineage as the broken MD5 and SHA-1). If a fundamental weakness were discovered in the Merkle–Damgård design, both SHA-1 and SHA-2 would be affected simultaneously. SHA-3's sponge construction is architecturally independent — a catastrophic break in SHA-2 would not affect SHA-3, giving cryptographers a safe fallback. This algorithm diversity is the primary reason governments and high-security systems are adopting SHA-3.
Q:How do I generate an Ethereum function selector using Keccak-256?
Ethereum function selectors are the first 4 bytes of the Keccak-256 hash of the function signature. For example, the selector for transfer(address,uint256) is the first 8 hex characters (4 bytes) of Keccak-256('transfer(address,uint256)'). Select the Keccak-256 variant in this tool, type the function signature exactly (no spaces, canonical type names), compute the hash, and take the first 8 characters. For the transfer example: Keccak-256('transfer(address,uint256)') = a9059cbb..., so the selector is 0xa9059cbb. Event signatures use the full 32-byte (64 hex char) Keccak-256 hash as the topic0.
Q:Is SHA-3 faster or slower than SHA-256?
In pure software implementations, SHA-3 is generally slower than SHA-256 and SHA-512 on most platforms. SHA-3 operates on a 1600-bit state with 24 rounds of the Keccak-f permutation, making it more memory-intensive. SHA-256 benefits from dedicated hardware acceleration (Intel SHA-NI, ARMv8 SHA2 extensions) that software SHA-3 lacks. In dedicated hardware (ASICs, FPGAs), SHA-3 can be very efficient. For JavaScript environments (like this browser-based tool), the difference is imperceptible for typical inputs, but SHA-256 is measurably faster for large file hashing.
Q:Which SHA-3 variant should I use for general-purpose hashing?
SHA3-256 is the recommended general-purpose choice — it matches the 256-bit security level of SHA-256, produces a familiar 64 hex character output, and is the most widely supported SHA-3 variant in cryptographic libraries. Use SHA3-512 for maximum security margin or when long-term future-proofing is critical. Use SHA3-224 or SHA3-384 only when you need to match a specific system or protocol requirement. Avoid Keccak-256 and Keccak-512 unless you specifically need Ethereum compatibility — they are not NIST-standard and may cause interoperability issues with systems expecting FIPS 202 SHA-3.
Q:Does SHA-3 have length extension attack resistance?
Yes — SHA-3's sponge construction is inherently resistant to length extension attacks, which is a significant advantage over SHA-2. In a length extension attack against SHA-256 or SHA-512, an attacker who knows H(message) and the length of the message can compute H(message || extension) without knowing the original message — this breaks naive HMAC constructions. SHA-3's sponge construction absorbs and squeezes independently, making length extension impossible. This means SHA-3(key || message) is safe as a MAC construction, unlike SHA-256 where you must use HMAC to prevent length extension vulnerabilities.