Block hash vs transaction hash: what's the difference?

Two hashes, two jobs

A transaction hash identifies one transaction. A block hash identifies one block - and indirectly, every transaction it contains. Both look like long hex strings, often 32 bytes (64 hex characters), so people mix them up. Block explorers treat them as different lookups against different indexes.

The quick mental model: a transaction is a single event. A block is a sealed envelope full of transactions, plus metadata, plus a link to the previous envelope. The hash of an envelope is not the hash of any letter inside it.

What a transaction hash is

A transaction hash is the fingerprint of one signed transaction. On EVM chains it is the Keccak-256 of the RLP-encoded transaction. On UTXO chains like Bitcoin it is the double-SHA-256 of the serialized transaction. On Solana the role is filled by the first signature, base58-encoded.

You use a tx hash to:

• pull up the parties, amount, and fee for one transaction;
• check whether it confirmed, reverted, or is still pending;
• prove that a specific transfer or contract call happened;
• thread a single payment across services that all see the same on-chain record.

See how to read a transaction hash for the format details.

What a block hash is

A block hash is the fingerprint of one block. Every chain hashes the block header - the structure that contains the block number, the previous block hash, a Merkle or state root over the included transactions, a timestamp, and consensus-specific fields. The hash of that header is the block's identity.

You use a block hash to:

• pin a specific block independent of any reorg;
• verify the parent-child relationship that makes the chain a chain;
• audit which transactions were included in a particular block;
• check finality conditions on the chain (an old enough block is effectively immutable).

The block hash is what makes a blockchain a blockchain. Each block header includes the previous block's hash, so changing any historical block changes that block's hash, which breaks every descendant's "previous hash" pointer. That is the integrity guarantee in one line.

Why they look so similar on EVM

On EVM chains, both block hashes and transaction hashes are written as a 0x prefix followed by 64 lowercase hex characters - 32 bytes either way. Visually identical:

tx hash:    0xabcdef...64 hex chars
block hash: 0x012345...64 hex chars

There is no shape clue. You have to know which kind of identifier you copied. If you paste one at an explorer's wrong endpoint - /tx/ for a block hash, or /block/ for a transaction hash - you get a "not found" result, because each endpoint searches its own index.

This is one place where tx.taxi helps. The router classifies 64-character hex strings as ambiguous between block and transaction on EVM-family chains, and can offer both options. The configured primary explorer often handles either kind on its search bar, so the redirect lands on the right page automatically.

Block height as a third identifier

Most chains let you address a block in two ways:

• By hash - the cryptographic identifier, globally unique.
• By height (sometimes called "block number") - a simple counter starting at zero for the genesis block and incrementing by one per block.

Height is shorter and easier to remember. Saying "block 12345678" is more human than reciting 64 hex characters. The trade-off: height only makes sense in the context of a specific chain. The same height number exists on every chain, pointing to a different block on each.

Hash is content-addressed. The same hash points to the same block on the same chain regardless of which fork you are looking at. During a reorg, two competing blocks at the same height have different hashes; the losing one becomes an orphan and disappears from the canonical chain.

For day-to-day lookups, height is fine. For audit and historical work, hash is safer.

How tx.taxi disambiguates

When you paste a value, the classifier looks at three signals in order:

1. Prefix. A T start on a base58 string suggests Tron. A bc1 prefix is Bitcoin. A 0x prefix is EVM-family.
2. Length. 42 characters with 0x is an EVM address. 66 characters with 0x is a 32-byte hex value - either a tx hash or a block hash on EVM.
3. Alphabet. Hex-only vs base58 vs base64 vs bech32 narrows the chain family.

For the ambiguous case of "0x-prefixed 64-character hex on an EVM chain", tx.taxi defaults to treating it as a transaction hash because that is the more common lookup. If you know you have a block hash, you can hint by appending /block/ in the path or by going directly to /chains/<chain-id> and using the chain page's pasted input.

A bare decimal number is treated as a block height candidate, with the chain inferred from context (the URL prefix, or a disambiguation step).

Block hash on UTXO chains

On Bitcoin, Litecoin, Dogecoin, Bitcoin Cash, and other UTXO chains, block hashes also follow a recognisable shape: 64 lowercase hex characters with no 0x prefix and a long run of leading zeros. The leading zeros are a side-effect of proof-of-work - the consensus rule requires the hash to be below a difficulty target, so valid blocks have hashes that start with many zero bits. A string like 00000000000000000003abcd... is almost certainly a Bitcoin block hash.

UTXO transaction hashes (txids) share the format but rarely have so many leading zeros, because they are not the target of mining work.

What to remember

• Block hash and tx hash are different lookups even when the bytes look similar.
• On EVM, both are 32 bytes of hex; the explorer endpoint distinguishes them.
• Block height is a friendlier alternative to block hash for everyday lookups.
• tx.taxi handles the routing decision so you can paste-and-go; the explorer itself handles the disambiguation when the format alone is not enough.

The format is just packaging. The right question is always: what am I trying to find - the envelope, or the letter inside it?