You verify a Bitcoin transaction by looking up its transaction ID in a block explorer and checking how many confirmations it has. That takes about thirty seconds and needs no account, no app, and no permission from anyone. The Bitcoin ledger is public, so every payment ever made can be independently checked by anybody who wants to check it.
The part most guides leave out is that a transaction can look finished on screen and still not be settled. Since October 2024, every unconfirmed Bitcoin transaction is replaceable by default, which means a pending payment is a request, not a receipt. Knowing the difference is what separates verifying a transaction from merely looking at one.
This guide covers how to check a transaction's status, how to read every field on an explorer page, how many confirmations different situations call for, how the network itself validates transactions, and how to tell a real payment from a fabricated one.
Key Takeaways
- Every Bitcoin transaction has a unique transaction ID (TXID), a 64 character string that acts as its permanent reference on the blockchain
- To check a transaction, paste the TXID into a block explorer and read the status, the confirmation count, and the output addresses
- Zero confirmations means nothing is settled. Since Bitcoin Core 28.0 in October 2024, full Replace-by-Fee (RBF) has been the default policy, so any unconfirmed transaction can be replaced by a higher-fee version
- One confirmation is enough for small amounts between people who trust each other. Six is the long-standing convention for large transfers. Newly mined coins are locked for 100 blocks by consensus rule
- Confirming a TXID exists is not the same as confirming you were paid. Check that one of the outputs is your address and that the amount matches
- Screenshots prove nothing. Anyone can fabricate one, and fake payment proof is a common tactic in a fraud category that cost Americans more than $11 billion in 2025
- Verification runs in two directions: check the details on your hardware wallet screen before you sign, and check the transaction on-chain after you broadcast
How to Check a Bitcoin Transaction in Four Steps
Every Bitcoin transaction is recorded on a public ledger. Checking one is a lookup, not a request for information from a company.
Step 1: Find the Transaction ID
The transaction ID, usually shortened to TXID and sometimes called the transaction hash, is a 64 character string of letters and numbers. It looks like this:
4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
Where to find it depends on where the transaction came from:
- Self-custody wallet: open the transaction in your history and look for "transaction details", "view on blockchain", or an ID field. In the Bitcoin.com Wallet, tapping a transaction reveals its full details
- Exchange or custodial service: check the withdrawal history. Most platforms display the TXID once the withdrawal has been broadcast, often as a clickable link
- You are the recipient and have no TXID: you can search your receiving address instead. The explorer will list every transaction that has touched it
Always copy the TXID with the copy button rather than typing it by hand. A single wrong character returns nothing, and 64 characters is a lot of room for a typo.
Step 2: Open a Block Explorer
A block explorer is a search engine for the blockchain. It reads the public ledger and presents it in a format people can actually use. The Bitcoin.com block explorer handles TXIDs, addresses, and block heights.
Two things to get right before you search:
- Check you are on a Bitcoin mainnet explorer: Testnet transactions, Bitcoin Cash transactions, and Litecoin transactions all produce identifiers that look similar. They belong to unrelated ledgers, and searching the wrong one returns nothing or, worse, returns something misleading
- Check the domain carefully: Cloned explorer sites exist for the sole purpose of displaying fake confirmations to people who were sent a link. Type the address yourself or use a bookmark
Step 3: Search the TXID and Read the Status
Paste the TXID into the search bar. The transaction page will show one of three states:
- Unconfirmed or pending: the transaction has been broadcast and is sitting in the mempool, waiting for a miner to include it in a block. Nothing is settled
- Confirmed: the transaction has been included in a mined block. The page will show which block, and the confirmation count starts climbing from there
- Not found: the explorer has no record of it. See the troubleshooting section further down, because this has several very different causes
Step 4: Check the Details, Not Just the Status
This is the step almost everyone skips, and it is the one that matters. A transaction being real and confirmed tells you a payment happened. It does not tell you that you were paid.
Read the output addresses. At least one of them should be your receiving address. Check the amount against what you expected. Then check the confirmation count against the threshold appropriate to the situation, which the next sections cover.
What Every Field on the Explorer Page Means
Explorer layouts differ, but the underlying data is identical because it all comes from the same ledger. Here is what each field tells you.
| Field | What it shows | What to watch for |
|---|---|---|
| TXID / Transaction hash | The transaction's unique 64 character identifier | Confirm it matches the one you were given, character for character, not just the first and last few |
| Status | Confirmed, unconfirmed, or pending | Unconfirmed means it is in the mempool and can still be replaced |
| Confirmations | How many blocks have been mined on top of the block containing this transaction | Rises by one roughly every ten minutes. Zero means it is not in a block at all |
| Block height | The sequential position of the containing block in the chain | Should be at or below the current chain tip. A height above the tip is impossible on mainnet |
| Timestamp | When the block was mined, not when the transaction was created | A transaction can sit in the mempool for hours before this timestamp |
| Inputs | The unspent transaction outputs (UTXOs) being spent, and the addresses they came from | Multiple inputs are normal. Wallets combine several UTXOs to cover an amount |
| Outputs | The addresses receiving bitcoin, and how much each gets | One of these must be your address if you are the recipient |
| Change output | Bitcoin returned to the sender's own wallet | Frequently mistaken for a second payment. It is not. This is normal and expected |
| Fee | The total amount paid to miners, in BTC or satoshis | Not a percentage of the amount sent. It is priced by data size |
| Fee rate | The fee expressed in satoshis per virtual byte (sat/vB) | This is what determines confirmation speed, not the total fee |
| Virtual size | How much block space the transaction occupies, in virtual bytes | More inputs means a larger transaction and a higher total fee at the same rate |
Two points that catch people out regularly.
Change outputs are not payments - If you send 0.1 BTC from a wallet holding 0.5 BTC, the explorer will show two outputs: 0.1 BTC to the recipient and roughly 0.4 BTC back to a fresh address your own wallet controls. This looks alarming the first time, but it is how Bitcoin transactions work at the protocol level.
Fees are charged by size, not by value - A transaction moving $50 and a transaction moving $5 million can cost exactly the same if they occupy the same block space.
How Many Confirmations Do You Actually Need
A confirmation means your transaction was included in a mined block. Each subsequent block mined on top of it adds another confirmation and makes reversal exponentially harder.
The requirement is not fixed. It scales with what you stand to lose.
| Confirmations | Appropriate for | Why |
|---|---|---|
| 0 | Nothing that matters | The transaction is in the mempool and replaceable. This is not settlement |
| 1 | Small amounts between parties who already trust each other | The transaction is in a block. Reversing it now requires a chain reorganization |
| 3 | Mid-value transfers. A common threshold for crediting deposits | Reorganizations three blocks deep are extremely rare |
| 6 | Large transfers and anything irreversible on your side | The long-standing convention, and the point at which reversal becomes impractical |
| 100 | Newly mined coins only | A consensus rule, not a convention. Coinbase outputs cannot be spent until 100 blocks deep |
Where the Six-Confirmation Rule Comes From
The number is not arbitrary and it is not superstition. It comes from probability calculations in the original Bitcoin whitepaper, which modeled an attacker trying to out-mine the honest network to reverse a payment. An attacker controlling a modest share of hashrate has a small but real chance of undoing one confirmation. By six, the probability collapses toward zero for any realistic adversary.
That math assumes an attacker who does not control a majority of hashrate. As of September 7, 2026, the Bitcoin network hashrate sits at roughly 915 - 921 EH/s with mining difficulty at 125.81 T, which makes the cost of assembling that kind of attack enormous.
The 100-Block Rule Is Different
Coinbase maturity is enforced at the consensus layer rather than chosen by policy. Newly mined bitcoin cannot be spent until the block that created it is 100 blocks deep. The rule exists because a chain reorganization can strand a freshly mined block, and if the miner had already spent the reward, every transaction downstream would unravel. This affects miners spending their own rewards. It does not affect ordinary payments.
A Note on Platform Thresholds
Exchanges, payment processors, and custodial services each set their own deposit requirements, typically somewhere between one and six confirmations. These are operational policies rather than protocol rules, and they change without announcement. Before moving a large amount onto any platform, check that platform's own current support documentation rather than relying on a number you read in an article, including this one.
What "Unconfirmed" Means Now That Full-RBF Is the Default
This is where most guides on this topic are out of date, and it changes the practical advice.
Replace-by-Fee (RBF) lets a sender replace an unconfirmed transaction with a new version paying a higher fee. It was introduced as an opt-in feature under BIP 125 in 2016, and for years the sender had to actively signal replaceability by setting a field called nSequence. If a transaction did not carry that signal, merchants often treated it as reasonably safe to accept before confirmation.
That reasoning no longer holds. Bitcoin Core 28.0, released in October 2024, made full-RBF the default mempool policy. Every unconfirmed transaction is now treated as replaceable regardless of whether the sender signaled anything. The signal became meaningless, and in June 2026 Bitcoin Core contributors proposed removing it from wallet software entirely on the grounds that it is redundant and leaks information about which wallet built the transaction. Bitcoin Optech maintains a current technical summary of how the policy works.
The practical consequences:
- Zero-confirmation payments provide no settlement guarantee. A sender can replace a pending transaction with one that redirects the funds to an address they control
- A pending payment is a statement of intent. It tells you someone broadcast a transaction. It does not tell you the money is yours
- Anyone accepting bitcoin for goods, services, or another asset should wait for at least one confirmation. For anything substantial, wait for more
- RBF is also useful to you. If your own transaction is stuck at a low fee rate, you can replace it with a higher-fee version, or the recipient can use Child-Pays-For-Parent (CPFP) to pull it through from their side
One more recent change worth knowing about: Bitcoin Core 31.0 rebuilt the mempool around a design called cluster mempool, grouping related unconfirmed transactions into clusters of up to 64 transactions and 101 kB of virtual size, then ordering them by the fee rate at which the group is expected to be mined. Most of this is invisible to ordinary users, but it makes fee-bumping through RBF and CPFP behave more predictably.
How the Bitcoin Network Verifies Transactions
Everything above is about how you check a transaction. This section is about how the network decides a transaction is valid in the first place. The two are often confused because they share the word "verify."
There is no central authority approving payments. Validation is performed independently by thousands of computers, each of which reaches its own conclusion using the same rules.
Nodes Validate
A Bitcoin node is a computer running Bitcoin software and holding a copy of the blockchain. When a transaction reaches it, the node checks it against consensus rules:
- Does the digital signature match? The sender must prove control of the private key corresponding to each input being spent. This is what stops anyone spending coins they do not own
- Do the inputs exist and remain unspent? Every input must reference a real, previously unspent output. This is what stops double-spending
- Do the numbers work? Outputs cannot exceed inputs. The difference becomes the miner's fee
- Is the transaction well-formed? Correct structure, valid scripts, within size limits
A transaction failing any check is rejected outright and never relayed further. This happens before mining and independently of it.
Miners Order and Commit
Miners select validated transactions from the mempool, assemble them into a candidate block, and compete to find a valid proof of work for it. Selection is economic: they order by fee rate in satoshis per virtual byte to maximize revenue from the roughly 4 million weight units of space each block provides.
Winning that race broadcasts the block to the network, where every node validates it independently before accepting it. Miners do not decide whether a transaction is valid. They decide which valid transactions get committed to the ledger first, and in what order.
The distinction matters for verification. A miner cannot force an invalid transaction into the chain, because every node would reject the block containing it. What miners control is timing, which is why fee rate determines how quickly you confirm.
How to Verify a Payment Someone Says They Sent You
If you are receiving bitcoin in exchange for anything, this is the section that protects you. Run every check in order and do not skip forward because the first one passed.
- Get the TXID, not a screenshot: Ask for the transaction ID. A genuine sender has it available in seconds
- Look it up yourself: Type the explorer address yourself. Never use a link someone sent you
- Confirm one of the outputs is your address: A transaction can be entirely real and have nothing to do with you. Check the full address string, not the first four characters
- Confirm the amount matches: Check the output paying your address specifically, not the total transaction value
- Check the confirmation count against the value at stake: Zero confirmations means wait
- Cross-check on a second independent explorer: If two explorers disagree about whether a transaction exists or how many confirmations it has, stop
- Check the timestamp: A confirmation timestamp from three years ago is an old transaction being presented as new
The pattern this defends against is straightforward. Someone shows apparent proof of an incoming payment, applies time pressure, and gets you to release goods, funds, or another asset before the payment settles. Then the pending transaction is replaced or was never real in the first place.
How to Spot a Fake Bitcoin Transaction
Fabricated payment proof is common enough to deserve its own checklist. The FBI's Internet Crime Complaint Center recorded 181,565 cryptocurrency-related complaints in its 2025 Internet Crime Report, published April 2026, accounting for more than $11.36 billion in reported losses out of roughly $20.9 billion total. The overwhelming majority of that involved social engineering rather than any technical compromise of Bitcoin itself.
| Red flag | What is actually happening | How to check |
|---|---|---|
| Screenshot offered as proof | Images are trivial to edit or generate. They prove nothing about the ledger | Ask for the TXID and look it up yourself |
| TXID returns no results | The identifier was invented, or belongs to a different network | Confirm you are on a mainnet explorer, then treat a persistent miss as fabricated |
| Zero confirmations presented as complete | The transaction may be real but is replaceable and unsettled | Wait for confirmations. Do not release anything |
| Block height above the current chain tip | Impossible on mainnet. The screenshot is fake or from a testnet | Compare against the current height. On September 7, 2026 the chain was at block 965,769 |
| Explorer link supplied by the sender | Cloned explorer sites display whatever the operator wants them to | Navigate to an explorer yourself and search the TXID |
| Transaction exists but your address is absent from the outputs | A real transaction between other parties, presented as a payment to you | Read the output addresses in full |
| Amount does not match, or is split across outputs | Partial payment framed as full payment | Check the specific output paying your address |
| Transaction was real, then vanished | Replaced through RBF, or evicted from the mempool | Re-check the TXID. A replacement will have a different ID |
| Pressure to act before confirmation | The entire scam depends on your urgency | Urgency from a counterparty is the signal, not the exception |
The single habit that defeats nearly all of these: get the TXID, search it yourself on an explorer you navigated to, and wait for confirmations proportional to the value at stake.
Verifying a Transaction Before You Sign It
Verification after the fact tells you what happened. Verification before you sign determines what happens. If you are sending rather than receiving, this is the more important half.
The threat is not that Bitcoin's cryptography fails. It is that the screen you are reading has been tampered with. Clipboard-hijacking malware watches for a copied Bitcoin address and swaps it for the attacker's. Compromised interfaces display one address while building a transaction that pays another. In both cases the transaction you sign is valid, correctly signed, and irreversible. It just pays the wrong person.
Practical defenses:
- Verify the recipient address on a hardware wallet screen, not on your computer. The device screen is driven by the device, so it shows what is actually being signed. If malware has compromised your computer, this is the only display you can trust
- Compare the full address, not the ends. Attackers generate addresses matching the first and last few characters specifically because that is all most people check
- For large transfers, confirm the address through a separate channel. A phone call beats a message in the same app that might be compromised
- Do a test send first. Send a small amount, confirm it arrives, then send the rest. The fee on a test send is trivial compared to the alternative
- Never approve a transaction you cannot read. If a device asks you to sign something it cannot display in a form you understand, stop
Bitcoin transactions cannot be reversed once confirmed. There is no chargeback, no support line, and no authority that can undo a payment.
What to Do When Your Transaction Is Not Found
"Not found" has several causes that look identical on screen and need completely different responses.
| Symptom | Likely cause | What to do |
|---|---|---|
| Explorer returns nothing at all | TXID copied with a trailing space, or a character mistyped | Re-copy using the copy button. Check for whitespace |
| Nothing found, TXID definitely correct | You are on the wrong network's explorer | Confirm mainnet Bitcoin, not testnet, Bitcoin Cash, or another chain |
| Wallet shows sent, explorer shows nothing | The transaction was never successfully broadcast | Check your connection and use your wallet's rebroadcast function if it has one |
| Was visible, now gone | Evicted from the mempool after sitting below the minimum relay fee rate | Rebroadcast, or wait for the funds to become spendable again |
| Was visible, now a different TXID exists | Replaced through RBF. The replacement has its own identifier | Search the new TXID. The original will never confirm |
| Visible on one explorer, not another | Indexing lag, or the transaction has not propagated to that node's mempool | Wait a few minutes and re-check. Persistent disagreement is a warning sign |
| Confirmed long ago, now missing | Extremely unlikely. Investigate before assuming anything | Verify on a second explorer, ideally your own node |
| Identifier is 64 characters but nothing matches | You may have the wtxid rather than the txid | For SegWit transactions these differ |
Stuck rather than missing is a different problem. A transaction sitting unconfirmed with a fee rate below current demand needs a fee bump through RBF, a CPFP push from the recipient, or patience. Network conditions matter here: as of September 7, 2026 the mempool was quiet at roughly 242 MB with around 81,000 pending transactions, so even low fee rates were confirming quickly. During congestion the picture changes within hours.
Verifying Independently with Your Own Node
There is a distinction worth understanding: most people never verify a transaction themselves. They ask someone else and trust the answer.
Mobile and desktop wallets typically operate as Simplified Payment Verification (SPV) clients. They do not hold the full blockchain or validate consensus rules. They query a server, receive an answer about your balance and transaction status, and display it. This is a reasonable trade-off, because full validation requires downloading and verifying the entire chain. But it means your wallet is reporting what a server told it.
Block explorers involve the same trust. An explorer is a website reading a blockchain and rendering the result. Well-run explorers are accurate, which is why cross-checking two independent ones is worthwhile. It is also why cloned explorer sites work as an attack.
Running a full node removes the middleman. Your node downloads every block, validates every transaction against consensus rules, and answers your questions from its own copy of the ledger. Nobody can show you a transaction that does not exist or hide one that does. Release notes and download instructions are published at bitcoincore.org.
The Privacy Cost of Public Lookups
One point rarely mentioned: searching your own TXID or address on a public explorer links that transaction to your IP address, and potentially to your identity. Bitcoin's ledger is public but pseudonymous, and the connection between an address and a person is exactly what most users would prefer not to hand over.
If that concerns you, the options are running your own node and querying it locally, or accessing explorers through a privacy-preserving connection. Bitcoin Core 31.0 also added the option for nodes to broadcast transactions exclusively over Tor or I2P, keeping your IP address off the clearnet when you send. This is not a reason to avoid checking your transactions. It is a reason to know what the check costs.
Conclusion
Verifying a Bitcoin transaction means looking up its transaction ID on a block explorer, reading the confirmation count, and checking that the outputs and amount match what you expected. The whole process is public and takes under a minute.
The habits that matter are simple ones. Get the TXID rather than a screenshot. Navigate to the explorer yourself rather than following a link. Read the output addresses in full. Treat zero confirmations as unsettled, because under full-RBF every pending transaction is replaceable. Verify the address on your hardware wallet screen before you sign, because that is the last moment anything can be changed. And scale your confirmation threshold to the amount at stake.
Bitcoin removed the need to trust an intermediary, but it did not remove the need to check. The ledger is open precisely so that you can.
