What this Keccak-256 generator does
This tool computes the original Keccak-256 hash of any text, returning a 256-bit value as 64 hexadecimal characters. This is the exact function used across Ethereum — by Solidity’s keccak256, the EVM SHA3 opcode, address derivation, and ABI function selectors — and it differs from NIST’s SHA3-256.
How it works
Keccak-256 uses the Keccak sponge construction over the Keccak-f[1600] permutation, with a 1088-bit rate (136 bytes) and a 512-bit capacity. The input is padded using the original Keccak rule — append 0x01, zero-pad to 136 bytes, set the last byte’s high bit — then absorbed block-by-block into a 1600-bit state matrix. Each absorption applies 24 rounds of five step mappings: theta (column parity mixing), rho (lane rotation), pi (lane permutation), chi (non-linear mixing), and iota (round constant XOR). After all blocks are absorbed, the first 256 bits are squeezed out as the digest.
The sole difference from FIPS 202 SHA3-256 is the padding suffix byte: Keccak uses 0x01, NIST SHA3-256 uses 0x06. This one-byte change produces entirely different digests for the same input.
Ethereum uses and practical examples
Address derivation
An Ethereum address is derived from a public key by hashing the 64-byte uncompressed public key (without the 0x04 prefix) with Keccak-256 and taking the last 20 bytes (40 hex characters). The EIP-55 checksum then encodes the address with mixed case.
Function selectors
The ABI function selector is the first 4 bytes of the Keccak-256 hash of the function signature. Type it in this tool with no spaces around the commas:
| Signature | Keccak-256 first 8 chars (selector) |
|---|---|
transfer(address,uint256) | a9059cbb |
approve(address,uint256) | 095ea7b3 |
balanceOf(address) | 70a08231 |
totalSupply() | 18160ddd |
Event topics
Solidity event signatures are hashed the same way. The topic Transfer(address,address,uint256) hashes to 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef, which you will recognise as the first topic on any ERC-20 Transfer log.
Storage slots
Mapping slot keys in EVM storage are computed as keccak256(abi.encode(key, slot)), where slot is the mapping’s position in storage. This tool can verify a slot calculation by concatenating the 32-byte key and 32-byte slot number in hex.
Reference values
| Input | Keccak-256 digest |
|---|---|
| (empty) | c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 |
abc | 4e03657aea45a94fc7d47ba826c8d667c0d1e6e33a64a036ec44f58fa12d6c45 |
hello | 1c8aff950685c2ed4bc3174f3472287b56d9517b9c948127319a09a7a36deac8 |
The empty-string digest is the canonical Ethereum Keccak-256 test vector and differs from SHA3-256’s a7ffc6f8... output for the same reason: the padding byte.
Important: Keccak-256 is not SHA3-256
If you are writing a Solidity contract or parsing Ethereum logs, you need Keccak-256 (0x01 padding), not the NIST SHA3-256 standard (0x06 padding). Many general-purpose cryptography libraries implement SHA3-256 but not the pre-standard Keccak-256. This tool implements the Ethereum-compatible version. If you need the NIST standard, use the SHA3-256 generator instead.