Byte order

Bitcoin shows transaction IDs and block hashes with their bytes reversed. Raw data uses the natural order: the 32 bytes exactly as the hash function returns them. Explorers and Bitcoin Core's RPC use the reverse order, the same bytes read backwards. When you copy a hash from raw data into a search box, reverse its bytes first.

What is the natural byte order?

The natural order is the output of the hash function, read from left to right. Programmers call it the internal or native order. Raw transactions and block headers use it.

Two parts of raw data use the natural order:

• Inputs. Each input refers to an earlier transaction by its TXID, in natural order.
• Block headers. The previous block hash field holds the hash of the block before, in natural order.

The hash of the genesis block, block 0, is 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 in natural order. Its five zero bytes sit at the right end. The reverse form, with the zeros first, is the one people search for.

What is the reverse byte order?

The reverse order is the same 32 bytes read from the other end. Explorers, search boxes and RPC calls use it, so it is also called the RPC or display order. Some write-ups call it network byte order, but that term usually means big-endian, so avoid it here. The genesis block hash becomes 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f. That is the form our explorer shows for block 0.

Bitcoin Core returns hashes in this order too. Some write-ups call the natural order "little-endian". That name belongs to numbers, and a hash is a string of bytes, not a number. The little-endian page explains that separate idea.

Which byte order do you use where?

Where you are	Byte order	Example
Raw transaction input	Natural	Previous TXID c997a5…3704
Raw block header, previous block hash	Natural	b91fd2b0…00000
Raw block header, merkle root	Natural	330b3201…0908e38
Explorer search or address bar	Reverse	0437cd7f…97c9
Bitcoin Core RPC, such as getblockhash	Reverse	000000000019d6…ce26f

How does a block header store its hashes?

The header of block 717,664 stores its hashes in natural order. Its previous block hash field holds the hash of block 717,663. Reverse those 32 bytes and you get the hash that explorers show for block 717,663.

Previous block hash, raw:       b91fd2b09d4a8238ad4c814e4fa0ab9ed34bf0f75a3a00000000000000000000
Previous block hash, explorer:  000000000000000000003a5af7f04bd39eaba04f4e814cad38824a9db0d21fb9

The same header stores its merkle root in natural order. Explorers show that root reversed.

Merkle root, raw:       330b32016c8176153071283d3e5fe87c2318b3fd41d6ca1b1a8bf12670908e38
Merkle root, explorer:  388e907026f18b1a1bcad641fdb318237ce85f3e3d2871301576816c01320b33

How does a transaction store its TXIDs?

The transaction in block 170 is one of the best known on the chain. Satoshi Nakamoto sent 10 BTC from it to Hal Finney, and the other output of 40 BTC returned to Satoshi. Its raw bytes hash to 169e1e83…4f18f4 in natural order. Reversed, that is f4184fc5…9e16, the TXID you search for on an explorer. Open that transaction to see it.

Its input spends an earlier output. The input stores that transaction's hash as c997a5…3704 in natural order. Reversed, the hash is 0437cd7f…97c9, the TXID of a transaction in block 9. Open that earlier transaction to see the output being spent.

Why are the bytes reversed?

Satoshi never explained the choice. The reasons below are the usual explanations, not documented decisions.

Bitcoin treats a block hash as a number, because a miner checks whether the hash is below the target. The natural bytes, read as a little-endian integer, give that number. Written out in natural order, the bytes look backwards to people. So the display form puts the most significant bytes first.

For the genesis block, the hash read this way is 10628944869218562084050143519444549580389464591454674019345556079. The target for difficulty 1 is 26959535291011309493156476344723991336010898738574164086137773096960. The hash is smaller, so it meets the target.

Transaction IDs are reversed as well, although Bitcoin never compares them as numbers. The usual explanation is consistency: one rule for both kinds of hash is simpler than two. Hal Finney, an early Bitcoin developer, argued that a hash is just a string of bytes. To him, reversing one was as pointless as reversing a sentence.

Why not change it?

Developers would find one order everywhere simpler. But explorers, wallets and tools have used the reverse form for years. Changing it would confuse more people than it would help, so new developers learn it as one of Bitcoin's quirks.

Do merkle roots also reverse?

Yes, when explorers display them. The block header stores the merkle root in natural order, as it stores the other hashes. You rarely search for a merkle root, so this seldom causes trouble. Know the rule when you read a raw header.

How do you flip the bytes in code?

Reverse the bytes, not the characters. Reversing the hex string character by character gives a wrong value. Take 6fe2, which is two bytes, 6f and e2. Reversing the characters gives 2ef6, which is two different bytes. Reverse the pairs of characters instead.

h = "6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000"
print(bytes.fromhex(h)[::-1].hex())
# 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

Keep the natural order in your code, and reverse only when you display a hash or search for one. The block header reference on developer.bitcoin.org lists each header field, including the two hashes.

What is the short version?

Raw data uses the natural order, and people use the reverse order. The bytes are the same in both. When you move a hash between a raw transaction and a search box, reverse its 32 bytes. Start with bytes if you need a refresher on what a byte is.