What does keccak256 compute?

Keccak256 takes any input and produces a deterministic 32 byte (256 bit) hash. The same input always produces the same hash, but a single bit change in the input scrambles the entire output. Ethereum uses keccak256 for event topics, function selectors, mapping storage slots, signature recovery, and merkle proofs.

Is keccak256 the same as SHA-3?

Not exactly. Keccak256 was the algorithm that won the SHA-3 competition, but the NIST standardised SHA-3-256 uses a different padding scheme. Ethereum kept the original Keccak padding. The two functions produce different outputs for the same input. Solidity keccak256 is the Ethereum variant, which is what this tool computes.

What is a function selector?

A function selector is the first 4 bytes of the keccak256 hash of a canonical function signature like transfer(address,uint256). Every contract call begins with the selector so the EVM knows which function to dispatch. Etherscan, Foundry, and Hardhat all use selectors to recognise function calls in raw calldata.

Why does encodePacked sometimes give different results than encode?

Solidity has two ABI encodings. abi.encode pads each parameter to 32 bytes and prevents collision. abi.encodePacked concatenates without padding, which is shorter but can collide. For example, encodePacked(string a, string b) and encodePacked(string c) can hash to the same value if the concatenation matches. Use encode for hash inputs unless you have a specific reason.

Does this tool work with Solidity hex literals?

Yes. Switch to the hex tab and paste any 0x prefixed hex string. The tool treats it as raw bytes, the same way Solidity does when you write keccak256(bytes memory data). For string inputs, the tool first encodes UTF-8 then hashes, which matches the keccak256(bytes(string)) Solidity pattern.

Are there hash collisions to worry about?

For 256 bit outputs the probability of an accidental collision is negligible (around 2^-128 for any pair of distinct inputs). Practical collision risks come from chosen prefix attacks against weak schemes like encodePacked, not from keccak256 itself. Use abi.encode rather than encodePacked for safety.

Is my input sent to a server?

No. The hash runs in your browser using the viem library. No analytics, no third party request, no logging. Open DevTools and watch the network tab while you type to confirm.

Keccak256 Hash Generator (Solidity, Free)

About this tool

What this generator answers

The Keccak256 Hash Generator computes the same hash that Solidity's built in keccak256 produces. Use it when you need to derive a function selector, compute an event topic, calculate a mapping storage slot, or sanity check a value before signing or storing it on chain.

The tool supports three input modes. UTF-8 string is the default and matches the Solidity pattern keccak256(bytes(string)). Hex bytes treats the input as raw bytes the way Solidity treats hex literals. Function signature mode computes both the full hash and the 4 byte selector that goes into EVM calldata.

How to use it

Pick the input mode that matches your data. For most use cases UTF-8 string is correct. If you are working with raw bytes from a transaction trace or a Solidity bytes literal, switch to hex. If you have a function signature like transfer(address,uint256) and want the calldata selector, switch to function signature mode.

Paste the input. The hash updates on every keystroke. The result panel always shows the full 32 byte hash; in signature mode it also shows the 4 byte selector. Copy buttons sit beside each output for fast workflow.

How the hash is computed

The tool uses viem.keccak256 under the hood. For string input, the text is first UTF-8 encoded into bytes and then hashed. For hex input the bytes are used directly. For function signatures the canonical form (no spaces, parameter types only) is hashed and the first 4 bytes are extracted.

All hashing runs in your browser. No request leaves the page. There is no API call, no telemetry, and no shared state. You can open DevTools and confirm the network tab stays empty while you type.

Where keccak256 gotchas usually catch developers

The most common bug is mixing up keccak256 and NIST SHA-3-256. They are different algorithms with different padding. If you used a generic SHA-3-256 tool you got a hash that does not match Solidity. This tool uses the Ethereum keccak variant, which is the right one.

The second most common bug is using abi.encodePacked when abi.encode is safer. encodePacked concatenates parameters without padding, which can produce hash collisions across different parameter combinations. For inputs to keccak256 prefer abi.encode unless you have a specific reason and you have audited for collision risk.

When this tool is the right one and when it is not

Use this tool for any Solidity facing keccak256 calculation: function selectors, event topic derivation, mapping slot calculation, signature recovery prep, merkle leaf hashing, and EIP-712 type hashing.

It is not the right tool for SHA-256 (Bitcoin, generic web), NIST SHA-3-256 (some non Ethereum chains), Poseidon (zkSNARK friendly hashes), or Blake2 (used by some Cosmos chains). Each of those is a different algorithm with different security properties.

Building a contract that needs careful hash design?

EIP-712 typed data, merkle distributions, and signature recovery all hinge on getting hash inputs right. Bring the design for a focused review.

Book a smart contract review

Frequently asked questions

What does keccak256 compute?: Keccak256 takes any input and produces a deterministic 32 byte (256 bit) hash. The same input always produces the same hash, but a single bit change in the input scrambles the entire output. Ethereum uses keccak256 for event topics, function selectors, mapping storage slots, signature recovery, and merkle proofs.
Is keccak256 the same as SHA-3?: Not exactly. Keccak256 was the algorithm that won the SHA-3 competition, but the NIST standardised SHA-3-256 uses a different padding scheme. Ethereum kept the original Keccak padding. The two functions produce different outputs for the same input. Solidity keccak256 is the Ethereum variant, which is what this tool computes.
What is a function selector?: A function selector is the first 4 bytes of the keccak256 hash of a canonical function signature like transfer(address,uint256). Every contract call begins with the selector so the EVM knows which function to dispatch. Etherscan, Foundry, and Hardhat all use selectors to recognise function calls in raw calldata.
Why does encodePacked sometimes give different results than encode?: Solidity has two ABI encodings. abi.encode pads each parameter to 32 bytes and prevents collision. abi.encodePacked concatenates without padding, which is shorter but can collide. For example, encodePacked(string a, string b) and encodePacked(string c) can hash to the same value if the concatenation matches. Use encode for hash inputs unless you have a specific reason.
Does this tool work with Solidity hex literals?: Yes. Switch to the hex tab and paste any 0x prefixed hex string. The tool treats it as raw bytes, the same way Solidity does when you write keccak256(bytes memory data). For string inputs, the tool first encodes UTF-8 then hashes, which matches the keccak256(bytes(string)) Solidity pattern.
Are there hash collisions to worry about?: For 256 bit outputs the probability of an accidental collision is negligible (around 2^-128 for any pair of distinct inputs). Practical collision risks come from chosen prefix attacks against weak schemes like encodePacked, not from keccak256 itself. Use abi.encode rather than encodePacked for safety.
Is my input sent to a server?: No. The hash runs in your browser using the viem library. No analytics, no third party request, no logging. Open DevTools and watch the network tab while you type to confirm.