# How to read a block explorer: transactions, fees, confirmations and addresses

A block explorer presents an operator’s indexed view of blocks and transactions. For an ordinary Bitcoin transaction, inspect which previous outputs it spends, the new outputs it creates, the fee, and whether it is in the accepted chain. Confirmations equal the current tip height minus the transaction’s block height plus one. An unconfirmed transaction may be in that operator’s mempool, but can also be unknown or dropped. Addresses and transactions do not by themselves identify people.

Evidence: [Esplora HTTP API](https://raw.githubusercontent.com/Blockstream/esplora/bb2d9f37bdb0eb0dade45b121a1df3581d7443ea/API.md); [Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html); [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html)

Canonical: https://degreesofsatoshi.com/encyclopedia/how-to-read-a-block-explorer/
Published: 2026-09-23
Substantively modified: 2026-10-02
Independently verified by an automated reviewer: 2026-10-02T18:26:58.075Z

AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied.

## Key facts

- **What it shows:** Blocks, transactions and addresses, read from one node’s copy of the chain ([The Mempool Open Source Project (README)](https://github.com/mempool/mempool); [mempool.space FAQ (source template, api-docs.component.html)](https://raw.githubusercontent.com/mempool/mempool/4f478a57635fa97cdb1434736647bc651f35145c/frontend/src/app/docs/api-docs/api-docs.component.html))
- **Inputs and outputs:** For an ordinary transaction, inputs reference previous outputs; input value minus output value is the fee ([Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html))
- **Worked example: the pizza transaction:** 131 inputs, one output of 10,000 BTC, a fee of 0.99 BTC, confirmed in block 57,043 ([The pizza transaction, machine-readable record](https://blockstream.info/api/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d))
- **Confirmations:** For a transaction in the accepted chain: tip height − transaction block height + 1 ([Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html); [Bitcoin Developer Guide: Payment Processing](https://developer.bitcoin.org/devguide/payment_processing.html))
- **Unconfirmed:** Not included in the operator’s accepted chain; presence in a mempool is a separate observation ([Esplora HTTP API](https://raw.githubusercontent.com/Blockstream/esplora/bb2d9f37bdb0eb0dade45b121a1df3581d7443ea/API.md))
- **Worked example: the genesis block:** Height 0, one transaction, 285 bytes, timestamp 3 January 2009 18:15:05 UTC, no previous block ([The genesis block, machine-readable record](https://blockstream.info/api/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f))

## A block explorer is a window onto one node, not onto the network itself

A fully validating node checks the chain’s rules. Pruned nodes may discard old block files after validation; an explorer also needs historical data and indexes to offer its history pages. A block explorer is a website that sits on top of one of those nodes and turns its database into pages you can click through: one page per block, one per transaction, one per address. The mempool.space documentation defines it as “a tool that enables you to explore real-time and historical information about the blockchain,” and the project describes itself as “the fully-featured mempool visualizer, explorer, and API service.” Blockstream’s explorer offers a similar interface with a documented data feed.

Two things follow from that design. The explorer shows you one node’s view, which is an operator’s report, not independent proof of validity, and is especially local for pending transactions, because, as the same documentation says, “there is no one global mempool: every node on the network maintains its own.” And whoever runs the site can see what you look up, which is one reason the mempool project encourages people to run their own copy on hardware ranging “from a simple one-click installation on a Raspberry Pi” upward. For reading history, any reputable explorer will do; for your own transactions, the private option exists.

Evidence: [The Mempool Open Source Project (README)](https://github.com/mempool/mempool); [mempool.space FAQ (source template, api-docs.component.html)](https://raw.githubusercontent.com/mempool/mempool/4f478a57635fa97cdb1434736647bc651f35145c/frontend/src/app/docs/api-docs/api-docs.component.html); [Esplora HTTP API](https://raw.githubusercontent.com/Blockstream/esplora/bb2d9f37bdb0eb0dade45b121a1df3581d7443ea/API.md)

## Read a transaction in a reproducible order

First identify the network and transaction. Check whether it is pending or included, then record the block hash and height if present. For an ordinary non-coinbase transaction, inspect the previous outputs spent, new outputs created and fee calculated from their difference.

Next distinguish output values from wallet ownership: a change output may belong to the sender, and a recipient address is not automatically a person. Record the observation time and chain tip when citing a confirmation count. Explorer labels add interpretation that should be kept separate from the raw transaction fields.

Evidence: [Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html); [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html); [Bitcoin Core mempool maintenance](https://raw.githubusercontent.com/bitcoin/bitcoin/v29.0/src/txmempool.cpp)

## Fees, mempools, and the limits of an unconfirmed payment

A transaction is unconfirmed relative to an observed chain if it has not been included there. It may be accepted in a node’s mempool, dropped under local policy, or unknown to that operator. Check the transaction response and its observation time rather than assuming every signed or broadcast transaction is still waiting in every node.

The mempool view on the front page of mempool.space shows the queue sorted by fee rate, measured in satoshis per virtual byte, and projects which transactions will fit in the next blocks. “Since space in the Bitcoin blockchain is limited, bigger transactions pay more in mining fees than smaller transactions,” and a higher rate generally means quicker confirmation. If yours is stuck, the docs say, “there’s no need to panic”: it will either confirm or not, and a wallet that supports replace-by-fee can resubmit it at a higher rate. Our guide to [fees and the mempool](/encyclopedia/bitcoin-transaction-fees-and-mempool/) goes into the auction in detail.

The developer guide’s warning is worth quoting whole: “Zero confirmation transactions (unconfirmed transactions) should generally not be trusted without risk analysis.” An unconfirmed payment can be replaced by a conflicting one, and the recipient “will see the incoming transaction notification disappear or turn into an error message.” Unconfirmed means not yet included in the explorer’s accepted chain; a signed transaction may already have been created and relayed.

Evidence: [mempool.space FAQ (source template, api-docs.component.html)](https://raw.githubusercontent.com/mempool/mempool/4f478a57635fa97cdb1434736647bc651f35145c/frontend/src/app/docs/api-docs/api-docs.component.html); [Esplora HTTP API](https://raw.githubusercontent.com/Blockstream/esplora/bb2d9f37bdb0eb0dade45b121a1df3581d7443ea/API.md); [Bitcoin Developer Guide: Payment Processing](https://developer.bitcoin.org/devguide/payment_processing.html); [Bitcoin Core mempool maintenance](https://raw.githubusercontent.com/bitcoin/bitcoin/v29.0/src/txmempool.cpp)

## Confirmations and block height: how deep is deep enough

Every block carries the hash of the previous block’s header, which chains them together and means, as the developer guide says, that “a transaction cannot be modified without modifying the block that records it and all following blocks.” Blocks are numbered by height, “the number of blocks between them and the first Bitcoin block.” For a transaction still in the accepted chain, confirmations equal tip height minus its block height plus one. A transaction in the tip has one confirmation, not zero. Reorganizations can change that count.

How many is enough depends on what is at stake. The developer guide says software handling high-value payments “should wait for at least six confirmations before treating a payment as accepted,” and that fewer may suit lower-risk cases. Six is a convention, not a law of nature, and explorers will happily show you a count in the hundreds of thousands for anything old.

The genesis block is the other example worth looking up. Its explorer record shows height 0, a timestamp of 3 January 2009 at 18:15:05 UTC, a size of 285 bytes, exactly one transaction, and no previous block hash at all, because there was nothing before it. Every confirmation count on the network is, in the end, a distance from that block. The [genesis block wallet page](/wallet/genesis-block-coinbase-block-0/) tells the rest of its story.

Evidence: [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html); [Bitcoin Developer Guide: Payment Processing](https://developer.bitcoin.org/devguide/payment_processing.html); [The genesis block, machine-readable record](https://blockstream.info/api/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f)

## Reading an address page without over-reading it: an address is not a person

An address page lists every transaction that has paid to or spent from that address, plus totals. In the Esplora data feed those are the sum of funded outputs and the sum of spent outputs, and the balance is one minus the other, with a separate pair of tallies for anything still in the mempool. That much is fact. Everything beyond it is inference, and the inference most people make first, that an address is a person, is the one most likely to be wrong.

The developer guide advises against reusing addresses, since reuse lets observers “easily track the receiving and spending habits of that person,” and it recommends a fresh address for each payment. Well-behaved wallets do exactly that, so one person is normally many addresses, and a single address’s balance says little about anyone’s wealth. The reverse also holds: a service that holds coins for many customers can pool them under one address, so one address can be thousands of people. Our [address graph research](/research/bitcoin-address-graph/) explains how analysts cluster addresses and how uncertain those clusters are, and the article on [whether Bitcoin is anonymous](/encyclopedia/is-bitcoin-anonymous/) explains what the chain does and does not reveal.

The habit to build is to read an address page as a record of coins, not of motives. A large incoming transaction is a large incoming transaction; whether it is a purchase, a transfer between one owner’s own wallets or an exchange moving its reserves is not on the page.

Evidence: [Esplora HTTP API](https://raw.githubusercontent.com/Blockstream/esplora/bb2d9f37bdb0eb0dade45b121a1df3581d7443ea/API.md); [Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html)

## Questions

### What does “unconfirmed” mean on a block explorer?

It has not been included in the explorer’s accepted chain. It may be in that node’s mempool, may have been evicted, or may be unknown to the operator. An unconfirmed payment can conflict with another transaction and is not a finalized transfer.

Evidence: [Esplora HTTP API](https://raw.githubusercontent.com/Blockstream/esplora/bb2d9f37bdb0eb0dade45b121a1df3581d7443ea/API.md); [Bitcoin Developer Guide: Payment Processing](https://developer.bitcoin.org/devguide/payment_processing.html)

### How many confirmations should I wait for?

Risk depends on amount, counterparties and threat assumptions. Six confirmations is a traditional convention discussed in the developer guide, not a guarantee. Inclusion gives the first confirmation; each later block adds another while the transaction remains in the accepted chain.

Evidence: [Bitcoin Developer Guide: Payment Processing](https://developer.bitcoin.org/devguide/payment_processing.html); [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html)

### Can I see who owns a Bitcoin address on a block explorer?

No. An address page shows coins received and spent, not names. Wallets are advised to use a new address for every payment, so one person is usually many addresses, and a service can pool many customers’ coins under one address. Any link from an address to a person comes from outside the chain.

Evidence: [Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html); [Esplora HTTP API](https://raw.githubusercontent.com/Blockstream/esplora/bb2d9f37bdb0eb0dade45b121a1df3581d7443ea/API.md)

### Why is the fee different from the amount sent?

Inputs are spent in full, so a transaction pays the recipient, returns the surplus to the sender as change, and leaves whatever remains to the miner as the fee. Fee rates are usually compared by virtual size and block-space demand, not as a percentage of the amount moved. The 2010 pizza transaction, for example, gathered 131 inputs into one 10,000 BTC output and paid a fee of 0.99 BTC.

Evidence: [Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html); [The pizza transaction, machine-readable record](https://blockstream.info/api/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d)

## Claims and scope

### how-to-read-a-block-explorer-quick-answer

A block explorer presents an operator’s indexed view of blocks and transactions. For an ordinary Bitcoin transaction, inspect which previous outputs it spends, the new outputs it creates, the fee, and whether it is in the accepted chain. Confirmations equal the current tip height minus the transaction’s block height plus one. An unconfirmed transaction may be in that operator’s mempool, but can also be unknown or dropped. Addresses and transactions do not by themselves identify people.

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### how-to-read-a-block-explorer-fact-what-it-shows

What it shows: Blocks, transactions and addresses, read from one node’s copy of the chain

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### how-to-read-a-block-explorer-fact-inputs-and-outputs

Inputs and outputs: For an ordinary transaction, inputs reference previous outputs; input value minus output value is the fee

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### how-to-read-a-block-explorer-fact-worked-example-the-pizza-transaction

Worked example: the pizza transaction: 131 inputs, one output of 10,000 BTC, a fee of 0.99 BTC, confirmed in block 57,043

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### how-to-read-a-block-explorer-fact-confirmations

Confirmations: For a transaction in the accepted chain: tip height − transaction block height + 1

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### how-to-read-a-block-explorer-fact-unconfirmed

Unconfirmed: Not included in the operator’s accepted chain; presence in a mempool is a separate observation

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### how-to-read-a-block-explorer-fact-worked-example-the-genesis-block

Worked example: the genesis block: Height 0, one transaction, 285 bytes, timestamp 3 January 2009 18:15:05 UTC, no previous block

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

## Sources

- [The Mempool Open Source Project (README)](https://github.com/mempool/mempool) — mempool/mempool on GitHub. Describes mempool.space as a mempool visualizer, explorer and API service, and encourages self-hosting on hardware from a Raspberry Pi upward. Locator: Describes mempool.space as a mempool visualizer, explorer and API service, and encourages self-hosting on hardware from a Raspberry Pi upward.. Retrieved: 2026-10-02T14:50:00.894168+00:00.
- [mempool.space FAQ (source template, api-docs.component.html)](https://raw.githubusercontent.com/mempool/mempool/4f478a57635fa97cdb1434736647bc651f35145c/frontend/src/app/docs/api-docs/api-docs.component.html) — mempool/mempool on GitHub. The source text of the FAQ shown at mempool.space/docs/faq: definitions of a mempool and a block explorer, the note that every node keeps its own mempool, fee rates in sat/vB, larger transactions paying more, and the advice that a stuck transaction will either confirm or not. Locator: The source text of the FAQ shown at mempool.space/docs/faq: definitions of a mempool and a block explorer, the note that every node keeps its own mempool, fee rates in sat/vB, larger transactions paying more, and the advice that a stuck transaction will either confirm or not.. Retrieved: 2026-10-02T15:04:15.275517+00:00.
- [Esplora HTTP API](https://raw.githubusercontent.com/Blockstream/esplora/bb2d9f37bdb0eb0dade45b121a1df3581d7443ea/API.md) — Blockstream/esplora on GitHub. Documents the transaction status object (confirmed, block_height null when unconfirmed, block_time), and the address statistics for confirmed and mempool activity, including funded and spent output sums. Locator: Documents the transaction status object (confirmed, block_height null when unconfirmed, block_time), and the address statistics for confirmed and mempool activity, including funded and spent output sums.. Retrieved: 2026-10-02T15:04:15.285075+00:00.
- [The pizza transaction, machine-readable record](https://blockstream.info/api/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d) — Blockstream explorer API (blockstream.info). The explorer’s data for the 10,000 BTC transaction: 131 inputs, one output of 1,000,000,000,000 satoshis, a fee of 99,000,000 satoshis, size 23,620 bytes, confirmed in block 57,043 with block time 1274552191 (22 May 2010 UTC). Locator: The explorer’s data for the 10,000 BTC transaction: 131 inputs, one output of 1,000,000,000,000 satoshis, a fee of 99,000,000 satoshis, size 23,620 bytes, confirmed in block 57,043 with block time 1274552191 (22 May 2010 UTC).. Retrieved: 2026-10-02T14:50:04.608040+00:00.
- [The genesis block, machine-readable record](https://blockstream.info/api/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f) — Blockstream explorer API (blockstream.info). The explorer’s data for block 0: timestamp 1231006505 (3 January 2009 18:15:05 UTC), one transaction, size 285 bytes, weight 1,140, difficulty 1 and a null previous block hash. Locator: The explorer’s data for block 0: timestamp 1231006505 (3 January 2009 18:15:05 UTC), one transaction, size 285 bytes, weight 1,140, difficulty 1 and a null previous block hash.. Retrieved: 2026-10-02T14:48:47.657357+00:00.
- [Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html) — developer.bitcoin.org. Explains inputs spending previous outputs, unspent transaction outputs, change outputs, the fee as the remainder, transaction identifiers, and the advice against address reuse. Locator: Explains inputs spending previous outputs, unspent transaction outputs, change outputs, the fee as the remainder, transaction identifiers, and the advice against address reuse.. Retrieved: 2026-10-02T14:48:40.568452+00:00.
- [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) — developer.bitcoin.org. Explains how blocks chain by the previous header hash, defines block height as the number of blocks from the first block, and describes forks and stale blocks. Locator: Explains how blocks chain by the previous header hash, defines block height as the number of blocks from the first block, and describes forks and stale blocks.. Retrieved: 2026-10-02T14:48:36.834850+00:00.
- [Bitcoin Developer Guide: Payment Processing](https://developer.bitcoin.org/devguide/payment_processing.html) — developer.bitcoin.org. Recommends at least six confirmations for high-value payments, warns that zero-confirmation transactions should not be trusted without risk analysis, and describes what a recipient sees when an unconfirmed payment is replaced. Locator: Recommends at least six confirmations for high-value payments, warns that zero-confirmation transactions should not be trusted without risk analysis, and describes what a recipient sees when an unconfirmed payment is replaced.. Retrieved: 2026-10-02T14:48:41.373881+00:00.
- [Bitcoin Core mempool maintenance](https://raw.githubusercontent.com/bitcoin/bitcoin/v29.0/src/txmempool.cpp) — Bitcoin Core. Node-local expiry and size-based eviction of unconfirmed transactions. Locator: CTxMemPool::Expire; CTxMemPool::TrimToSize. Retrieved: 2026-10-02T17:55:16.998Z.

## Revision history

- 2026-09-23: Initial Bitcoin encyclopedia entry at this permanent URL.
- 2026-10-02: Revised direct answer to preserve source scope and qualifications. Corrected key fact: Inputs and outputs Corrected key fact: Confirmations Corrected key fact: Unconfirmed Corrected scope or wording: Every full node, meaning every computer that downloads and checks the whole Bitcoin c Corrected scope or wording: which is authoritative for anything already in a block but only a snapshot for anythi Corrected scope or wording: amounts, each locked to an address. Corrected scope or wording: because fees are paid per byte of data, not per bitcoin moved. Corrected scope or wording: A transaction’s confirmation count is simply the distance from the block that holds i Corrected scope or wording: Unconfirmed means not yet happened. Corrected scope or wording: Fees, the mempool, and why “unconfirmed” means not yet happened Corrected FAQ: What does “unconfirmed” mean on a block explorer? Corrected FAQ: How many confirmations should I wait for? Corrected scope or wording: Fees depend on the transaction’s size in bytes, not the amount moved.
- 2026-10-02: Added reusable claims, explicit source locators, and matching Markdown and JSON. This publishing change does not itself establish factual verification.
- 2026-10-02: Expanded explanation: Read a transaction in a reproducible order. Worked examples are illustrative; source checks and independent verification are recorded separately.

## Cite this entry

Degrees of Satoshi editorial project. “How to read a block explorer: transactions, fees, confirmations and addresses.” Published 2026-09-23; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/how-to-read-a-block-explorer/