How to Use a Bitcoin Block Explorer (Transaction Lookup Guide)

A Bitcoin block explorer is a web tool that lets you search the Bitcoin blockchain by transaction ID (TXID), address, or block and read back a verified on-chain record: confirmation status, inputs and outputs, miner fee in sat/vB, and the block that includes the transaction. It is a read-only window into the same public ledger every Bitcoin node maintains, and it settles most "did my payment go through?" questions in under a minute when you know which field to look at.

This guide is a step-by-step workflow for using any major Bitcoin block explorer (mempool.space, Blockchain.com, Blockstream.info, Blockchair, BTCscan) to verify a transfer, interpret confirmations, read fees, troubleshoot a stuck transaction, and spot the privacy traps and fake-explorer scams that catch casual users. It is not a tool for reversing transactions, proving address ownership, or tracking Lightning Network payments: those require different infrastructure.

What this guide covers:

• What a block explorer can and cannot prove

• Choosing between TXID, address, and block as your search input

• A step-by-step TXID lookup with the three fields to check first

• Reading confirmations, fees, and the UTXO (input/output) structure

• RBF, CPFP, and "replaceable" labels: what the explorer is telling you

• Address pages, balances, and the privacy footguns

• Fake explorers, phishing links, and what never to paste into a search bar

What is a Bitcoin block explorer and what can it actually prove?

A Bitcoin block explorer is a website that connects to one or more full Bitcoin nodes, indexes the data those nodes maintain, and presents it in a readable form. It shows you the same ledger every node on the network independently validates, so the underlying facts about a transaction are identical across explorers even when the labels and calculations differ at the margin.

What a block explorer can verify:

• Whether a specific TXID exists on the Bitcoin network

• Whether that transaction is unconfirmed (in the mempool) or confirmed in a block

• The number of confirmations since the including block

• The exact amounts in each input and output

• The timestamp when the transaction was first seen and when it was included

• The block height and block hash containing the transaction

• The total fee in satoshis and the effective fee rate in sat/vB

What a block explorer cannot verify:

• Who controls an address (addresses are pseudonymous, not anonymous)

• Whether a payment was intentional, a gift, a mistake, or the product of compromised keys

• Whether the recipient address actually belongs to the person you intended to pay

• Any Lightning Network payment (Lightning is an off-chain system; only the open/close channel transactions settle on-chain)

• Activity on other blockchains (Bitcoin Cash, Ethereum, Litecoin have their own explorers)

• Any way to reverse, cancel, or modify a confirmed transaction

Why different explorers can show slightly different numbers:

Explorers compute derived fields (effective fee rate, first-seen time, estimated confirmation time) using their own algorithms. One might show "fee rate" as a simple fee/size division; another shows "effective fee rate" that accounts for CPFP parent-child bumps. The underlying consensus data (confirmations, amounts, block inclusion) is identical because all explorers ultimately read from the same blockchain. If two explorers disagree on a consensus-level field, treat it as an indexing lag, not a discrepancy in the ledger, and refresh after a few minutes.

For the full structure of what a transaction contains, see our guide on how a Bitcoin transaction works.

TXID vs address vs block: Which identifier should you search?

The most common block explorer mistake is searching the wrong identifier. Each of the three inputs answers a different question, and picking the wrong one either returns nothing or buries your answer in noise.

When to search by TXID

A TXID, also called a transaction hash, is the 64-character hexadecimal identifier for a single broadcast transaction. Every bitcoin transaction has exactly one TXID, and that TXID is the most precise input you can give an explorer. Use it when you have a concrete payment to verify, a wallet or exchange gave you a transaction reference, or you are sharing proof of payment with a counterparty. Example: f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 (the TXID of Satoshi Nakamoto's first Bitcoin transfer to Hal Finney, still visible on any explorer today).

When to search by address

A Bitcoin address aggregates every transaction that has ever sent coins to or spent coins from it. Search by address when you need the full history for a specific receiving identifier, are verifying whether funds have arrived across multiple payments, or need the current unspent balance. Modern wallets generate a fresh address for each receive request, so one address typically represents a single payment context, not an entire wallet. Searching one address does not show you all of "your" bitcoin if your wallet controls multiple addresses.

When to search by block

Block height is the sequential position of a block in the chain (the Bitcoin genesis block is height 0, and at the time of writing in May 2026 the chain is past height 948,274) (source: bitbo.io). Block hash is the cryptographic identifier for one specific block, a 64-character hex string. Both lead to the same block page. Search by block when you want to see every transaction included in a specific block, verify the block reward and miner, or look up a block by the exact moment it was mined. Confirming your TXID appears in a specific block is a second-order check on a successful confirmation.

Copy/paste hygiene

• Always copy the full identifier using your wallet's or exchange's copy button, never hand-type

• Verify no leading or trailing spaces snuck in from the clipboard

• Confirm you are on a Bitcoin mainnet explorer, not a Bitcoin testnet, Bitcoin Cash, or Litecoin explorer; prefixes and TXID formats look similar but the ledgers are unrelated

• If a TXID returns "not found," wait 1-2 minutes and refresh: transactions take a few seconds to propagate to every indexer after broadcast

For a full walkthrough of address formats and how each one is derived, see our guide on Bitcoin public key vs. private key.

How do you look up a Bitcoin transaction by TXID, step by step?

This is the workflow that covers most "did my payment arrive?" situations. Pick a reputable explorer, paste your TXID, and check three specific fields in order.

Step 1: Get the TXID from the source that created it

For a self-custody wallet send, the TXID appears on the send confirmation screen and in the wallet's transaction history. For an exchange withdrawal, the TXID appears in the withdrawal history once the exchange has actually broadcast the transaction to the network (before that, the withdrawal is in internal processing and no on-chain TXID exists yet). For a payment you are receiving, ask the sender to share their TXID; it is safe for them to share.

Step 2: Open a reputable block explorer

Recommended options:

• mempool.space (also exposes detailed mempool data at https://mempool.space)

• Blockstream Explorer

• Blockchair

• Blockchain

• BTCscan

Type the explorer's URL directly into your browser rather than clicking search-result links. Fake block explorers exist; see the scam patterns section below.

Step 3: Paste the TXID into the search bar

The search bar is typically the most prominent element on the homepage. Paste the full 64-character hex string exactly as copied. The explorer auto-detects whether the input is a TXID, address, or block hash based on length and format.

Step 4: Press Enter and wait for the transaction page to load

If the TXID is valid and has been broadcast, a transaction detail page loads within seconds. If you get "transaction not found," either the transaction has not yet propagated to the explorer's node (wait and refresh), the TXID was copied incorrectly, or the transaction was never broadcast.

Step 5: Check three fields in order.

On the transaction detail page, read these three fields first before anything else:

1. Status: Look for "Confirmed" (with a block height) or "Unconfirmed / In mempool." A confirmed transaction is included in at least one block.

2. Confirmations: A number showing how many blocks have been added on top of the including block. Zero means unconfirmed. One means just confirmed. Six or more is the conventional threshold for high-value irreversibility.

3. Output amount and address: Scroll to the "Outputs" section and verify the expected amount appears at the expected destination address. Most transactions have two outputs: one payment and one change output back to the sender. Do not assume the first output is always yours.

Quick verification checklist:

1. TXID in the explorer matches the TXID you were given (first four and last four characters minimum)

2. Status shows "Confirmed" with a block height, or "Unconfirmed" if still pending

3. Confirmation count meets the threshold your context requires (personal transfer, exchange deposit, merchant payment)

4. Output amount matches the expected payment amount

5. Output address matches the expected destination

If all five check out, the transfer is accounted for on-chain. Screenshot the explorer page as proof.

If the TXID returns "not found":

• Wait 2 minutes and refresh; propagation delay is normal

• Confirm you pasted the full string without truncation or trailing whitespace

• Verify you are on a Bitcoin mainnet explorer (not testnet, not Bitcoin Cash, not Litecoin)

• If the TXID still does not resolve after 10 minutes, the transaction may not have been broadcast successfully; check your wallet or exchange for a "rebroadcast" option

For the deposit-side version of this workflow, see our guide on how to send bitcoins.

What do confirmations actually mean, and how many are enough?

A confirmation is one block added to the Bitcoin blockchain on top of the block containing your transaction. The first confirmation is the inclusion itself; the second is the next block mined on top of that one, and so on. Each additional confirmation increases the computational cost an attacker would have to pay to reorganize the chain and roll back your transaction.

How confirmations accumulate

Bitcoin blocks are mined approximately every 10 minutes on average, per the protocol's difficulty targeting. That average is a long-run mean; individual block times vary from a few seconds to over an hour due to the Poisson nature of mining. Six confirmations typically take 45 to 75 minutes in practice, not exactly 60.

The six-confirmation convention comes from an early assumption that no attacker controls more than ~10% of hashrate and that a residual risk under 0.1% is acceptable. For very large transactions, the Bitcoin Wiki notes that 60 confirmations is needed to stay under 1% probability of failure against a 40% hashrate attacker, and 144 confirmations (one day) is recommended for sales comparable in value to a full block reward.

Why transactions stay unconfirmed

Miners select transactions from the mempool by effective fee rate (sat/vB), not by fee total or arrival time. During congested periods, transactions paying below the current mempool clearing rate can wait hours or, in the extreme, drop out after the default 336-hour (two-week) expiry. During the May 2026 low-congestion period on mempool.space, with the no priority tier at 0.2 sat/vB. 

Mempool vs confirmed

The mempool is the staging area where broadcast transactions wait for miner inclusion. Every full node maintains its own mempool; they are similar but not identical across the network. Your transaction is in "the mempool" from broadcast until a miner includes it in a block. After inclusion, the transaction's status flips to “confirmed” and the mempool entry is cleared. Block explorers display both states; the transaction page shows a "pending" or "unconfirmed" banner when it is still in the mempool.

Confirmation count is context-dependent, not a universal rule

A $5 coffee may be fine at 0-conf. A $500 merchant payment is typically fine at 1-3 confirmations. A $50,000 transfer between cold-storage wallets is typically held for 6+ confirmations. There is no protocol rule that defines finality; finality is a probabilistic property of confirmation depth.

For the detailed confirmation math and a full explanation of reorganizations and block reorg risk, see our guide on Bitcoin confirmations and how many Bitcoin confirmations you need.

How do you read fees on a block explorer (and why total fee and fee rate differ)?

Every Bitcoin transaction pays a fee to miners. Explorers show two fee-related numbers, and confusing them is one of the most common diagnostic errors when troubleshooting stuck transactions.

The two fee numbers:

• Total fee (satoshis or BTC): The absolute amount paid to the miner. It equals the sum of input values minus the sum of output values. One satoshi is 0.00000001 BTC.

• Fee rate (sat/vB): The fee divided by the transaction size in virtual bytes. This is what miners use to prioritize transactions.

Why fee rate matters more than total fee

Miners pack blocks to maximize revenue per byte of block space. A simple 1-input, 2-output native SegWit transaction is typically 140-200 vB. A consolidation transaction with many inputs can be 500-1,000+ vB. At the same sat/vB, a bigger transaction costs more in absolute satoshis, but miners prioritize both at the same rate, because the revenue per byte is identical.

Worked example:

• Transaction A: 150 vB × 50 sat/vB = 7,500 sat total fee

• Transaction B: 500 vB × 50 sat/vB = 25,000 sat total fee

Both transactions have equal miner priority despite the 3.3× difference in total fee. The bigger transaction is not "overpaying"; it simply occupies more block space.

Why explorer fees may differ from wallet estimates

Explorers show historical data: the fee of a transaction that is already on-chain or in the mempool. Wallets show predicted fees based on current mempool depth to hit a target confirmation window. The two numbers serve different purposes and routinely differ by several sat/vB during congestion.

Effective fee rate

Some explorers display "effective fee rate" alongside the simple fee rate. The effective rate accounts for CPFP bumps (child transactions paying extra fee to pull an unconfirmed parent into a block). A stalled parent transaction shown with a low simple fee rate may have a much higher effective fee rate if a child has already bumped it.

Live network fee data (May 2026)

Checking mempool.space's fee recommendation endpoint (source: Mempool.space) on May 7, 2026 returned 0.2 sat/vB at the no priority tier, up to 1 sat/vB for the high priority tier. This is a low-congestion baseline; during the 2021 and 2024 congestion peaks, fastest-tier rates exceeded 50 sat/vB and approached the block-space ceiling for hours at a time.

For the dynamics of why fees spike and how to choose one without overpaying, see why are Bitcoin fees so high and how to choose Bitcoin fees.

How do inputs, outputs, and UTXOs appear on a block explorer?

Bitcoin accounts are not balances in a ledger; they are unspent transaction outputs (UTXOs) attached to specific addresses. A block explorer exposes this structure directly, and reading it correctly is the difference between interpreting a transaction as "strange" and recognizing a normal send.

The core concept

A UTXO is a discrete amount of bitcoin assigned to an address that has not yet been spent. Your wallet balance is the sum of all UTXOs its keys can spend. UTXOs are like bills in a physical wallet: you cannot tear a 0.5 BTC UTXO in half to pay 0.1 BTC; you spend the whole UTXO and receive change back.

Inputs and outputs

• Inputs are previous UTXOs being consumed. When you send bitcoin, your wallet selects one or more existing UTXOs as inputs. Each input references the earlier transaction that created it.

• Outputs create new UTXOs. Each output assigns a specific amount to a destination address. After the transaction confirms, those outputs are the new spendable UTXOs.

The change output

If you hold a single 1 BTC UTXO and want to send 0.3 BTC, the transaction consumes the entire 1 BTC input and creates three logical outcomes:

• 0.3 BTC to the recipient

• ~0.699 BTC back to an address your wallet controls (change)

• The remaining ~0.001 BTC is the miner fee (not shown as an output; it is the input-output differential)

The change output is your own money returning to you. It is not a second payment, a fee, or an error.

Transaction flow

INPUTS                           OUTPUTS
[0.5 BTC from Address A]   →     [0.3 BTC to Address B (payment)]
                          →     [0.199 BTC to Address C (change)]
                          →     [0.001 BTC to miners (fee)]

Common patterns an explorer will show

• Simple payment (1 input, 2 outputs): One UTXO consumed, one payment output, one change output. The most common send pattern from a modern wallet.

• Consolidation (many inputs, 1 output): A wallet combining many small UTXOs into one larger output to reduce fragmentation, usually performed during low-fee periods.

• Batch send (1 input, many outputs): One large UTXO split among multiple recipients in a single transaction. Exchanges use this pattern for periodic withdrawal batches.

• Coinbase (no inputs, several outputs): The first transaction in every block, creating the new bitcoin issuance and distributing block rewards and collected fees to the miner.

Why you see multiple input addresses

Wallets accumulate UTXOs from different past transactions. When the payment amount exceeds any single UTXO, the wallet selects multiple UTXOs as inputs. The presence of many input addresses does not mean many senders; it means one wallet consolidating its own UTXO set to fund a single transfer.

Privacy caution on input grouping

When a single transaction spends multiple inputs, chain analysts commonly treat those inputs as controlled by the same wallet (the "common-input-ownership heuristic"). This is a heuristic, not a proof; CoinJoin and PayJoin transactions intentionally break it. Still, you can usually infer that a multi-input transaction comes from one wallet.

For a dedicated guide to UTXO mechanics, see Bitcoin UTXO explained.

What do "Replaceable," "RBF," and "CPFP" labels on an explorer tell you?

When a transaction is unconfirmed, explorers add labels that describe how the transaction can be accelerated or replaced. These labels change what you can do, and they are not always shown in the same place across explorers.

RBF (Replace-By-Fee, BIP-125)

RBF lets the original sender create a new version of an unconfirmed transaction that pays a higher fee and replaces the original in miners' mempools. BIP-125 requires the replacement to pay a strictly higher absolute fee than the original.

• Who uses it: The original sender. RBF is opt-in at broadcast time and requires wallet support.

• Explorer label: "Replaceable," "RBF," or a flag icon next to the transaction status. After a replacement is broadcast, the original is marked "replaced" and the new TXID becomes the active transaction.

• Where you find it: On mempool.space, replaceable transactions are tagged with an RBF icon; on Blockchair, a "Replaceable" field appears under the TXID summary.

CPFP (Child-Pays-For-Parent)

CPFP is for when you cannot use RBF, typically because the original sender did not opt in, or because you are the recipient rather than the sender. The recipient spends the unconfirmed output in a new child transaction that pays a high fee. Miners evaluating the parent-child pair see the combined fee-per-byte and confirm both to collect it.

• Who uses it: Anyone controlling one of the unconfirmed outputs, often the recipient.

• Explorer label: Two linked transactions, with the child showing an elevated effective fee rate and the parent shown as accelerated by it.

• Where you find it: Click into the child transaction; most explorers show a note linking to the parent and display an "effective fee rate" higher than the parent's simple fee rate.

What neither mechanism does

Neither RBF nor CPFP cancels a transaction. RBF replaces an unconfirmed transaction with a new one paying a higher fee (typically to the same recipient). CPFP pulls the parent through the mempool faster but still confirms the original transfer. Once a transaction is confirmed, it cannot be reversed or replaced by any protocol mechanism.

When you see "replaced"

If your original TXID now shows "replaced" or 404s on some explorers, the sender broadcasts an RBF replacement. Ask the sender for the new TXID. The recipient always gets the final confirmed transfer either way; the fee bump just reassigns which version confirms.

For a full worked comparison of RBF and CPFP with diagnostic flowcharts, see our guide on RBF vs CPFP. For what to do if your transaction sits unconfirmed for hours, see why is my Bitcoin transaction stuck.

What does a block page tell you, and when should you look at one?

Every transaction lives in exactly one block. The block page shows the container: its height, hash, timestamp, miner, size, fee totals, and the full list of transactions it includes.

Block height vs block hash

• Block height is the sequential number of the block, starting at 0 for the Bitcoin genesis block mined by Satoshi Nakamoto on January 3, 2009. Block 948,274 is the 948,274th block added to the chain.

• Block hash is the 64-character cryptographic hash of the block's header. Any change to the block's contents changes the hash completely (that is the cryptographic commitment at the heart of proof-of-work).

Both inputs lead to the same block page in any explorer.

What a block page shows

• Block height and block hash

• Timestamp (approximate; miners can set it within a consensus-permitted range)

• Size in bytes and weight in virtual bytes

• Transaction count and total fees collected

• Coinbase transaction (the one creating the block subsidy and collecting fees)

• Full list of included transactions with TXIDs

• Pool identification (which mining pool mined this block, inferred from coinbase outputs)

• Previous and next block hashes (chain pointers)

What "miner" means on an explorer

Miner identification is heuristic. Explorers match the coinbase output addresses against a known list of mining pool addresses and coinbase signatures. Major pools (F2Pool, Antpool, Foundry USA, ViaBTC) are typically identified correctly. A solo miner or a new pool may appear as "Unknown."

Timestamp caveat

Bitcoin consensus allows miners to set block timestamps within a window: not more than 2 hours ahead of the median time of the last 11 blocks, and not before that median time. Timestamps on an explorer are the miner-declared values, not the wall-clock moment of inclusion. Small discrepancies of minutes are normal; larger anomalies are occasionally visible.

When to use block-page data

• Confirming your TXID appears in the block you expect

• Checking network activity or fee density at a specific point in time

• Inspecting the coinbase transaction for a block (miner identification, block reward composition after halvings)

• Cross-referencing timestamps to resolve "when did this confirm?" questions

For a deeper guide to how blocks, headers, and chain linkage fit together, see our guide on the Bitcoin blockchain.

How do you read an address page, and what privacy traps hide there?

Address pages are the richest source of information on a block explorer and also the one most likely to mislead casual users. An address page shows every transaction ever touching that address, the current balance, and the UTXOs available to spend.

What the address page shows

• Total received: cumulative amount ever sent to this address

• Total sent: cumulative amount ever spent from this address

• Current balance: total received minus total sent, which also equals the sum of current UTXOs at the address

• Full transaction history, chronologically

• Current UTXO set (some explorers show this as a separate tab)

Why "address balance" ≠ "wallet balance"

Modern Bitcoin wallets derive dozens to thousands of addresses from a single master key per BIP-32 and BIP-84. Each receive request typically produces a fresh address. An address page shows the balance at one address, not the balance of the wallet it came from. If your wallet displays 1.5 BTC but a specific receiving address shows 0.1 BTC, the remaining 1.4 BTC is distributed across other addresses the same wallet can sign for.

The pseudonymity illusion

Bitcoin addresses are pseudonymous, not anonymous. On its own, an address is a random-looking hash. The moment an address is linked to your identity (because you posted it publicly, tied it to a KYC exchange account, or used it for a payment with a known party), every past and future transaction at that address becomes traceable to you by anyone willing to read the blockchain. This is the fundamental privacy property of the Bitcoin ledger: public by design.

Address reuse is a privacy leak

Receiving multiple payments to the same address links all of them publicly. Chain analysts treat the address as one wallet context and build graphs of everyone you transact with. Modern wallets default to generating a fresh address per receive to break this link. Address reuse does not break any security guarantee; it breaks privacy.

For a detailed treatment of chain privacy and the common-input heuristic, see our guide on Bitcoin privacy.

What you must never paste into a block explorer or any third-party site

• Your seed phrase or recovery words

• Your private keys (WIF format, hex format, or any other)

• Your extended public keys (xpub, ypub, zpub) or extended private keys (xprv, yprv, zprv)

• Wallet export files, wallet.dat files, or any backup containing key material

A TXID or a single address is safe to paste. Anything that reveals key derivation material is not, because a hostile explorer can archive it and derive every future address you will ever generate.

Sharing proof of payment safely

Share TXIDs, not addresses, to prove a specific transfer. A TXID reveals only that one transaction; a public address links every other transaction at that address. The recipient can look up the TXID on any explorer of their choice and verify it independently.

How do you avoid fake block explorers and phishing traps?

Fake block explorers and phishing-branded explorer sites exist. They look identical to legitimate ones and typically have two goals: harvesting what you paste into them (xpubs, seed words) or routing you into a downstream scam (fake support, "recovery services," fraudulent wallet downloads).

Patterns to watch:

• Typosquat domains: blockch4in.com, mempo0l.space, blockstreem.info. Always type the URL directly or use a browser bookmark.

• Search-result poisoning: Search ads and poisoned SEO for common explorer queries can route you to lookalike sites. Treat the top sponsored result with skepticism.

• Fake "recovery" overlays: Some phishing explorers add a popup or sidebar offering transaction recovery, chargeback, or "unfreeze" services. No such service exists for confirmed Bitcoin transactions; every one of them is a scam.

• Unsolicited explorer links: A stranger on Telegram, Discord, or X sending you "check this transaction at [link]" is frequently routing you to a malicious site. Open your own explorer and paste the TXID yourself.

• Explorer-branded wallet downloads: No mainstream explorer distributes a wallet. If an "explorer" site offers a wallet app, it is a scam.

Safe habits:

• Bookmark one or two explorers you trust and use those by default

• Verify the URL in the address bar before pasting anything

• Never paste seed words, private keys, or xpubs into any website, including explorers

• Treat any "recovery" offer as a scam; no one can reverse a confirmed Bitcoin transaction

• If you suspect you pasted sensitive data into a fake explorer, move your funds to a new wallet generated from a fresh seed immediately

For a broader survey of Bitcoin-specific scam patterns, see common Bitcoin scams.

What should you do if the explorer shows your deposit hasn't arrived?

The explorer is usually right; the problem is usually upstream.

Step-by-step diagnostic

1. Confirm the TXID exists on-chain. Paste it into mempool.space. If it resolves, the transaction was broadcast and is either confirmed or in the mempool.

2. Check confirmations. If confirmations are below the receiving party's threshold (most exchanges require 2-6), wait. Exchange crediting happens only after the required depth.

3. Check the receiving address. Verify the output address shown on-chain matches the address the exchange or recipient told you to send to, character-for-character. Clipboard hijacking substitutes an attacker-controlled address that can start with the same four characters as yours.

4. Check the network. If the transaction shows up on a Bitcoin explorer, you are on Bitcoin. If it does not but shows up on a BNB Chain or Ethereum explorer, you sent "BTC" as a wrapped token on a different network and need a separate recovery workflow.

5. Check minimum deposit thresholds. Some exchanges require deposits above a minimum to credit; below that, the deposit may be held or credited only when combined with a later deposit.

If all five check out and your counterparty still reports the deposit as missing after a reasonable delay (typically six confirmations plus the exchange's processing window), escalate with the TXID, both addresses, the amount, and the timestamp. The TXID is your proof; anything else is optional.

For wrong-network recovery specifically, see sent bitcoin to the wrong address or network. For exchange-side troubleshooting, see haven't received Bitcoin yet.

From a deposit-verification standpoint, a block explorer is the primary source of truth that operational teams at exchanges like BloFin rely on to reconcile whether a user's deposit has actually arrived on-chain; the TXID lookup a retail user performs on mempool.space is structurally the same check an operations team runs internally, just at one-transaction scale rather than thousands per day.

Frequently Asked Questions

Is it safe to share a Bitcoin TXID publicly?

Yes. A TXID is a 64-character hash that identifies one specific transaction on the public ledger. It does not reveal your private keys, your seed phrase, or any other transactions you have made. Anyone can look up a TXID on any block explorer, and the data returned is the same for all of them. Sharing a TXID is the standard way to prove a payment. Avoid sharing full Bitcoin addresses on public forums or social media, because address pages aggregate every transaction at that address and link them to whoever is known to control it.

Why does one explorer say "unconfirmed" and another show my transaction as confirmed?

This is almost always an indexing lag rather than a real disagreement. Each explorer runs its own full nodes and its own database; new blocks propagate through the network in a few seconds, but some explorers index the new block's transactions a minute or two later than others. If explorers disagree, wait 2-5 minutes, refresh, and the slower one will catch up. Persistent multi-hour disagreement is extremely rare and usually indicates a local outage at the slower explorer, not a real ledger difference.

Can a block explorer track Lightning Network payments?

No. Lightning Network payments happen off-chain between two parties inside a payment channel. Only the opening and closing of the channel settle on the Bitcoin blockchain and are visible on a Bitcoin block explorer. The individual Lightning payments between open and close are never broadcast to the Bitcoin network, so no block explorer can see them. For visibility into Lightning payments, you need the wallet that made the payment or specialized Lightning network explorers that work on public channel graph data. For the distinction between on-chain and Lightning, see our guide on the Lightning Network.

What's the difference between "fee rate" and "effective fee rate"?

Fee rate is the simple division of the total fee by the transaction size in virtual bytes (sat/vB). Effective fee rate accounts for CPFP bumps, where a child transaction pays extra fee to pull an unconfirmed parent into a block. If a child is bumping a parent, the parent's simple fee rate looks low but its effective fee rate (computed over both transactions together) is higher. Miners optimize for effective fee rate because that is what determines total block revenue.

Can I reverse a Bitcoin transaction by using an explorer?

No. Block explorers are read-only tools. They display the ledger; they cannot modify it. Once a transaction is confirmed in a block, no mechanism in the Bitcoin protocol can reverse it. Services that advertise "transaction recovery" or "chargeback" for Bitcoin are scams. The only exception involves wrong-network sends to centralized exchanges that offer discretionary recovery procedures, and that is an exchange-side process, not a blockchain-level one.

What does "replaced" mean next to a TXID?

"Replaced" means the original transaction was an RBF-enabled (replaceable) transaction and the sender broadcast a new version paying a higher fee. The original TXID is effectively cancelled and the new TXID becomes the one that will confirm (or already confirmed). Ask the sender for the new TXID. The recipient receives the payment from whichever version confirms, so "replaced" is not a loss event for the recipient; it is a fee-bump event for the sender.

How do I know I'm looking at a real block explorer and not a fake one?

Type the explorer URL directly into your browser or use a bookmark you set yourself. Common legitimate explorers are mempool.space, blockstream.info, blockchair.com, blockchain.com, and btcscan.org. Verify the TLS padlock and the exact domain. Never paste your seed phrase, private keys, or extended keys into any website, including what appears to be an explorer; no legitimate explorer ever asks for those inputs.

What information should I never paste into a block explorer?

Never paste a seed phrase, private key, extended public key (xpub, ypub, zpub), extended private key (xprv, yprv, zprv), wallet backup file, or password. Legitimate explorers only accept TXIDs, addresses, and block identifiers as search inputs. A search bar that accepts or asks for any key material is a phishing trap.

Why does my address page show "total received" higher than my current balance?

"Total received" is the cumulative amount ever received at that address. "Current balance" is what is left after outflows. If the address has ever sent bitcoin out, the total received will exceed the current balance. This is expected behavior, not a discrepancy. The explorer is showing a complete historical record.

How long does it take for a transaction to appear on a block explorer after I broadcast it?

Typically 5 to 30 seconds for most major explorers. Broadcast transactions propagate through the Bitcoin peer-to-peer network in a few seconds and are indexed by explorers within a similar window. If a TXID still does not resolve after 2-5 minutes, the transaction may not have been successfully broadcast; check your wallet for a "rebroadcast" or "resend" option.

Bitcoin block explorer glossary

• Block: A bundle of transactions mined together and added to the Bitcoin blockchain; contains a block header, a coinbase transaction, and regular transactions.

• Block explorer: A web tool that reads the Bitcoin blockchain and presents it in a searchable, human-readable format.

• Block hash: The 64-character hexadecimal cryptographic hash of a block's header; uniquely identifies one block.

• Block height: The sequential position of a block in the chain, starting at 0 for the genesis block.

• Coinbase transaction: The first transaction in every block; has no inputs and creates the block subsidy plus collects all fees for the miner.

• Confirmation: One block added to the chain on top of the block containing a transaction; more confirmations mean greater finality.

• CPFP (Child-Pays-For-Parent): A fee-bump technique where a child transaction pays high fee to pull an unconfirmed parent into a block.

• Effective fee rate: The fee-per-byte calculation that accounts for CPFP parent-child bumps; higher than simple fee rate when a child is bumping a parent.

• Fee rate (sat/vB): Satoshis per virtual byte; the metric miners use to prioritize transactions.

• Genesis block: Block 0 of the Bitcoin blockchain, mined by Satoshi Nakamoto on January 3, 2009.

• Mempool: The set of broadcast transactions waiting for inclusion in a block; each full node maintains its own.

• RBF (Replace-By-Fee): BIP-125 mechanism allowing the sender to replace an unconfirmed transaction with a higher-fee version.

• Satoshi (sat): The smallest bitcoin unit, 0.00000001 BTC.

• TXID (transaction ID): The 64-character hexadecimal identifier for one broadcast transaction.

• UTXO (unspent transaction output): A discrete amount of bitcoin at an address that has not yet been spent; the atomic unit of the Bitcoin accounting model.

• Virtual byte (vB): The SegWit-discounted size unit used for fee calculation.

For the complete terminology set across the pillar, see our Bitcoin glossary.

Researched and written by the BloFin Academy editorial team with AI-assisted drafting. All facts independently verified against Bitcoin Core documentation, the Bitcoin Wiki, and live block-explorer data at time of publication.

Disclaimer: This content is for educational purposes only and does not constitute financial, investment, legal, or tax advice. Crypto assets are highly volatile and carry significant risk of loss. Always verify local regulations and consult a qualified professional before making financial decisions.