Is Keccak-256 the same as SHA3-256?

No. Keccak-256 was the algorithm Keccak submitted to NIST; SHA3-256 added two padding bits before finalising. Same input, different output. Ethereum and the EVM use the original Keccak-256.

Where in Ethereum does it show up?

Function selectors, storage slot derivation, EIP-55 checksum addresses, CREATE2 deterministic addresses, and most signing schemes that require a 256-bit digest.

Is the output deterministic for the same input?

Yes. Keccak-256 is a pure function. The same UTF-8 byte sequence always produces the same 32-byte digest, regardless of browser or run.

Does Toova log the input?

No. The hash is computed locally in this tab. The string and the digest never travel to a server.

Can I use this for ABI encoding?

Use Keccak-256 over the canonical function signature like transfer(address,uint256) — exactly the four-byte prefix selectors expect — then take the first 4 bytes of the result.

Keccak-256 Hash — used by Ethereum (EIP-55, EVM)

Drop any UTF-8 string in the input box and read the 32-byte Keccak-256 digest. This is the algorithm Ethereum uses everywhere: EIP-55 checksum addresses, function selectors, storage slot derivation, contract addresses from CREATE2.

Keccak-256 versus SHA3-256

Keccak-256 was Keccak's submission to NIST before it became SHA3. The final SHA3 standard changed the padding rule (multi-rate padding gained two extra bits), so SHA3-256 and Keccak-256 of the same input differ. Ethereum kept the original Keccak so its on-chain hashes match wallet, indexer and explorer implementations that all use Keccak-256 by convention.

Where Ethereum uses it

Function selectors are the first 4 bytes of keccak256("transfer(address,uint256)") and similar canonical signatures. Storage slots for mappings derive from keccak256(abi.encode(key, slot)). EIP-55 mixes case based on keccak256 of the lowercase address. Contract addresses from CREATE2 are keccak256 over deployer, salt and bytecode.

How the implementation runs

The page ships a tiny Keccak-f[1600] permutation in JavaScript. There is no Web Crypto entry for it. You can verify by comparing against the known empty-string digest c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Inputs and outputs never leave the tab.

Frequently Asked Questions

Is Keccak-256 the same as SHA3-256?: No. Keccak-256 was the algorithm Keccak submitted to NIST; SHA3-256 added two padding bits before finalising. Same input, different output. Ethereum and the EVM use the original Keccak-256.
Where in Ethereum does it show up?: Function selectors, storage slot derivation, EIP-55 checksum addresses, CREATE2 deterministic addresses, and most signing schemes that require a 256-bit digest.
How do I verify the implementation?: Hash the empty string and compare against c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Any deviation means the algorithm or padding is wrong.
Is the output deterministic for the same input?: Yes. Keccak-256 is a pure function. The same UTF-8 byte sequence always produces the same 32-byte digest, regardless of browser or run.
Does Toova log the input?: No. The hash is computed locally in this tab. The string and the digest never travel to a server.
Can I use this for ABI encoding?: Use Keccak-256 over the canonical function signature like transfer(address,uint256) — exactly the four-byte prefix selectors expect — then take the first 4 bytes of the result.