Ethereum Function Selector (EVM)

How to use the EVM function selector

Type the function signature you want to check into the text field. You can paste it with the parameter names exactly as you see them in the contract documentation. Then click the “Calculate selector” button. The result also appears automatically when the page loads, so you immediately see the tool working on the default value.

1. Type or paste a signature, for example transfer(address to, uint256 amount).
2. Click “Calculate selector.”
3. Read the three results: the canonical form, the full Keccak-256 hash, and the 4-byte selector.

For the default value, the canonical form is transfer(address,uint256), the full Keccak-256 hash is 0xa9059cbb2ab09eb219583f4a59a5d0623ade346d962bcd4e46b11da047c9049b, and the 4-byte selector is 0xa9059cbb. If the signature is invalid, an error message appears instead of the results. The entire calculation runs locally in your browser.

What is a function's canonical signature

A canonical signature is the simplest, unambiguous way to describe a function: its name, parentheses, and the list of parameter types, without variable names or extra words. That form is the basis for the rest of the calculation.

The tool normalizes the text you enter using several rules:

• removes the optional function prefix and parameter names,
• removes the words memory, calldata, storage, indexed, and payable,
• changes uint to uint256 and int to int256,
• changes byte to bytes1, including when the parameter is an array, for example uint[] becomes uint256[],
• splits parameters by commas only at the top level of parentheses, so nested parentheses do not break the list.

The result always has the form name(type1,type2,...). This means two people writing the same function in different ways — one with parameter names, one without — get an identical description.

Keccak-256 vs. SHA3-256 in Ethereum

Ethereum does not use the version of SHA3-256 that was later standardized. It uses Keccak-256, an earlier version of the same family with different input padding. That is why Keccak-256 and SHA3-256 produce different results for the same text.

The tool computes Keccak-256 from the canonical form encoded in UTF-8. You get 32 bytes, shown as 0x plus 64 hexadecimal characters. This is exactly the same hash Ethereum uses to derive a function selector.

If you see the term “SHA3” in an Ethereum context, it almost always means Keccak-256. It is worth remembering, because computing SHA3-256 would give a different string and therefore a different selector.

How to read the 4-byte selector and full hash

A function selector is the first 4 bytes of the Keccak-256 hash. In hexadecimal notation, that means 0x plus 8 characters — exactly what you see in the “Selector (4 bytes)” row. The full hash has 32 bytes, or 0x plus 64 characters, and it appears in the “Keccak-256” row.

In practice, the selector tells you which contract function a transaction calls, while the full hash can be useful when you compare entire signatures. Note that the selector is always the beginning of the full hash — the first eight characters after 0x.

Tool limitations: tuples, type aliases, and ABI parsing

The tool normalizes signatures and computes the hash. It is not a full ABI parser or a contract code analyzer. Below are the main limits to know before using the result.

• Tuples and complex types. Nested parentheses do not split the parameter list, but with complex types, structs, and tuples, check for yourself that the notation matches the definition in the contract.
• Type aliases. Only the abbreviations described above are converted: uint, int, and byte. If you use a custom type name or an alias outside that list, it is treated literally and the result reflects your input.
• No contract verification. The tool does not fetch source code or contract definitions, and it does not confirm that the function actually exists at a given address. You need to verify that yourself, for example in the project documentation or verified code.
• Data scope. The tool does not read files, fetch results, or keep a calculation history. Everything happens locally in your browser, and nothing is sent to a server.
• One signature at a time. You check a single entry, so if you have many functions, repeat the same step for each one separately.

If the result will go into production code, treat it as a starting point and compare it with the function definition in the contract. That way you can be sure the parameter types and their order match what actually runs on the network.

Frequently asked questions

This tool calculates locally in your browser; before using a selector in production, verify the canonical signature against ABI/Solidity documentation, especially for complex types.