Solidity ABI Encoder / Decoder

Every call to a smart contract on the EVM arrives as a byte string: four bytes of selector followed by tightly packed, 32-byte-padded parameters. Solidity ABI Encoder / Decoder builds that string from a function signature and a set of typed values, and reverses the process for raw calldata you paste in from a block explorer. Nothing leaves the browser.

The tool covers the full head/tail layout the ABI specification defines for mixed static and dynamic types. Static types (integers, booleans, addresses and fixed-size byte arrays) land directly in the head slot. Dynamic types (bytes and string) put a 32-byte offset in the head and append their length-prefixed data to the tail. Decode mode verifies the 4-byte selector before reading a single parameter, so a mismatched signature produces a clear error rather than silently returning garbage values.

Worked Example: Encoding an ERC-20 Transfer

Press Load Sample and Encode mode loads transfer(address,uint256) with the address 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 and the value 1000000000000000000 (1 ETH expressed in wei). The output is:

• Selector 0xa9059cbb — first 4 bytes of keccak256("transfer(address,uint256)")
• Param 0 (address) — the 20-byte address right-padded to 32 bytes: 000000000000000000000000d8da6bf269…
• Param 1 (uint256) — 1 × 10¹⁸ as a 32-byte big-endian integer: 0000000000000000000000000000000000000000000000000de0b6b3a7640000

Click Decode beside the calldata output to send it straight to Decode mode and see the values recovered from the bytes. The round-trip confirms the encoding is correct before submitting a transaction.

Supported Types and Their Limits

• uint/int: any width from 8 to 256 in multiples of 8. A value of -1 on int256 encodes as ff...ff (32 bytes of 0xff) via two’s complement. Entering a negative value for a uint type returns “uint cannot be negative.”
• address: a 20-byte hex string with or without 0x prefix, lower or mixed case. The tool accepts both EIP-55 checksummed and unchecksummed addresses; the encoded form is always lowercase and zero-padded to 32 bytes.
• bytes1–bytes32: fixed-size; left-aligned and right-zero-padded to 32 bytes. A bytes3 value of 0xabcdef must be exactly 3 bytes (6 hex chars); providing 4 bytes returns “bytes3 requires exactly 3 bytes.”
• bytes (dynamic): enter as hex with or without 0x. The encoder writes the byte count as a uint256, then the data padded to the next 32-byte boundary.
• string: UTF-8 encoded. A 25-character ASCII string such as Hello from the blockchain occupies exactly one 32-byte data word after its 32-byte length prefix.

Edge Cases Worth Knowing

• Selector verification in Decode mode. The first 4 bytes of the calldata must match the Keccak-256 selector for the signature you provide. If they differ, the tool reports the mismatch and stops. This catches the common mistake of pasting calldata from one function and decoding it with another’s signature.
• Mixed static + dynamic parameters shift all offsets. In registerUser(address,string,uint256) the string in the middle means the head contains three 32-byte slots (one for each parameter in order) before any tail data begins. The offset in the string’s head slot is therefore 3 × 32 = 96 bytes, not 32.
• Parameter names are stripped automatically. Pasting transfer(address recipient, uint256 amount) encodes identically to transfer(address,uint256). The selector hash is always computed from the canonical, name-free form.
• uint256 max is approximately 1.16 × 10⁷⁷. Values above this ceiling for any uint<N> type produce a range-exceeded error. The tool uses BigInt throughout, so values up to the ceiling encode without floating-point error.