bc1qrv0v2l9…m7sn7e4v4 — P2WSH (native SegWit v0, pay to witness script hash) — Bitcoin address inspector

What this page does — and where each answer comes from

There are two fundamentally different kinds of question you can ask about an address, and this page keeps them apart on purpose:

The first three are facts derived from the string itself and can never be wrong. The fourth is a claim by a third party, and the page says which explorer made it. If there is no network, the first three still work perfectly and the fourth says so.

1. What a Bitcoin address actually is

An address is not a key, not an account, and not a wallet. It is a short, checksummed encoding of a spending condition — technically, a commitment to a script that a future transaction must satisfy. The blockchain never stores addresses at all: it stores outputs locked by a script, and an address is simply a human-friendly way to write down certain scripts.

That distinction explains most of what confuses people:

• Nobody "owns" an address. Whoever can satisfy the script can spend the output.
• An address can receive money without anyone holding its key — for example a burn address.
• A wallet does not "hold" addresses; it holds keys and can regenerate addresses from them.

2. The two encoding families

Bitcoin has exactly two ways of writing an address down, and telling them apart is the first thing this page does:

The Base58 alphabet excludes 0, O, I and l precisely because they are the characters humans confuse when copying from paper. Bech32 goes further: banning mixed case turns a whole class of transcription error into a hard failure.

3. The address types, and what each one commits to

This is the part that makes some addresses convertible into others and some not. Every address commits to a single 20-byte or 32-byte value, but what that value is depends on the type:

4. Sibling addresses: one key, several addresses

Because P2PKH, P2WPKH and P2SH-P2WPKH all commit to the same 20 bytes — the hash of the compressed public key — any one of them determines the other two. This is not a security weakness; it is simply the same commitment written in different scripts.

It matters enormously in practice. The classic disaster is a key whose coins sit at the P2PKH address while the wallet in use only ever looks at the P2WPKH address (or the reverse, or testnet vs mainnet). The wallet reports a zero balance and the owner concludes the funds are gone. The coins are usually still there, and looking at the sibling addresses is how you find them.

All six rows above are the same private key. Two of them are on testnet, which is a different network entirely — coins cannot be moved between them, but the same key controls both.

5. What validation does — and does not — mean

This page verifies the checksum, the character set, the length, the version byte or witness version, the program length, the case rule and the padding rule. Passing all of that means one thing only: the string is a well-formed address that no Bitcoin node would reject as malformed.

It does not mean:

• that anyone can spend it — a burn address validates perfectly;
• that it is yours, or that it has ever been used;
• that it is the address you meant. A checksum catches typos with high probability, but it is a detector, not a corrector. If a typo happens to produce another valid checksum, the result is a different, perfectly valid address — and money sent there is gone. Base58Check's 4 bytes give a roughly 1-in-4-billion chance per random corruption; bech32's code has stronger published bounds and additionally rejects the mixed-case mistakes that Base58 can only mis-encode.

6. Reading a balance correctly

There is no "balance" field in Bitcoin. What exists is a set of unspent outputs, each locked to a script. An address's balance is computed by summing the unspent outputs that pay it:

Three consequences follow, and the page shows the ingredients separately so you can check them:

• Total received can be far larger than the current balance. An address that has been swept a hundred times shows a large received figure and a zero balance — that is normal, not a bug.
• Unconfirmed outputs live in the mempool, not in a block. They count toward a balance the moment they are seen, but they can still disappear if the transaction is replaced or dropped.
• Confirmations equal tip height − block height + 1. Fewer than a handful means a reorganisation could still un-include the transaction. Six is the traditional informal threshold, not a rule.

7. Reading the transaction list

The history this page shows is written from the address's point of view. For each transaction it computes how much the address received, how much it spent, and the net effect:

Other columns deserve a note:

• Fee is paid by whoever's inputs the transaction consumes, so it is only really "yours" on outgoing transactions. It is shown for every row because it is a property of the transaction.
• vBytes is weight ÷ 4, the unit fees are actually priced in. Witness data is discounted fourfold, which is exactly why SegWit and Taproot inputs are cheaper.
• Counterparties are the other addresses in the transaction — recipients when you sent, senders when you received. A row with none usually means the outputs were data carriers (OP_RETURN), which hold no coins and have no address.
• Revealed public key. The moment an address spends, its public key is published on chain. Until then, a P2PKH or P2WPKH address is protected by the hash alone. This page reports whether the address has ever spent, because that single fact changes its quantum-resistance profile.

8. Privacy: who learns that you looked

Validation happens entirely on this server. On-chain lookups do not, and there are two separate paths:

Either way, an address query is a privacy leak: asking about an address links you to it. Reusing one address for every payment publishes your whole financial history to anyone who looks, and asking a public API about your own addresses tells that API's operator what you hold. If that matters to you, run your own node and query it locally.

9. Special and unspendable addresses

Some addresses are famous enough to be worth recognising, and this page labels them:

Burning coins is a real technique — it is how some protocols make a commitment that can never be redeemed. It is also, obviously, irreversible.

10. Quick reference