ABI Encoder / Decoder
Encode Ethereum smart contract calldata from function signatures and parameters. Decode raw hex calldata back into typed values.
Parsed: transfer — 2 param(s): address, uint256
ABI Encoding Reference
| Type | Encoding | Dynamic? |
|---|---|---|
| address | Left-pad to 32 bytes | No |
| uint256 / int256 | 32-byte big-endian | No |
| bool | 0 or 1, left-padded to 32 bytes | No |
| bytes32 | Right-pad with zeros to 32 bytes | No |
| string / bytes | Offset + length + data (32-byte aligned) | Yes |
What is the Ethereum ABI?
The Ethereum Application Binary Interface (ABI) is the standard way to interact with contracts in the Ethereum ecosystem — both from outside the blockchain and for contract-to-contract interaction. It encodes function calls and events into bytes that the EVM can interpret. Understanding the ABI is essential for debugging transactions, writing tests, and building tooling around smart contracts.
ABI Encoding Rules
Every parameter in an ABI call is encoded as one or more 32-byte (256-bit) slots. Static types occupy exactly one slot. Dynamic types (string, bytes) use a 32-byte pointer in the header that points to the actual data location. The data section begins with a 32-byte length prefix followed by the padded content. Understanding these rules lets you manually craft or verify calldata for any contract call.
Function Selectors and Event Topics
The 4-byte function selector uniquely identifies which function to call in a contract. It is computed as the first 4 bytes of the Keccak-256 hash of the function's canonical signature. Event topics work similarly but use the full 32-byte hash. Knowing how to compute selectors lets you identify calls in transaction traces, filter logs, and debug unexpected reverts.
Frequently Asked Questions
What is Ethereum ABI encoding?
The Application Binary Interface (ABI) defines how data is encoded when calling Ethereum smart contracts. Function calls are encoded as a 4-byte selector (first 4 bytes of the Keccak-256 of the signature) followed by ABI-encoded parameters. Static types (uint, address, bool, bytesN) are packed into 32-byte slots; dynamic types (string, bytes) use an offset pointer followed by length and data.
How is a function selector computed?
The function selector is the first 4 bytes of the Keccak-256 hash of the canonical function signature, e.g., 'transfer(address,uint256)'. There are no spaces, no parameter names — only the function name and comma-separated canonical type names. For example, keccak256('transfer(address,uint256)') gives 0xa9059cbb.
What is the difference between static and dynamic ABI types?
Static types (uint256, address, bool, bytes32) are always encoded as exactly 32 bytes in place. Dynamic types (string, bytes, and arrays) cannot be known at compile time, so they are encoded using an offset pointer in the head section and the actual data (length prefix + content) in the tail section.
Can I import an ABI from Etherscan?
Yes. On the Decode tab, expand the 'Import ABI JSON' section and paste the ABI JSON array from Etherscan or your compilation output. The tool will parse all function signatures and let you click to select one for decoding.
Is this tool safe to use with sensitive contract data?
Yes. All ABI encoding and decoding happens entirely in your browser. No calldata or ABI is sent to any server. This tool is ideal for inspecting transactions, debugging calldata, or preparing manual calls.