Transaction Calldata Decoder

Paste raw calldata and get a readable breakdown — no ABI needed for common ERC-20/721/1155 and DEX functions.

transfer(address,uint256)

selector 0xa9059cbb

to (address)

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045

amount (uint256)

100000000000000000

Reading calldata without knowing what it is first

Block explorers and wallets often show calldata as an opaque hex blob unless they already have the contract’s verified ABI on file. But a huge share of real-world calldata is calling one of a small set of extremely common functions — token transfers, approvals, NFT transfers, DEX swaps. This tool checks the calldata’s 4-byte selector against a curated list of those signatures first, so you often don’t need the ABI at all.

What to do when it’s not recognized

An unrecognized selector isn’t a dead end — it means the function isn’t in this tool’s built-in list, not that it’s necessarily unusual. The raw 32-byte words are still shown so you can inspect them manually, and if you track down (or already know) the exact signature, the ABI Encoder/Decoder on this site will decode it precisely.

How this tool works

Each known signature is hashed once with viem to build a selector lookup table entirely client-side. Matching calldata is decoded with decodeFunctionData; everything happens locally in your browser.

Frequently asked questions

The ABI Decoder needs you to already know (and supply) the exact function signature. This tool works the other way around — paste calldata alone, and it checks the selector against a built-in list of common ERC-20/721/1155 and DEX-router functions to figure out the signature itself.

You still get the 4-byte selector and the raw calldata split into its 32-byte argument words — useful for manual inspection, or as a starting point if you separately track down the signature and switch to the ABI Decoder.

In principle a 4-byte space has collisions, though real ones are rare and usually flagged as suspicious when found deliberately. More commonly, the exact same signature is reused across standards — transferFrom(address,address,uint256) means the same thing, and has the same selector, whether it's an ERC-20 or ERC-721 token.

It's a genuinely useful sanity check — but treat it as one signal, not a guarantee. A decoded "transfer 5 USDC" call tells you what the function does structurally; it doesn't tell you whether the contract itself is trustworthy. Always verify you're interacting with the contract address you expect.

No. Selector lookup and decoding both happen locally in your browser using viem — nothing is transmitted.