Solidity Function Selector Calculator & Lookup
Compute 4-byte selectors with Keccak-256 or reverse-lookup a selector — batch mode, all client-side
Reverse lookup: selector → function
Paste a calldata selector (e.g. 0xa9059cbb) to find which common function it calls. Matching runs against 66 built-in signatures — no network requests.
Function signatures (one per line)
Selectors (3)
0xa9059cbb
transfer(address,uint256)
0x095ea7b3
approve(address,uint256)
0x70a08231
balanceOf(address)
About the Function Selector
Every Ethereum smart contract function is identified on-chain by its 4-byte selector: the first four bytes of the Keccak-256 hash of its canonical signature. When a wallet or dapp calls transfer(address,uint256), the calldata starts with 0xa9059cbb — that value is the selector. Selector collisions and interface matching make this small hash a daily concern for Solidity developers and auditors.
Paste one or many function signatures to compute their selectors instantly. This matches exactly what Solidity keccak256(abi.encodeWithSignature(...)), Foundry cast sig, and ethers.js Interface.getSighash produce — the hashing runs entirely in your browser.
How to use
- Enter one function signature per line, e.g. transfer(address,uint256).
- Each 4-byte selector is computed instantly with Keccak-256.
- Verify the selector matches the calldata prefix in your transaction.
- Use Copy all to export selector + signature pairs for your notes or ABI work.
Frequently Asked Questions
What is a Solidity function selector? ▾
The first 4 bytes of the Keccak-256 hash of the function signature, e.g. 0xa9059cbb for transfer(address,uint256). It identifies which function a transaction calls in the calldata.
Does this match Foundry cast sig and ethers.js output? ▾
Yes. Selector computation is standardized: Keccak-256 of the canonical signature string, first 4 bytes. Results match cast sig, ethers.js getSighash, and web3.js encodeFunctionSignature.
Why do two of my functions have the same selector? ▾
It is rare but possible - 4 bytes allow collisions. The compiler warns on collisions within one contract; across contracts it is usually harmless unless an ABI proxy forwards calls.
What function is selector 0xa9059cbb? ▾
0xa9059cbb is transfer(address,uint256) — the ERC-20 transfer function. It is the most common selector seen in Ethereum calldata. Other frequently encountered selectors: 0x095ea7b3 is approve(address,uint256), 0x23b872dd is transferFrom(address,address,uint256), 0x70a08231 is balanceOf(address). Paste any selector into the reverse lookup above to match it against a dictionary of common signatures.
Can two different functions have the same 4-byte selector? ▾
Yes. The selector is only the first 4 bytes of a 32-byte Keccak-256 hash, so collisions exist by construction — roughly 50% probability once you gather around 77,000 signatures, and deliberate collision attacks (like the 2021 transfer/transfer30541730497GoldDuplex case) are a known attack vector for unprotected fallback routing. Solidity compilers since 0.4.x reject exact-match collisions in a single contract. The lookup above flags dictionary collisions when your input produces a selector it already knows.
What is a function selector? ▾
The first four bytes of keccak256 of a function's canonical signature — transfer(address,uint256) becomes 0xa9059cbb. The EVM dispatches calls by these bytes alone, which is why signatures must match exactly.
Why does my selector differ from the contract's? ▾
Signatures must use canonical types: uint not uint256 in the string you hash is wrong — it is the reverse, uint256 is canonical while uint is the alias. Type mismatches and typo'd argument order produce different selectors that silently call nothing.
Can I look up unknown selectors? ▾
Yes — the tool computes keccak256 locally and matches against common signature databases for 4-byte lookups, helping you reverse-engineer unlabeled transactions.