ABI Encoder / Decoder

What is ABI Encoder / Decoder?

ABI (Application Binary Interface) Encoder/Decoder is a free tool for encoding and decoding Ethereum smart contract function call data. It converts human-readable function signatures and parameters into hexadecimal calldata that can be sent to smart contracts, and vice versa.

This tool is essential for blockchain developers working with smart contracts, debugging transactions, or building dApps on Ethereum and EVM-compatible chains.

What is ABI in Ethereum?

ABI (Application Binary Interface) is a specification that defines how to interact with Ethereum smart contracts. It describes the functions available in a contract, their parameters, and return types. The ABI encoder converts function calls into bytecode that the EVM can execute.

What is calldata?

Calldata is the encoded data sent with a transaction to a smart contract. It consists of a 4-byte function selector (first 8 hex characters after 0x) followed by ABI-encoded parameters. For example, calling transfer(address,uint256) generates calldata like 0xa9059cbb000000...

How do I encode a function call?

Enter the function signature (e.g., transfer(address,uint256)) and parameters as a JSON array. The tool will generate the complete calldata including the function selector and encoded parameters. This calldata can be used in web3 transactions or for debugging.

How do I decode transaction input data?

Paste the transaction input data (calldata) from any EVM transaction. If you know the function signature, provide it for detailed parameter decoding. Otherwise, the tool will show the function selector and raw data. This is useful for analyzing transactions on block explorers.

Which blockchains are supported?

This tool works with all EVM-compatible blockchains including Ethereum, BSC, Polygon, Arbitrum, Optimism, Avalanche, and any other chain that uses the Ethereum Virtual Machine and follows ABI encoding standards.

How is the 4-byte function selector calculated from a signature?

Take the function signature like transfer(address,uint256), apply Keccak-256 (NOT regular SHA-256), and take the first 4 bytes. The signature must have NO spaces and use canonical type names: address, uint256 not uint, bytes32 not bytes. transfer(address,uint256) hashes to 0xa9059cbb...

How does ABI encoding handle dynamic-size types like string and bytes?

Dynamic types use a two-part scheme: head contains offsets (32 bytes each), tail contains length + padded data. For transfer(address,uint256) all params are static so they pack directly. For setMessage(string), the string param emits its offset in head then its UTF-8 length and content padded to 32-byte chunks in tail.

Can I decode calldata when I do not know the function signature?

Partially. The first 4 bytes are the selector — query it against open databases like 4byte.directory or Openchain.xyz to find candidate signatures. Without the signature you cannot decode parameters reliably because ABI is type-aware. The tool links out to these databases for lookup.

Why does my encoded calldata differ from web3 ethers.js output?

Ethers.js uses canonical type aliases (uint -> uint256, int -> int256, bytes -> bytes-dynamic) and may differ if you pass non-canonical types. Also check parameter ordering — JSON arrays must match the signature order. Ethers also automatically encodes function() to selector 0x without arguments; some tools omit the trailing zero bytes.

Common Use Cases

• Encode ERC20 token transfers for contract interactions
• Decode transaction input data from Etherscan or block explorers
• Test smart contract function calls before deployment
• Debug failed transactions by analyzing calldata
• Build custom transactions for multisig wallets
• Analyze DeFi protocol interactions (Uniswap swaps, etc.)