Home › Tools › Bitcoin address checker

Bitcoin address checker

Paste a Bitcoin address to check that it's valid and see exactly what it is: its type, network, encoding, checksum, witness program and the output script a payment to it creates. Everything is decoded in your browser, following the rules in BIP 173 and BIP 350.

Updated · 5 min read

Free, and runs entirely in your browser: nothing you type is sent anywhere.

How to use the address checker

  1. Paste an address into the box, or pick one of the examples (one for every address type, mostly taken from the BIP test vectors).
  2. Read the result. A valid address shows its type, network, encoding and checksum, the witness version and program (or the 20-byte hash for older types), the scriptPubKey in hex and as opcodes, and the BIPs that define it.
  3. If the address is invalid, the checker says exactly which rule it breaks. For a mistyped bc1 address it also highlights the one or two characters most likely to be wrong.

It also recognises things people paste by mistake: extended public keys (xpub, ypub, zpub), Lightning invoices and offers, silent payment addresses, bitcoin: payment links (open those in the payment link tool) and output scripts in hex. If you paste something secret, such as a seed phrase, a WIF private key or an xprv, it stops, warns you, and keeps it out of the page address.

What type of Bitcoin address is this?

The first characters tell you the type. The checker confirms it by decoding the whole address, because the prefix alone can be faked by a typo.

Starts with Type Encoding Output script Defined in
1 P2PKH (legacy) Base58Check OP_DUP OP_HASH160 <20 bytes> OP_EQUALVERIFY OP_CHECKSIG Original software
3 P2SH (script or wrapped SegWit) Base58Check OP_HASH160 <20 bytes> OP_EQUAL BIP 13, BIP 16
bc1q (42 characters) P2WPKH (native SegWit) Bech32 OP_0 <20 bytes> BIP 141, BIP 173
bc1q (62 characters) P2WSH (SegWit script) Bech32 OP_0 <32 bytes> BIP 141, BIP 173
bc1p (62 characters) P2TR (Taproot) Bech32m OP_1 <32 bytes> BIP 341, BIP 350
bc1pfeessrawgf P2A (anchor output) Bech32m OP_1 <0x4e73> BIP 433

Test networks use different prefixes for the same types: tb1 for testnet and signet, bcrt1 for regtest, and m, n or 2 for the Base58 types. Coins sent on those networks have no value. The address types guide explains each type in depth.

bc1q vs bc1p: what's the difference?

The character after bc1 is the SegWit version, written in the Bech32 alphabet: q is version 0 and p is version 1. A bc1q address is native SegWit (BIP 141) and uses the Bech32 checksum. A bc1p address is Taproot (BIP 341) and uses Bech32m (BIP 350).

Both are cheap to spend. Taproot adds privacy: a key-path spend looks the same whether one key, a MuSig2 multisig or a hidden script tree controls the coins. Its output is 12 bytes larger than P2WPKH, but its typical input is smaller. Any wallet that supports BIP 350 can send to both; wallets that only implement BIP 173 can't send to bc1p. The BIP 173 vs BIP 350 comparison covers the details.

How address checksums catch typos

Base58Check (addresses starting with 1 or 3) adds 4 bytes to the version byte and 20-byte hash: the start of SHA-256 applied twice. A typo almost always breaks it, but the checksum can't say where the mistake is.

Bech32, designed by Pieter Wuille and Greg Maxwell in BIP 173, uses a BCH code instead. It guarantees to detect any error affecting up to 4 characters, with less than a 1 in a billion chance of missing more. It can also locate a few substituted characters, which is how this checker highlights them. BIP 173 says software should only point at likely errors, never "correct" an address, so the tool doesn't suggest a fix.

Bech32m (BIP 350, by Pieter Wuille) changes one constant in the checksum. Bech32 has a weakness: when the last character is a p, inserting or deleting q characters just before it doesn't break the checksum. Version 0 addresses have fixed lengths, so they're safe, but newer versions aren't. Since BIP 350, version 0 must use Bech32 and versions 1 to 16 must use Bech32m. A Taproot address with an old Bech32 checksum is rejected, so outdated software can't burn coins by mangling it.

Every rule the checker applies

  • Base58 addresses: only Base58 characters (no 0, O, I or l), a valid double SHA-256 checksum, 21 bytes of payload, and a version byte of 0x00 or 0x05 (mainnet) or 0x6f or 0xc4 (test networks).
  • Bech32 and Bech32m addresses: at most 90 characters, all lowercase or all uppercase (never mixed), prefix bc, tb or bcrt, and a valid checksum.
  • A SegWit version from 0 to 16, and a witness program of 2 to 40 bytes with at most 4 bits of zero padding.
  • Version 0 programs are exactly 20 bytes (P2WPKH) or 32 bytes (P2WSH), and version 0 uses Bech32 while later versions use Bech32m.

These are the rules and test vectors from BIP 173 and BIP 350; the checker passes all of them.

What a valid address doesn't tell you

A valid checksum proves the address wasn't mistyped, not that it belongs to the person you mean to pay. Malware that swaps copied addresses produces perfectly valid ones, so compare the address on your hardware wallet's screen or with the recipient. The checker works offline, so it can't show balances or history.

Some valid addresses shouldn't receive payments. Versions 2 to 16, and version 1 programs other than Taproot's 32 bytes, have no spending rules yet, so anyone could take coins sent there today. A P2A output is spendable by anyone by design. And for privacy, use a fresh address for every payment: reusing one links your payments together on-chain.

Frequently asked questions

How do I know if a Bitcoin address is valid?

Paste it into the checker. Every Bitcoin address carries a checksum: Base58Check for addresses starting with 1 or 3, Bech32 or Bech32m for addresses starting with bc1. If one character is wrong, the checksum fails and the address is rejected. A valid result means the address is well formed, not that it belongs to the person you intend to pay.

What is the difference between bc1q and bc1p addresses?

The fourth character is the SegWit version. bc1q addresses are SegWit version 0 (P2WPKH or P2WSH, from BIP 141 and BIP 173) and use the Bech32 checksum. bc1p addresses are version 1, Taproot (BIP 341), and use Bech32m (BIP 350). Both are cheap to spend; Taproot spends look alike whatever the spending policy, which helps privacy.

What do Bitcoin addresses starting with 1, 3 and bc1 mean?

Addresses starting with 1 are legacy P2PKH, paying to a single public key hash. Addresses starting with 3 are P2SH (BIP 16), paying to a script such as multisig or wrapped SegWit. Addresses starting with bc1 are native SegWit: bc1q for version 0 and bc1p for Taproot. On test networks the prefixes are m or n, 2, and tb1.

What happens if I send bitcoin to a mistyped address?

Almost certainly nothing, because the wallet refuses. A mistyped character breaks the checksum, and Bech32 is guaranteed to catch any mistake in up to 4 characters. The real risks are a valid address that isn't the recipient's, for example one swapped in by clipboard malware, or an address for the wrong network or a future SegWit version.

Are Bitcoin addresses case-sensitive?

Legacy addresses starting with 1 or 3 are: Base58 uses both cases, so changing one letter's case makes a different (invalid) address. Bech32 and Bech32m addresses are not: bc1q... and BC1Q... are the same address, though mixing cases is invalid. Wallets show them in lowercase, and QR codes use uppercase because it encodes more compactly.

Is it safe to paste my address into this checker?

Yes. The checker runs entirely in your browser and sends nothing anywhere, and an address is meant to be shared anyway. Never paste a seed phrase, private key or xprv into any website, including this one: the checker recognises those, warns you and doesn't process them.

BIPs in this article

  • BIP 173 (Bech32): Base32 address format for native v0-16 witness outputs: Deployed. Introduces Bech32, an address format for native SegWit outputs, recognizable by addresses starting with "bc1". It uses only lowercase letters and numbers and a strong checksum that catches typing…
  • BIP 350: Bech32m format for v1+ witness addresses: Deployed. Introduces Bech32m, a corrected version of the Bech32 address format used for SegWit addresses (those starting with 'bc1'). A subtle flaw in Bech32 could let certain typos go undetected, so Bech32m…
  • BIP 141 (SegWit): Segregated Witness (Consensus layer): Deployed. Defines Segregated Witness (SegWit), which moves signatures into a separate "witness" section of each transaction while remaining compatible with older nodes. This fixed transaction malleability,…
  • BIP 341: Taproot: SegWit version 1 spending rules: Deployed. Taproot introduces a new kind of Bitcoin output that can be spent either with a single signature or by revealing just one of many possible alternative spending conditions, kept hidden in a tree…
  • BIP 13 (P2SH addresses): Address Format for pay-to-script-hash: Deployed. Defines the address format for pay-to-script-hash, the addresses that begin with "3". Such an address stands for a hidden set of spending rules, so people can pay into arrangements like multisig as…
  • BIP 16 (P2SH): Pay to Script Hash: Deployed. Introduced Pay to Script Hash (P2SH), letting a sender pay to a short fingerprint of spending rules that the recipient reveals only when spending. This shifted the cost and complexity of setups like…
  • BIP 84 (native SegWit derivation): Derivation scheme for P2WPKH based accounts: Deployed. Specifies the standard key path for HD wallets that use native SegWit addresses (those starting with 'bc1q'). Agreeing on this path means a user can restore the same seed phrase in different wallet…
  • BIP 86 (Taproot derivation): Key Derivation for Single Key P2TR Outputs: Deployed. Defines the standard key path for HD wallets that use single-key Taproot addresses (those starting with 'bc1p'). It plays the same role for Taproot that BIP 84 does for SegWit, so seed phrases…
  • BIP 433: Pay to Anchor (P2A): Draft. Defines Pay to Anchor, a tiny standard output that anyone can spend without a signature. Its purpose is to act as a hook for fee-bumping: by spending it in a follow-up transaction, any party can add…
  • BIP 352: Silent Payments: Complete. Silent Payments let someone publish one static address that anyone can pay, while each payment lands at a different, unlinkable address on the blockchain. Unlike similar schemes, it needs no extra…

Learn more

Guides

Free tools

Glossary