Ethereum ABI Encoder / Decoder

Turn a function signature plus arguments into exact calldata, or paste calldata from a transaction and decode it. Full ABI v2 support: nested arrays, tuples, dynamic bytes and strings, with a word-by-word breakdown.

Integers may be decimal or 0x hex (quotes optional). Addresses, bytes and strings are quoted. bytesN accepts 0x hex or text.
Examples:

Computed in your browser with JavaScript. Addresses are never uploaded or stored.

What is ABI encoding?

ABI encoding is the Solidity contract ABI specification's rule for turning a function call into bytes: a 4-byte selector followed by the arguments packed into 32-byte words, with static values inline and dynamic values (bytes, strings, dynamic arrays) placed after a head that holds their byte offsets. An ABI encoder builds that calldata from a signature and values; a decoder reverses it.

How the layout works

For f(uint256,uint32[],bytes10,bytes) called with (0x123, [0x456, 0x789], "1234567890", "Hello, world!") the encoding is: the selector 0x8be65246, then the head of four words (the uint256, an offset of 0x80 to the array, the bytes10 right-padded, an offset of 0xe0 to the bytes), then the tail: the array length 2 and its two elements, then the bytes length 13 and the padded data. Click "Solidity docs f()" above to see it word by word.

Rules in brief

Worked example: an ERC-20 transfer

transfer(address,uint256) with recipient 0x1111111111111111111111111111111111111111 and 25 USDT (25,000,000 raw units) encodes to 68 bytes: selector a9059cbb, then 12 zero bytes of left padding followed by the 20-byte address, then 25,000,000 = 0x17d7840 left-padded to a 32-byte word. Every ERC-20 transfer in every explorer has exactly this shape, which is why the decoder can name the function and recover the arguments from the selector alone.

Related

Compute selectors alone with the function selector tool; convert token amounts to raw integers with the token decimals converter; inspect single words with the hex to decimal converter.

Frequently asked questions

What is ABI encoding?

The Application Binary Interface defines how arguments are laid out in a transaction's data field: a 4-byte selector followed by 32-byte words. Static types are placed inline; dynamic types (bytes, string, dynamic arrays, tuples containing them) are referenced by an offset in the head and placed in the tail.

How do I write the arguments?

As a JSON array in parameter order. Integers may be plain or 0x hex, with or without quotes; large values should be quoted or written in hex. Addresses and strings are quoted. Arrays and tuples are nested arrays, for example [[1,2],[3]] for uint256[][].

Why does my decoded value show as a string?

Integers larger than 253 cannot be represented exactly as JSON numbers, so all integers are shown as decimal strings. Addresses are shown EIP-55 checksummed.

Can I decode a transaction from Etherscan?

Yes. Copy the input data, paste it with the function signature, and the selector is checked against the signature before decoding. If the selector does not match you get an error instead of garbage.

What is the difference between abi.encode and abi.encodePacked?

abi.encode follows the standard rules above and pads every value to 32 bytes, so it can be decoded. abi.encodePacked concatenates values at their minimal width with no padding or offsets; it is shorter but ambiguous and cannot be decoded without knowing the types. This tool implements the standard encoding only.

Does it support custom errors and events?

The encoding rules are identical, so you can encode or decode error data with the error's signature. Event logs are different: non-indexed parameters are ABI-encoded in the data field, so decode that part with a signature containing only the non-indexed types.