What is ABI encoding?

ABI (Application Binary Interface) encoding is the rule for how Solidity types are packed into the bytes that travel on EVM calldata, return data, and event topics. The standard pads each static parameter to 32 bytes and uses an offset table for dynamic types. Every Ethereum tool that calls contracts has to encode and decode according to this rule.

How do I decode an Etherscan input field?

Copy the input hex from the Etherscan transaction details, switch to Decode mode, paste the parameter types from the function signature, and paste the hex (drop the first 4 bytes if you only want the parameters; keep them if you want the full call). The tool returns a JSON array of decoded values.

Why does my decoded number look enormous?

Token amounts are stored as raw integer wei equivalents. A transfer of 1 USDC (6 decimals) shows as 1000000. A transfer of 1 ETH shows as 1000000000000000000 (18 decimals). To convert to a human readable number, divide by 10 to the power of the token decimals.

Can I encode dynamic types like string and bytes?

Yes. The ABI spec handles string, bytes, T[], and tuples (T1, T2, ...). The tool uses viem.parseAbiParameters which supports all standard ABI grammar. Pass the value as the natural JSON form: a string for string, a hex prefixed value for bytes, an array for arrays, an object or array for tuples.

What about function selector + parameters together?

Full calldata is the 4 byte function selector concatenated with the encoded parameters. To decode full calldata, use this tool to decode the parameters (drop the leading 8 hex chars after 0x), and use the Keccak256 Hash Generator to compute selectors from a function signature. The two tools cover the round trip together.

Do you support struct (tuple) decoding?

Yes. Solidity tuples are written as parenthesised type lists in the ABI. For a struct like { address owner; uint256 amount; }, use the type string (address, uint256). For arrays of structs use (address, uint256)[]. The tool decodes the tuple as a JS array in declaration order.

Is my input sent anywhere?

No. Encoding and decoding run in your browser via viem. Open DevTools and watch the network tab while you paste calldata to confirm. There is no third party fetch in the path between the input fields and the result panel.

ABI Encoder & Decoder (EVM, Free)

About this tool

What this tool answers

The ABI Encoder & Decoder converts between Solidity parameter values and the hex calldata that travels on the EVM. Use it when reading raw transactions, debugging an unverified contract, building calldata by hand for a multisig, or sanity checking what your client library actually sent.

Etherscan can decode parameters only when a contract is verified. This tool needs only the parameter types you supply, so it works for any calldata: unverified contracts, MEV bot internals, internal calls inside a multisig batch, or hex pulled from a debug trace.

How to use it

Pick Encode or Decode at the top. In Encode mode, paste the parameter types as a comma separated string (for example, address, uint256) and the values as a JSON array. The tool returns the hex calldata bytes.

In Decode mode, paste the same types you expect plus the hex calldata. If the hex starts with a 4 byte function selector, drop the first 8 hex characters after the 0x to decode just the parameters. The tool returns a JSON array of decoded values, with bigints serialised as strings to preserve precision.

How the ABI codec works

The tool uses viem.encodeAbiParameters and decodeAbiParameters, which implement the official Solidity ABI spec. Static types occupy exactly 32 bytes each. Dynamic types (string, bytes, T[], tuples with dynamic members) place an offset in their slot and append the actual data after the static section.

All processing runs in your browser. There is no fetch, no third party request, no logging. The tool works fully offline once the page is loaded.

Where the encode and decode usually fail

The most common error is a type mismatch. If you encoded with uint256 but try to decode as uint128, the offsets shift and decoding either fails or returns wrong values. The types must match exactly.

The second is including or omitting the function selector. The 4 byte selector is not part of ABI encoded parameters; it sits in front of them. If you copied the full Etherscan input field, drop the first 8 hex chars after the 0x to decode parameters only. If you want to decode an entire call as a function, use the function signature workflow in the Keccak256 generator together with this tool.

When this tool is the right one

Use this tool any time you have hex bytes and need typed values, or typed values and need hex bytes. It is right for inspecting unverified contracts, building calldata for Gnosis Safe transactions, debugging client libraries, and writing test fixtures.

It is not the right tool when you need full transaction decoding (the function name and contract context too). For that, use a verified contract on Etherscan, or run a local trace with Tenderly or Foundry. The ABI codec only knows the parameter shape; it does not know the function name or which contract you called.

Tracking down a calldata bug?

Calldata mismatches between client libraries and contract expectations cause silent reverts and lost funds. Bring the trace for a focused review.

Book a smart contract review

Frequently asked questions

What is ABI encoding?: ABI (Application Binary Interface) encoding is the rule for how Solidity types are packed into the bytes that travel on EVM calldata, return data, and event topics. The standard pads each static parameter to 32 bytes and uses an offset table for dynamic types. Every Ethereum tool that calls contracts has to encode and decode according to this rule.
How do I decode an Etherscan input field?: Copy the input hex from the Etherscan transaction details, switch to Decode mode, paste the parameter types from the function signature, and paste the hex (drop the first 4 bytes if you only want the parameters; keep them if you want the full call). The tool returns a JSON array of decoded values.
Why does my decoded number look enormous?: Token amounts are stored as raw integer wei equivalents. A transfer of 1 USDC (6 decimals) shows as 1000000. A transfer of 1 ETH shows as 1000000000000000000 (18 decimals). To convert to a human readable number, divide by 10 to the power of the token decimals.
Can I encode dynamic types like string and bytes?: Yes. The ABI spec handles string, bytes, T[], and tuples (T1, T2, ...). The tool uses viem.parseAbiParameters which supports all standard ABI grammar. Pass the value as the natural JSON form: a string for string, a hex prefixed value for bytes, an array for arrays, an object or array for tuples.
What about function selector + parameters together?: Full calldata is the 4 byte function selector concatenated with the encoded parameters. To decode full calldata, use this tool to decode the parameters (drop the leading 8 hex chars after 0x), and use the Keccak256 Hash Generator to compute selectors from a function signature. The two tools cover the round trip together.
Do you support struct (tuple) decoding?: Yes. Solidity tuples are written as parenthesised type lists in the ABI. For a struct like { address owner; uint256 amount; }, use the type string (address, uint256). For arrays of structs use (address, uint256)[]. The tool decodes the tuple as a JS array in declaration order.
Is my input sent anywhere?: No. Encoding and decoding run in your browser via viem. Open DevTools and watch the network tab while you paste calldata to confirm. There is no third party fetch in the path between the input fields and the result panel.