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
- Every value occupies a multiple of 32 bytes. Integers and addresses are left-padded,
bytesNis right-padded. - Negative integers use two's complement at 256 bits.
- Dynamic values are referenced by byte offsets measured from the start of the enclosing tuple or array body.
- A static array
T[k]of staticTis inline; a dynamic arrayT[]starts with its length. - Tuples follow the same head/tail rule recursively, which is how structs and nested arrays are encoded.
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.