How to Decode Input Data on BscScan to See What a Transaction Did

06 November 2026

When you look at a BNB Chain transaction on BscScan, the "Input Data" field often shows a long hexadecimal string that looks like gibberish. This string is the raw data sent to the smart contract, telling it exactly what function to run and with what parameters. Decoding it reveals the actual action - whether swapping tokens, approving a transfer, or calling a specific contract function. You can decode it directly on BscScan using its built-in decoder, without needing any external tools.

What input data contains

Every transaction that interacts with a smart contract includes input data. This data has two parts:

• Function selector: The first 4 bytes (8 hexadecimal characters) of the input data. This identifies which function the contract should execute. For example, 0x095ea7b3 is the selector for the approve function in BEP-20 tokens.
• Parameters: Everything after the selector, encoded according to the contract's ABI (Application Binary Interface). These are the arguments passed to the function - addresses, numbers, or other values, each padded to 32 bytes.

If the transaction is a simple BNB transfer (sending BNB to another address), the input data field is usually empty or shows 0x. Only contract interactions produce non-empty input data.

Step-by-Step: decoding on bscscan

BscScan includes a "Decode Input Data" feature that works for most common contracts. Here is how to use it:

1. Open the transaction page on BscScan. Find the transaction hash (TxHash) from your wallet or explorer search.

2. Scroll to the "Input Data" section. It is below the transaction details. You will see a long hex string, often collapsed by default. Click "Click to show more" to expand it.

3. Click the "Decode Input Data" button. This button appears directly below the hex string. BscScan will attempt to match the function selector to a known contract ABI.

4. Review the decoded output. If successful, you will see:

5. Function name: The name of the contract function called (e.g., swapExactTokensForTokens, approve, transfer).
6. Parameters: Each argument listed with its name, type, and decoded value. For example, an approve call shows spender (the address being approved) and amount (the token amount).

If the contract is not verified (its source code not published), BscScan cannot decode it. You will see "No data available" or the raw hex remains.

When Decoding Fails

Decoding fails for three main reasons:

• Unverified contract: The contract's ABI is not on BscScan. Many anonymous or newly deployed contracts are unverified. You cannot decode them through BscScan alone.
• Non-standard encoding: Some contracts use custom encoding that does not match standard ABI rules. This is rare but possible.
• Corrupted or malformed data: A bug in the caller's code or a failed transaction can produce invalid input data.

For unverified contracts, you have two alternatives:

• Use a block explorer with decompilation: Sites like Tenderly or Blocksec's Phalcon can sometimes reverse-engineer the function selector and guess the parameters, though results are not always accurate.
• Manually decode using the contract ABI: If you have the ABI (from the contract's source code or an API), you can use a tool like the cast command-line tool from Foundry or an online ABI decoder. This requires technical knowledge of Solidity types and hex encoding.

Reading Decoded Parameters

Once decoded, you need to interpret the values correctly:

• Addresses: Shown in full (e.g., 0x1234...abcd). Some addresses may be wrapped in 0x padding - ignore leading zeros.
• Numbers: Usually displayed as decimal (e.g., 1000000000000000000). For token amounts, divide by the token's decimals (often 18). So 1000000000000000000 equals 1 token with 18 decimals.
• Booleans: Shown as true or false.
• Bytes: Raw hex data, sometimes representing strings or other nested data.

For swaps on PancakeSwap or similar DEXes, the decoded data will show the path of tokens (input token, output token) and the amounts. This tells you exactly what the transaction swapped and for how much.

Why you might need to decode

Most users do not need to decode input data for routine transactions. Your wallet or DApp interface already shows you what the transaction does before you confirm it. However, decoding is useful when:

• Verifying a suspicious transaction: If you see unexpected activity in your wallet, decoding the input data can reveal what a malicious contract attempted to do.
• Auditing a contract interaction: Developers or advanced users may want to confirm exact parameters sent to a contract, especially when debugging failed transactions.
• Checking approval details: For token approvals, decoding shows exactly how many tokens were approved and to which address. This is more precise than the "Token Approvals" page, which sometimes aggregates data.

Limitations and Caveats

• BscScan's decoder works only for verified contracts on BNB Chain. It does not decode Ethereum mainnet or other EVM chains without switching the explorer.
• The decoded data is the input to the contract, not the output. It tells you what the transaction tried to do, not what the contract actually did. For example, a transaction may call approve but the contract could revert silently. Always check the transaction status (Success/Failed) separately.
• Some contracts use proxy patterns where the implementation contract is different from the proxy. BscScan may decode using the proxy's ABI instead of the implementation's, which can show incorrect function names or parameters. Use the "Read as Proxy" option if available.

Decoding input data on BscScan is a straightforward way to understand exactly what a BNB Chain transaction intended to do. For verified contracts, one click reveals the function and parameters. For unverified ones, you need external tools or the contract's ABI.

Back to bnb chain