Calldata
decoder.

Selectors

40+

computed locally via keccak

Custom

Any

paste a signature to decode

Network

None

zero requests

Auth

None

no wallet, no signup

/23—CALLDATA DECODER

awaiting input

▸ /notes

Selectors are truncated keccak.

The 4-byte selector is the keccak-256 of the signature cut short, which you can reproduce in the hash playground. Truncation means collisions exist, so a selector match is strong evidence, not proof.

Read before you sign.

Wallet confirmation screens show calldata hex for a reason. Pasting it here answers the question that matters: which function, which recipient, how much. An unlimited approve looks very different from a transfer once decoded.

Events are the other half.

Calldata is what a transaction asked for; event logs are what actually happened. The event topic decoder covers that side with the same local-only approach.

▸ /faq

What is a function selector?

The first 4 bytes of calldata: the keccak-256 hash of the function signature, truncated. 0xa9059cbb is keccak("transfer(address,uint256)") cut to 4 bytes, which is why the same selector appears in every ERC-20 transfer ever made.

Why does my selector come up unknown?

This page ships a local table of the most common signatures and computes their selectors in your browser. Anything else needs the signature text: paste it into the signature field and the decoder verifies it hashes to your selector before decoding. Public databases like 4byte.directory index millions of signatures.

Can it decode tuple (struct) arguments?

Recognized functions with tuple parameters are labeled, and the raw 32-byte words are shown with offsets so you can read them manually. Flat types (addresses, integers, bools, bytes, strings, and arrays of them) decode fully.

Is anything sent to a server?

No. Selector hashing and argument decoding run entirely in your browser. Calldata often contains addresses and amounts you may not want to share, so this tool deliberately makes no network requests.

Calldatadecoder.