UtilityToolsLab

© 2026 UtilityToolsLab. Built and maintained by the UtilityToolsLab Team.

Free eBooks·About·Changelog·Privacy Policy·Terms of Service·Report a bug
HomeBlockchain EncodingRLP Encoder

Related Tools

Base58 EncoderKeccak-256EIP-55 ChecksumSatoshi/BTC

RLP Encoder / Decoder (Ethereum)

Decode a raw Ethereum RLP payload into its fields, or serialise a nested structure back into bytes. Shows every item, length prefix and nesting level.

You Might Also Like

All Blockchain Encoding

Base58 Encoder

Encode bytes or text to Base58 and Base58Check, or decode a Base58 string back to hex with a full checksum check. Runs entirely in your browser.

Keccak-256

Compute the Keccak-256 hash of text or raw hex bytes entirely in your browser — the Ethereum variant, not NIST SHA-3. No uploads, ever.

EIP-55 Checksum

Apply or validate the EIP-55 mixed-case checksum on any Ethereum address. Shows checksummed, lowercase, and uppercase forms with instant copy.

Satoshi/BTC

Convert between Satoshi, Bit, mBTC and BTC with BigInt precision. No floating-point rounding at the satoshi level, no price feed, no network call.

Ethereum stores almost nothing as JSON. Transactions, receipts and every node of the state trie are serialised with Recursive Length Prefix, a format holding exactly two data types: a byte string, and a list of byte strings. The RLP Encoder / Decoder runs it in both directions, so you can paste a raw transaction and read its fields, or write a structure and get the bytes a client would put on the wire.

What surprises people is that RLP carries no type information at all. There are no field names, no integers, no booleans. A 20-byte string is a recipient address purely because of where it sits in the list, and 0x means the number zero and the empty string at the same time. The decoder therefore reports positions, byte counts and nesting depth rather than inventing labels it has no way to know.

Encoding is written as JSON, because RLP’s shape is JSON’s without objects. A quoted string is UTF-8 text, a 0x… string is raw bytes, a whole number becomes its minimal big-endian form, and an array is a list. Nothing is uploaded; every byte is built in the tab you have open.

Walkthrough: Nine Fields Out of One Transaction

The box opens already holding 0xf86c098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a76400008025a028ef61340bd939bc2195fe537567866003e1a15d3c71ff63e1590620aa636276a067cbe9d8997f761aecb703304b3800ccf555c9f3dc64214b297fb1966a3b6d83, the signed legacy transaction published in EIP-155 itself. Decoding it reports 110 bytes and nine items at one level of nesting: a nonce of 0x09, a gas price of 0x04a817c800 (20 Gwei), a gas limit of 0x5208 (21000), the recipient 0x3535353535353535353535353535353535353535, a value of 0x0de0b6b3a7640000 (one ether), calldata that is empty and shows as 0x (empty), then 0x25 for v and the two 32-byte halves of the signature. The control most people walk past is Round trip: it pushes whatever you are looking at into the opposite mode, so that decoded structure goes back to the encoder and rebuilds the same 110 bytes.

The Algorithm: Four Rules and the 55-Byte Line

  • A single byte below 0x80 is its own encoding, with no prefix whatsoever. This is why 0x0f stays one byte long while 0x8f becomes two.
  • A byte string of 55 bytes or fewer gets one prefix byte, 0x80 plus its length. The empty string is 0x80 and nothing else.
  • The 55-byte line is the whole design. At 55 bytes the prefix is 0xb7, a single byte. At 56 the format switches to a length-of-the-length form and spends two: 0xb8 to say “one length byte follows”, then 0x38 for the 56. Cross that boundary and the encoding grows by a byte in a place people do not expect.
  • Lists repeat those same two shapes at 0xc0 and 0xf7, measured over the combined length of the encoded children rather than their count. A nine-field transaction runs past 55 bytes of payload, which is why the sample begins 0xf8.
  • Because those rules leave exactly one legal encoding per value, the decoder re-encodes whatever it just read and compares. Matching bytes earn a canonical badge; differing bytes raise a warning, since consensus code rejects a non-minimal payload even when its contents parse cleanly.

What Happens When a Payload Will Not Decode

  • Append four stray bytes to a valid payload and the tool refuses rather than reading the first item and shrugging: “Trailing data — the first item ends at byte 9 but 4 more follow. An RLP payload holds exactly one item.”
  • Lose a character and the digit count is reported back, because an odd number of hex digits leaves one nibble with no byte to sit in. A prefix promising more bytes than remain is named with the offset it failed at instead of a generic parse error.
  • A long-form length starting with a zero byte is rejected outright. It decodes unambiguously, but it is not the minimal encoding, so accepting it would let two different payloads mean the same thing.
  • On the encode side, whole numbers stop at 9007199254740991, since anything larger cannot survive JSON parsing intact. Write those as a 0x… string, which is how the sample carries a value of one ether. Objects, nulls and booleans are refused with the reason, and the convention for a boolean is 0x01 against 0x.
  • Nesting is capped at 64 levels and input at 200,000 characters, which keeps a pathological payload of nothing but list prefixes from locking the tab.
Whitespace and an optional 0x prefix are ignored
Decoded structure
[
  "0x09",
  "0x04a817c800",
  "0x5208",
  "55555555555555555555",
  "0x0de0b6b3a7640000",
  "0x",
  "%",
  "0x28ef61340bd939bc2195fe537567866003e1a15d3c71ff63e1590620aa636276",
  "0x67cbe9d8997f761aecb703304b3800ccf555c9f3dc64214b297fb1966a3b6d83"
]
110 bytes encoded10 items1 levels of nesting

Canonical — re-encoding this structure reproduces the input byte for byte.

Item by item
rootlist · 9 items
[0]1 byte0x09
[1]5 bytes0x04a817c800
[2]2 bytes0x5208
[3]20 bytes0x3535353535353535353535353535353535353535“55555555555555555555”
[4]8 bytes0x0de0b6b3a7640000
[5]0 bytes0x (empty)
[6]1 byte0x25“%”
[7]32 bytes0x28ef61340bd939bc2195fe537567866003e1a15d3c71ff63e1590620aa636276
[8]32 bytes0x67cbe9d8997f761aecb703304b3800ccf555c9f3dc64214b297fb1966a3b6d83

RLP carries no type information. A decoded 20-byte string is a recipient address only because of where it sits in the list, and 0x means both the number zero and the empty string. That is why the decoder shows positions and byte counts rather than guessing field names. Everything is computed in this tab.