Bitcoin address formats: Legacy, SegWit, and Taproot

One network, several ways to encode a destination

A Bitcoin address is a human-readable encoding for a payment destination. Different formats reflect different output scripts and address encodings—not different versions of bitcoin. On Bitcoin mainnet, the first characters are useful clues, but they are not a complete safety check.

Read the common mainnet clues

• 1… — P2PKH, often called legacy. A common mainnet Base58Check address format, as shown in the Bitcoin Developer Guide's transaction reference.
• 3… — P2SH. BIP 13 specifies this mainnet Base58Check prefix for a script-hash destination. The prefix alone does not tell you which script is behind it; P2SH can support multisignature arrangements and can also wrap a SegWit spend (BIP 141).
• bc1q… — native SegWit version 0. BIP 173 specifies Bech32 for version-0 witness addresses such as P2WPKH and P2WSH.
• bc1p… — native SegWit witness version 1, encoded with Bech32m. BIP 350 assigns Bech32m to witness version 1 and later; standard Taproot (P2TR) outputs use a 32-byte witness program (BIP 341). The prefix by itself does not reveal the full program.

For Bech32 witness addresses, bc is the human-readable part for Bitcoin mainnet and tb is used for testnet (BIP 173). Base58 P2PKH and P2SH addresses also use different version bytes on testnet. These are format and network clues, not a substitute for decoding and checking a full address. Wallets and services may differ in which formats they support for sending or receiving.

Does a prefix mean a cheaper fee?

Not by itself. A network fee depends on the signed transaction's virtual size and fee rate. The inputs, outputs and their scripts or witness data affect that size; so can the output script created for the destination. Network demand also changes the fee rate a wallet may suggest. A prefix alone cannot tell you what a specific send will cost, so check the current estimate in the sending wallet. The Bitcoin Developer Guide's transaction chapter explains inputs and outputs, and Bitcoin.org's fee guide explains why fees depend on transaction size and current demand. For the fee calculation and the other costs that can appear on a route, see Bitcoin transaction fees explained.

What a prefix cannot verify

A familiar prefix does not identify the person or service behind an address, prove that it belongs to the intended recipient, or establish that the sender's wallet supports that format. Nor does the prefix alone guarantee a particular fee, privacy property or recovery option. A checksum can help detect some typing errors; it cannot tell you whether you selected the right recipient. For why a public address does not, by itself, reveal a person's identity, see Is Bitcoin Anonymous?.

Use the address as part of a receiving check

1. Confirm that both sides mean Bitcoin on the same network. 2. Create or retrieve the address from the intended wallet's receive screen or the recipient's independently verified instructions. 3. Compare the complete address—not just its first characters—and check that the sending wallet accepts it before approving. 4. For an exchange or hosted service, check its current deposit instructions and confirmation policy.

If an address changes unexpectedly, stop and verify it through a separate trusted channel. Do not expose a recovery phrase or private key to check an address. For the transaction stages after signing, see how Bitcoin transactions work. For signing and recovery responsibilities, compare Bitcoin wallet choices.

Try the visual match

Match each prefix in the diagram to its format, then explain why a correct format label still cannot prove that the address belongs to the person you intend to pay. The labels are a learning aid, not a real address validator or a prompt to send funds.