Endianness

Endianness is the order of bytes used to represent a number. The same sequence of bytes can have different numeric values when read in different orders.

Contents

What byte order means

An integer stored in several bytes assigns a different weight to each byte. Each position is worth 256 times the position below it. The most significant byte carries the greatest weight; the least significant byte carries the smallest.

Big-endian places the most significant byte first. Little-endian places the least significant byte first. The names describe the order of whole bytes, not the order of bits or hexadecimal digits within each byte.

A single-byte value has the same numeric interpretation in either order. For several bytes, the format of the field tells you which order to use.

The same bytes, two numbers

Example 1: Read the sequence 01 02

Original bytes: 01 02
Byte length: 2 bytes
Big-endian: 258
Little-endian: 513

Big-endian: (1 × 256) + 2 = 258.
Little-endian: 1 + (2 × 256) = 513.

Both calculations start with exactly the same bytes. Choosing a different numeric interpretation does not change the input sequence. To understand why a byte has values from zero to 255, see Bits, Bytes, and Hexadecimal.

Writing the same number in either order

Reading bytes is different from encoding a number. If we want to store the number 258 in a two-byte field, its bytes depend on the specified byte order.

Example 2: Encode the integer 258 in two bytes

Byte order	Stored bytes	Decoded integer
Big-endian	`01 02`	`258`
Little-endian	`02 01`	`258`

The value stays the same because each sequence is read using the order that was used to write it.

Field width matters as well. The integer 1 in a four-byte field is 00 00 00 01 in big-endian order and 01 00 00 00 in little-endian order. A format may require all four bytes even though the value could fit in one.

Byte reversal moves pairs of hex digits together. Reversing 12 34 gives 34 12, not 43 21. Reversing the individual characters would also change the byte values.

Byte order in Bitcoin

Many Bitcoin numeric fields use little-endian serialization. Examples include a block header's timestamp and nonce, a transaction's locktime, and its output amounts. An output amount is an integer count of satoshis; its signed type and permitted values are discussed in Data Types.

Example 3: A four-byte little-endian field

Bytes	Little-endian integer	Big-endian integer
`01 00 00 00`	`1`	`16,777,216`

If the field is specified as little-endian, its value is 1. The other interpretation is a comparison, not an alternative valid reading of that field.

Bitcoin does not use one byte order for every kind of data. For example, network ports in the peer-to-peer version message use big-endian order. The extra numeric bytes following a CompactSize marker use little-endian order. Always follow the particular field's definition.

Hashes and display order

A hash is a sequence of bytes with its own purpose; it does not become a monetary amount simply because its bytes can be read as an integer. Bitcoin Core's usual hexadecimal display of transaction and block identifiers reverses the byte order relative to their internal byte sequence.

This convention can make an identifier in an explorer look different from the corresponding bytes in serialized data. It is a display convention for those identifiers, not a rule to reverse every hash, public key, script, or piece of text.

Likewise, reversing the UTF-8 bytes for hello would change the text to olleh. The endianness of a numeric interpretation does not tell you to rearrange text.

Try the interpreter

Open the Data Interpreter to try these examples.

In the Data Interpreter, choose Hex and enter 01 02. Interpret with Endian: Big. Compare the big-endian integer 258 with the little-endian integer 513.
Change Endian to Little and interpret again. The selected integer is now 513; the input bytes and their length remain the same.
Enter 01 00 00 00 and compare the numeric readings shown in Example 3.

Hex input supplies bytes directly. In Auto or Binary format, input such as 0b100000010 supplies an integer instead: the interpreter writes 258 as 01 02 for Big or 02 01 for Little. This is why changing byte order can affect the normalized bytes for numeric input while preserving bytes supplied as hex.

The tool's numeric interpretations are unsigned. It does not recognize a transaction field or choose that field's required byte order for you.