Keccak256 is a 256 bit cryptographic hash function used by Ethereum and Solidity. It takes any input and produces a deterministic 32 byte hash. The same input always produces the same output, but a single bit change scrambles the entire result. Ethereum uses it for function selectors, event topics, mapping storage slots, signature recovery, and merkle proofs.

What is keccak256 used for in Solidity?

Solidity uses keccak256 for function selector derivation, event topic hashing, mapping slot calculation, EIP-712 typed data hashing, merkle leaf hashing, and signature recovery preparation. Every external function call in the EVM is dispatched by the first 4 bytes of the keccak256 hash of its canonical signature, which is why selector derivation is the most common keccak256 use case in Solidity development.

Is keccak256 the same as SHA-3?

Not exactly. Keccak256 was the algorithm that won the SHA-3 competition, but NIST standardised SHA-3-256 with 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 online tool computes and what every smart contract on Ethereum uses.

Why does abi.encodePacked sometimes give different results than abi.encode?

Solidity has two ABI encodings. abi.encode pads each parameter to 32 bytes and prevents collisions across argument boundaries. 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 abi.encode for hash inputs unless you have a specific reason.

Does this keccak256 online 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. The output is identical to what your contract would produce.

Is my input sent to a server when I hash with keccak256 online?

No. The hash runs entirely in your browser using the viem library. No analytics, no third party request, no logging, no server side processing. Open DevTools and watch the network tab while you type to confirm. This is why the tool is safe for sensitive inputs such as commitment schemes and signing payloads.

Keccak256 Hash Generator Online (Free, Solidity)

Direct answer

Keccak256 is a 256 bit cryptographic hash function used by Ethereum and Solidity. This online keccak256 hash generator computes the exact same hash that the Solidity keccak256 builtin produces, including the 4 byte function selector for any function signature. All hashing happens in your browser using viem, so no input is ever sent to a server.

Example

Input: transfer(address,uint256)

Hash: 0xa9059cbb2ab09eb219583f4a59a5d0623ade346d962bcd4e46b11da047c9049b

Selector: 0xa9059cbb

About this tool

What this keccak256 hash generator answers

Use the generator 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, hex bytes, and function signature.

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 the keccak256 online tool

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 keccak256 differs from SHA-3

Keccak256 and NIST SHA-3-256 share the same underlying sponge construction but use different padding. Keccak uses the original Keccak padding from the SHA-3 competition submission. NIST SHA-3-256 added a domain separation suffix during standardisation. The two functions produce different outputs for the same input, and that difference is the single most common bug when developers move between non Ethereum and Ethereum tooling.

Ethereum kept the original Keccak padding for backward compatibility, which is why Solidity keccak256 is the Ethereum variant rather than the NIST standard. If you used a generic SHA-3-256 tool you almost certainly got a hash that does not match what your contract produces. This generator uses the Ethereum keccak variant, which is the right one for any on chain workflow.

Function selector derivation

A function selector is the first 4 bytes of the keccak256 hash of a canonical function signature. The canonical form drops parameter names and spaces. For transfer(address to, uint256 amount) the canonical signature is transfer(address,uint256). The selector is the first 4 bytes of keccak256("transfer(address,uint256)"), which is 0xa9059cbb.

Every external contract call in the EVM begins with the selector so the dispatcher knows which function to invoke. Etherscan, Foundry, and Hardhat all use selectors to recognise function calls in raw calldata. The same selector can be derived from any keccak256 implementation as long as the canonical signature is correct.

Code examples for keccak256 in Solidity, ethers.js, and Python

In Solidity, the builtin keccak256(bytes) takes a bytes value. For a string, wrap it: bytes32 h = keccak256(bytes("transfer(address,uint256)")). For an ABI encoded payload, use keccak256(abi.encode(arg1, arg2)) rather than abi.encodePacked unless you have audited for collision risk.

In ethers.js v6, import keccak256 and toUtf8Bytes from ethers and call keccak256(toUtf8Bytes("transfer(address,uint256)")). In viem, call keccak256(toBytes("transfer(address,uint256)")). In Python with eth-utils, call keccak(text="transfer(address,uint256)").hex(). All four implementations produce the same 32 byte hash for the same input, which is what makes keccak256 cross tool reliable.

Where keccak256 gotchas usually catch developers

The most common bug is mixing up keccak256 and NIST SHA-3-256, addressed above. 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.

The third bug is forgetting that string input is first UTF-8 encoded before hashing. If your data contains characters outside ASCII, the hash depends on the encoding. The fourth is using a tool that defaults to NIST SHA-3 instead of Ethereum keccak. This generator defaults to the Ethereum keccak variant so the output always matches what your contract produces.

When this hash generator is the right tool 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 and a different output for the same input.

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 is keccak256?: Keccak256 is a 256 bit cryptographic hash function used by Ethereum and Solidity. It takes any input and produces a deterministic 32 byte hash. The same input always produces the same output, but a single bit change scrambles the entire result. Ethereum uses it for function selectors, event topics, mapping storage slots, signature recovery, and merkle proofs.
What is keccak256 used for in Solidity?: Solidity uses keccak256 for function selector derivation, event topic hashing, mapping slot calculation, EIP-712 typed data hashing, merkle leaf hashing, and signature recovery preparation. Every external function call in the EVM is dispatched by the first 4 bytes of the keccak256 hash of its canonical signature, which is why selector derivation is the most common keccak256 use case in Solidity development.
Is keccak256 the same as SHA-3?: Not exactly. Keccak256 was the algorithm that won the SHA-3 competition, but NIST standardised SHA-3-256 with 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 online tool computes and what every smart contract on Ethereum uses.
What is a function selector and why is it 4 bytes?: A function selector is the first 4 bytes of the keccak256 hash of a canonical function signature like transfer(address,uint256). Every external contract call in the EVM begins with the selector so the dispatcher knows which function to invoke. Four bytes is enough entropy to avoid accidental collisions across the function space of a contract while keeping calldata small.
Why does abi.encodePacked sometimes give different results than abi.encode?: Solidity has two ABI encodings. abi.encode pads each parameter to 32 bytes and prevents collisions across argument boundaries. 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 abi.encode for hash inputs unless you have a specific reason.
Does this keccak256 online 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. The output is identical to what your contract would produce.
Is my input sent to a server when I hash with keccak256 online?: No. The hash runs entirely in your browser using the viem library. No analytics, no third party request, no logging, no server side processing. Open DevTools and watch the network tab while you type to confirm. This is why the tool is safe for sensitive inputs such as commitment schemes and signing payloads.