A Bitcoin address is a payment instruction, not an account name. On mainnet, the first characters usually tell you which encoding and output type a wallet is asking for: 1 for legacy P2PKH, 3 for P2SH, bc1q for SegWit version 0, and bc1p for Taproot. Those prefixes help with a quick check, but they do not identify the recipient and they are not enough to prove that an address is safe.
The practical choice is usually simple: use the newest address type that both the receiving wallet and the sending service support. Do not convert an address by hand. Copy it from the receiving wallet, compare the beginning and end, and let the sending wallet validate the checksum.
This guide reflects Bitcoin Core and Bitcoin Improvement Proposal documentation checked on 31 October 2026. It does not report hands-on wallet testing.
The four address families at a glance
| Mainnet prefix | Common name | Output type | Encoding | What the prefix can tell you |
|---|---|---|---|---|
| 1… | Legacy | P2PKH | Base58Check | A public-key-hash output using the original address family |
| 3… | P2SH or nested SegWit | P2SH | Base58Check | A script-hash output; the address alone does not reveal whether it wraps SegWit |
| bc1q… | Native SegWit | P2WPKH or P2WSH, witness v0 | Bech32 | A native version-0 witness output |
| bc1p… | Taproot | P2TR, witness v1 | Bech32m | A version-1 Taproot output with a 32-byte witness program |
This is a mainnet table. Test networks use different prefixes. An address that looks plausible for another network must not be treated as a valid mainnet destination.
Legacy P2PKH addresses start with 1
A legacy Pay-to-Public-Key-Hash address represents the hash of a public key. On Bitcoin mainnet it begins with 1 and uses Base58Check encoding.
Legacy addresses remain valid. “Legacy” describes the output format, not a deadline after which the address stops working. The trade-off is efficiency: spending a legacy output places the signature and public key in the traditional transaction input, so it generally uses more virtual bytes than an equivalent SegWit spend.
That affects the size of a later spending transaction, not the amount received. Our Bitcoin fee estimation guide explains why wallets quote fees in satoshis per virtual byte and why a target fee rate is not the same as the final fee.
Addresses starting with 3 are script hashes
A mainnet address beginning with 3 is a Pay-to-Script-Hash address. BIP 13 defines it as an encoded 20-byte hash of a redeeming script. BIP 16 defines how that script is supplied and checked when the output is spent.
A 3 prefix does not uniquely mean nested SegWit. P2SH was created before SegWit and can represent other scripts, including multisignature constructions. A wallet can also place a P2WPKH witness program inside P2SH. That wrapped form is commonly called P2SH-P2WPKH or nested SegWit.
Bitcoin Core’s SegWit wallet guide says the wrapped address is indistinguishable from another P2SH address until the redeem script is exposed. This is why an address decoder should not label every 3… address as SegWit.
Nested SegWit was useful during the transition because software that understood P2SH could send to it even when it did not yet understand native Bech32 addresses. It carries a wrapper that native SegWit does not need, so it is normally less compact than the equivalent native output.
Native SegWit addresses start with bc1q
Native version-0 SegWit addresses use Bech32, specified by BIP 173. On mainnet they begin with bc1q.
There are two common version-0 programs:
- P2WPKH uses a 20-byte public-key hash
- P2WSH uses a 32-byte script hash
The shared bc1q beginning therefore does not by itself distinguish a single-key P2WPKH output from a script-based P2WSH output. Length and decoding reveal the program type.
BIP 173 designed Bech32 for native witness outputs. It uses a checksummed base-32 character set and forbids mixed-case strings. Encoders produce lowercase addresses. A wallet should reject an address whose case or checksum is invalid rather than trying to repair it.
Native SegWit removes the P2SH wrapper used by nested SegWit. Bitcoin Core’s guide notes that native forms are smaller in virtual size in most comparable cases, which can reduce the fee needed to spend them at the same fee rate. The exact saving still depends on the whole transaction: input count, output count, script type and signatures all matter.
Taproot addresses start with bc1p
Taproot is SegWit version 1. BIP 341 defines a Taproot output as a native version-1 witness program containing 32 bytes. Its mainnet address normally begins with bc1p.
Taproot addresses use Bech32m, not the original Bech32 checksum. BIP 350 keeps Bech32 for witness version 0 and requires Bech32m for witness versions 1 through 16. A decoder must check that the checksum family matches the witness version.
A Taproot output can be spent through a key path or, when configured, a script path. The address does not tell an observer which path will be used. It commits to an output key; the spending data later shows how the coins were unlocked.
Support is the practical constraint. A receiving wallet may offer Taproot while an older exchange or service cannot send to bc1p. If the sending service rejects a valid Taproot address, generate a different supported address in the receiving wallet. Do not edit the address or swap its prefix.
Which address type should you choose?
For a new receive address, follow the receiving wallet’s supported options and the sender’s compatibility:
- Prefer bc1p when the wallet intentionally offers Taproot and the sender supports it.
- Use bc1q for broad native SegWit support.
- Use 3… nested SegWit when a sender accepts P2SH but rejects native SegWit.
- Use 1… only when compatibility requires the legacy format.
This is a compatibility order, not a promise that every Taproot transaction is cheaper than every SegWit transaction. Transaction structure decides the actual size and fee.
If you are coordinating several signers, the address is only the final destination. The signing workflow still needs the right derivation paths, scripts and change checks. Our PSBT guide covers how partially signed transactions move between participants, while Multisig vs MPC wallets explains where an approval rule can live.
Checks to make before sending
An address checksum catches some transcription errors. It cannot tell you whether malware replaced the address, whether the recipient chose the intended wallet, or whether you selected the right network.
Before sending:
- obtain the address through an expected channel
- compare the first and last characters on both devices
- confirm the network in the sending wallet
- let the wallet validate the complete address
- use a small test payment when the amount and operational risk justify it
- wait for the recipient to confirm the test before sending the remainder
- generate a fresh receive address when the wallet supports it
Do not infer ownership from an address visible in a block explorer. A watch-only wallet can track addresses without holding their private keys, as explained in our watch-only wallet guide.
