What does this Ethereum transaction actually do?
You are looking at a smart contract transaction (a program running on the Ethereum blockchain) and you see something like 0xa9059cbb000000...0de0b6b3a7640000. The first ten characters are not random. That is the function selector, a short identifier telling the contract: *"call the transfer function"*.
This tool does two things. First: type a function signature like transfer(address,uint256) and get its 4-byte identifier (0xa9059cbb). Those are the 4 bytes that appear at the start of every transaction calling that function.
Second: paste a raw calldata blob (the hex from a transaction), the tool extracts the selector, looks it up in a built-in registry of ~30 common functions (ERC-20, NFTs, Uniswap, WETH, proxies, ENS), and shows you what arguments were passed.
Everything runs locally in your browser, no API calls, no data leaving your device. Perfect for debugging wallet transactions, reading pending transactions on Etherscan, or just learning how the EVM ABI works.
How to use it
- Pick a mode at the top: Compute selector (you know the function name, you want the identifier) or Decode calldata (you have a hex blob and want to know what it does).
- In Compute selector mode: type the function signature like functionName(argType1,argType2). No spaces, no argument names, just the types. The 4-byte result appears instantly.
- In Decode calldata mode: paste the full transaction hex (with 0x or without). The tool reads the first 4 bytes and looks them up in the built-in registry. If found, it shows the function name and a parameter table. If not, you can paste the signature manually.
- Click the example chips under the input (transfer, approve, swap) to see how common operations look.
- The list at the bottom is the built-in selector registry (~30 common ones). Click any entry to autofill the input.
- string, bytes, and array arguments are marked as *"(dynamic type)"* and skipped, full decoding requires complex offset logic (out of scope here). Addresses and integers decode just fine.
When this is useful
Six typical situations where the selector gives you a concrete answer:
- Debugging a weird wallet transaction. Something disappeared from your wallet and you do not know what you clicked. Copy the calldata from Etherscan, paste it here, you see immediately: *"ah, this was approve for unlimited USDT to some random contract"*. Now you know what to revoke.
- Reading a pending transaction on Etherscan. You want to know what the contract is about to do before you sign in MetaMask. Paste the *"Input Data"* field, you see: *"swapExactTokensForTokens, a DEX swap"*. Brain relaxes.
- Building an integration with a smart contract. You need to construct calldata by hand (e.g. for a multicall or a non-standard framework). You compute the selector for each function, concatenate with the arguments. This is step one.
- Learning how the ABI works. Your first day with Solidity and someone throws *"function selector"* at you. Type transfer(address,uint256), you get 0xa9059cbb, change it to Transfer(...) (capital T), totally different selector. So even capitalisation matters. Lesson learned.
- Security review of a contract. You have a suspicious transaction that allegedly called *"claimAirdrop"*, but something feels off. Compute the selector for claimAirdrop() and check whether it matches the first 4 bytes of the calldata. If it does not, someone tried to fool you.
- Writing Foundry / Hardhat tests. You need to hardcode a selector in a test (e.g. for expectRevert(bytes4)). Compute it here, copy, paste into the test. No need to install cast or set up a separate toolchain.