Free Ethereum ABI Decoder

uint256, address, bool, string, and bytes32. Dynamic types (arrays, tuples) require manual inspection.

The first 4 bytes of call data, derived from the keccak256 hash of the function signature (e.g., "transfer(address,uint256)").

Yes, completely free.

Absolutely. The Ethereum ABI Decoder processes everything client-side in your browser. No data is uploaded to or stored on any server. Your content remains private on your device at all times.

Yes, the Ethereum ABI Decoder is fully responsive and works on smartphones and tablets. You can use it on any device with a modern web browser -- no app download required.

No account or registration is needed. Simply open the Ethereum ABI Decoder in your browser and start using it immediately. There are no sign-up walls or usage restrictions.

Simply enter your input in the provided field, adjust any settings to your preference, and the tool will process it instantly. You can then copy the result to your clipboard or download it.

The Ethereum ABI Decoder works in all modern browsers including Chrome, Firefox, Safari, Edge, and Opera. For the best experience, use the latest version of your preferred browser.

A uint256 in calldata is a raw integer with no decimal point, so a token transfer amount comes out as a very large number measured in the token's smallest unit. For most ERC-20 tokens that means wei-style units with 18 decimals: the value 1000000000000000000 (0xde0b6b3a7640000) equals exactly 1 token. To convert, divide the decoded integer by 10 raised to the token's decimals. USDC and USDT use 6 decimals, so 1000000 is 1.00, while WBTC uses 8. The decoder reads the 32-byte slot big-endian and shows you the exact integer plus the raw hex it came from, so you can verify the amount yourself. Paste your ABI and calldata to see the precise figure before you trust a wallet prompt.

The decoder computes a Keccak-256 selector for every function in your ABI and compares it to the first 4 bytes of your calldata. When nothing matches, it means the ABI you pasted does not contain the function that was actually called. The usual causes are using the wrong contract's ABI, a proxy contract that forwards calls to a different implementation, or an ABI missing the specific function. A single character difference in a parameter type, such as uint versus uint256, also changes the selector and breaks the match. The fix is to load the verified ABI for the exact contract from a block explorer, then re-decode. The error itself is a useful signal that the transaction is not what you assumed. Double-check the source and try again with the correct ABI.

A function selector is just 4 bytes, the leading slice of the Keccak-256 hash of a canonical signature like transfer(address,uint256), which identifies which function a transaction targets. It tells you the function but nothing about parameter names or how to interpret the bytes that follow. A full ABI is the complete JSON description of a contract's functions, including each input's name and type and its outputs. The decoder needs the ABI, not just the selector, because the 32-byte argument slots are meaningless until you know that one holds an address and the next holds a uint256. With only a selector you can look up a likely signature; with the ABI you get named, typed values. Paste the ABI array here to turn raw hex into a labeled parameter breakdown.

It handles string and bytes by following ABI encoding rules: the static slot holds an offset pointer to a separate region where the length is stored first, followed by the actual data. The decoder reads that pointer, jumps to the length, and reconstructs the text or hex value. Fixed-size static types such as uint256, int, address, bool, and bytes32 each sit in one 32-byte slot and decode cleanly every time. Where it stops short is complex dynamic structures like variable-length arrays and nested tuples, which use multi-part encoding that can require manual inspection rather than a single clean value. For everyday calls such as ERC-20 transfers, approvals, and simple setters, the automatic output is complete. Paste your calldata to see which parameters resolve directly.

Start with the canonical signature: the function name followed by its parameter types in parentheses, comma-separated, with no spaces and no parameter names, for example transfer(address,uint256). Run that exact string through the Keccak-256 hash function and take the first 4 bytes of the 32-byte result. For transfer that produces 0xa9059cbb. The canonical form matters because uint must be written as its full alias uint256 and int as int256, otherwise the hash and selector change entirely. This tool computes selectors with a built-in Keccak-256 implementation directly in your browser, so it never needs the verbose online signature databases to match a call. Load the ERC-20 transfer example to watch a real signature resolve to its selector, then swap in your own function to confirm what a transaction calls.