Bitcoin Address Types Explained

Direct Answer

Compare legacy, nested SegWit, native SegWit and Taproot address formats, prefixes, compatibility and safety limits.

Two Bitcoin addresses can both receive BTC and still create different transaction structures underneath. A mainnet address beginning with 1, one beginning with 3, a bc1q address and a bc1p address can all be valid destinations, but they do not necessarily represent the same script, encoding or future spending condition.

That difference is easy to miss because the wallet presents an address as a single string. Underneath it, the address tells software how to construct a transaction output. Once that output is confirmed, it becomes a UTXO that must later be spent according to the script rules encoded by that output.

The practical question is therefore not simply “Which prefix is newer?” It is whether the address belongs to the intended Bitcoin network, what output type it represents, whether the sending software supports that format, and what the address can—and cannot—tell you before you authorize a payment.

What a Bitcoin Address Represents

A Bitcoin address is not an account in the banking sense. It does not contain bitcoin, hold a private key or provide a complete view of a wallet balance. It is a human-readable encoding that helps a wallet construct a particular transaction output.

The simplified relationship is:

Bitcoin address
        ↓
Address decoding
        ↓
scriptPubKey
        ↓
Transaction output
        ↓
Confirmed UTXO
        ↓
Future spending condition

When you send bitcoin, the wallet does not move an object from one address string to another. It consumes existing UTXOs as transaction inputs and creates new outputs. The destination address provides the information required to build one of those outputs.

This is why an address format matters technically. A P2PKH address leads to a different output script than a P2WPKH address. A Taproot P2TR output is different again. Those outputs can all represent spendable bitcoin, but the conditions and serialization used when they are spent are not identical.

The address is not the private key

The private key remains separate from the address. A wallet uses private-key material to create the signature or witness data required by the spending condition. Publishing a receiving address does not publish the private key.

The reverse is also important: seeing an address does not prove that a particular person controls the corresponding key. Blockchain analysis can observe transactions and outputs, but an address string alone is not identity evidence.

Why Several Formats Exist

Bitcoin has multiple address formats because the transaction system evolved while maintaining compatibility with older outputs. New formats did not replace old outputs on the blockchain. Instead, they introduced additional ways to express spending conditions.

The four formats most users encounter on Bitcoin mainnet are:

• Legacy P2PKH, commonly displayed with an address beginning with 1.
• P2SH, commonly beginning with 3; nested SegWit is one important use of P2SH, but not the only one.
• Native SegWit, encoded with Bech32 and commonly beginning with bc1q for witness version 0.
• Taproot, encoded with Bech32m and beginning with bc1p for witness version 1 P2TR outputs.

The important change is not the appearance of the string. It is what the decoded destination tells the wallet to place in the new output.

Bitcoin Address Types Compared

Common name	Mainnet prefix	Encoding	Typical output	What the prefix tells you
Legacy	1	Base58Check	P2PKH	Version-byte family for a mainnet public-key-hash address
P2SH (including nested SegWit)	3	Base58Check	P2SH; nested SegWit is one possible redeem-script construction	The destination is P2SH, not the exact redeem script inside it
Native SegWit	bc1q	Bech32	Witness v0, commonly P2WPKH or P2WSH	Mainnet Bech32 witness-version-0 destination
Taproot	bc1p	Bech32m	P2TR	Mainnet witness-version-1 Taproot destination

This table is useful for identification, but the prefix is not a complete description of future spending behavior. The clearest example is a 3... address: it identifies P2SH, but P2SH can commit to many redeem scripts. Nested SegWit is only one possibility.

Legacy P2PKH Addresses

Legacy pay-to-public-key-hash, or P2PKH, is the address format most closely associated with early Bitcoin wallet software. On mainnet, these Base58Check addresses normally begin with 1.

The address represents a hash of a public key. When a wallet pays to that destination, it creates a P2PKH locking script that requires a valid signature and the corresponding public key when the output is spent.

OP_DUP
OP_HASH160
<20-byte public-key hash>
OP_EQUALVERIFY
OP_CHECKSIG

The visible address is therefore not the script itself. The wallet decodes the Base58Check address, extracts the version and payload, and constructs the appropriate scriptPubKey.

P2PKH outputs remain valid Bitcoin outputs. “Legacy” does not mean invalid or automatically unsafe. The distinction becomes relevant when comparing transaction structure: spending a traditional P2PKH output places the unlocking data in the input script rather than using SegWit witness serialization.

That difference can increase transaction weight compared with common SegWit key spends. It does not mean a P2PKH payment automatically has a particular fee. Input count, output count, selected fee rate and the rest of the signed transaction still determine the final cost.

P2SH and Nested SegWit

Pay-to-script-hash, or P2SH, moved part of the spending logic behind a hash. Mainnet P2SH addresses use Base58Check and normally begin with 3.

A standard P2SH output places the redeem-script hash in the locking script:

OP_HASH160
<20-byte script hash>
OP_EQUAL

The full redeem script is supplied only when the output is spent. This created an important compatibility tool when SegWit was introduced: a SegWit witness program could be placed inside a P2SH redeem script, allowing a sender that understood ordinary P2SH addresses to pay an output that would later be spent using SegWit rules.

A common single-key construction is called P2SH-P2WPKH:

P2SH address
    ↓
hash of redeemScript
    ↓
redeemScript contains a P2WPKH witness program
    ↓
signature and public key are supplied through witness data when spent

A 3-prefix does not prove SegWit

This is one of the most important limits of visual address identification. An address beginning with 3 tells you that the destination uses the mainnet P2SH address version. It does not reveal the full redeem script before the output is spent.

P2SH existed before SegWit and can wrap other scripts. Treating every 3... address as “a SegWit address” is therefore too broad.

Technical boundary: the prefix identifies the outer address format. It does not prove the exact script hidden behind a P2SH hash.

Native SegWit and bc1q

Native SegWit removes the P2SH compatibility wrapper and represents the witness program directly. BIP 173 introduced Bech32 encoding for native SegWit addresses.

On Bitcoin mainnet, the human-readable part is bc. Witness version 0 produces addresses commonly recognizable by the beginning bc1q.

Two common witness-version-0 outputs are:

• P2WPKH: a 20-byte witness program commonly used for single-key wallet payments.
• P2WSH: a 32-byte witness program that commits to a witness script.

The address itself gives the wallet the witness version and program. For witness version 0, common output scripts have these forms:

P2WPKH: OP_0 <20-byte key hash>
P2WSH:  OP_0 <32-byte script hash>

The output directly contains the witness program instead of a P2SH wrapper. When the UTXO is spent, the signature or script data required by the witness program is supplied in the transaction witness rather than in a traditional P2PKH-style scriptSig.

Bech32 changes error detection too

Bech32 is not merely a different alphabet. It includes a checksum designed for this address family and separates the human-readable network portion from the encoded witness data.

Bech32 strings must not mix uppercase and lowercase characters. Wallets normally display Bitcoin mainnet Bech32 addresses in lowercase. A fully uppercase encoding can be valid under the specification, but mixed case is invalid.

Taproot and bc1p

Taproot introduced pay-to-Taproot, or P2TR, outputs. P2TR uses witness version 1 with a 32-byte witness program. On Bitcoin mainnet, the resulting address begins with bc1p.

Witness version 1 and later use Bech32m rather than the original Bech32 checksum. BIP 350 introduced this change after a weakness was identified in using the original Bech32 checksum behavior for newer witness versions.

This gives a practical identification rule:

bc1q... → witness version 0 → Bech32
bc1p... → witness version 1 P2TR → Bech32m

The corresponding P2TR locking script uses witness version 1 and a 32-byte Taproot output key:

OP_1 <32-byte Taproot output key>

A P2TR output commits to that Taproot output key. It can later be spent through the key path or, if a script tree was committed, through a valid revealed script path.

The address does not reveal which path will eventually be used. Seeing bc1p tells you that the output is P2TR. It does not tell you whether the future spender will use a key-path signature or reveal a script path.

What Bitcoin Prefixes Really Tell You

Prefixes are useful because they let a human quickly identify the likely address family and network. They should be treated as an initial check, not as complete validation.

Example beginning	Likely mainnet meaning	What it does not prove
1...	P2PKH mainnet address	Owner, balance or recipient identity
3...	P2SH mainnet address	That the redeem script is nested SegWit
bc1q...	Native witness-version-0 address	Whether it is P2WPKH or P2WSH by prefix alone
bc1p...	P2TR witness-version-1 address	Which Taproot spending path will later be used

The prefix also cannot authenticate the person who gave you the address. A perfectly encoded, checksum-valid address can still belong to the wrong recipient.

Network Comes Before Address Type

Before choosing between Legacy, SegWit or Taproot, confirm that the address belongs to the Bitcoin network you intend to use.

Bech32-family addresses make this visible through their human-readable part. BIP 173 defines bc for Bitcoin mainnet and tb for Bitcoin testnet addresses. The human-readable part is therefore part of network validation, not decoration.

Base58Check address families also use different version bytes between mainnet and test networks, even though the difference is less obvious to a user who only looks at the string.

A wallet should reject an unsupported network/address combination, but the final responsibility is still to confirm the network shown by the sending application. Address-format recognition is not a substitute for network verification.

For the wider transaction context—inputs, outputs, confirmations and the Bitcoin base layer—use the Bitcoin network reference.

Address Type and Transaction Fees

It is common to hear that a newer Bitcoin address is “cheaper.” That statement is directionally useful in some comparisons, but too simple to use as a fee rule.

The address chosen by a recipient affects the type and serialized size of the output created today. More importantly, when that output is later spent, its script type affects the structure of the corresponding transaction input.

SegWit also changes transaction Weight accounting because witness bytes are weighted differently from non-witness bytes. A common Native SegWit key spend therefore has a different Weight profile from a comparable Legacy P2PKH spend. That affects virtual size when the UTXO is spent, but it still does not fix the total fee in advance.

The same BTC amount can lead to different future costs

Consider two users who each receive the same amount of bitcoin. One receives a P2PKH output and the other receives a P2WPKH output. The value is identical. The future input structure is not.

When those UTXOs are later spent, their unlocking data is serialized differently. That changes transaction Weight and therefore virtual size. At the same sat/vB rate, different vSize means a different total fee.

This is an illustrative technical scenario, not a user transaction record or a claim about a specific wallet.

The address type still does not determine the final fee by itself. A transaction with many efficient SegWit inputs can be larger than one with a single Legacy input. Output count, signatures, script paths and the chosen fee rate also matter.

For the full relationship between Weight, virtual size and sat/vB, read how Bitcoin transaction fees work. When you need a transaction-specific estimate rather than a conceptual comparison, use the Bitcoin Transaction Fee Calculator.

Compatibility Is a Sender Check

A valid Bitcoin address is not useful to a payment workflow if the sending wallet or withdrawal service does not understand the format.

This distinction was especially important during the adoption of Native SegWit and later Taproot. The Bitcoin network could recognize the output type while older applications lacked support for creating that destination.

When a service rejects a bc1q or bc1p address, do not alter the address manually. Do not remove characters, change the prefix or convert it through an arbitrary website. Use an address format that your receiving wallet actually generated and that the sender explicitly supports.

Sending between formats is not conversion

You do not need a Legacy wallet to pay a Legacy address or a Taproot wallet to pay a Taproot address in the sense of matching the source and destination formats. The sending transaction consumes whatever supported UTXOs the wallet selects and creates a new output for the destination script.

The relevant question is whether the sending software can decode and construct the requested destination output.

A Valid Address Can Still Be Wrong

Checksums catch certain transcription errors. They do not authenticate the intended recipient.

If malware replaces a copied address with another valid Bitcoin address, the replacement can pass checksum validation perfectly. The technical format is valid; the destination is wrong.

This is why “the wallet accepted the address” is not the final safety check. Acceptance tells you that the software recognized a valid or supported destination. It does not prove where the address came from.

Verify Before You Send

A useful verification process separates format validation from recipient validation.

1. Confirm the network. Make sure the wallet or service is sending Bitcoin on the intended Bitcoin network rather than another asset or test environment.
2. Read the address family. A 1, 3, bc1q or bc1p prefix gives you an initial format clue.
3. Confirm sender support. The withdrawal service or wallet must explicitly accept the destination format.
4. Verify the destination through a trusted channel. Compare the complete address on a trusted display where practical rather than relying only on a few leading and trailing characters.
5. Review the wallet’s final transaction screen. Confirm the recipient, amount, network fee and any change before signing.
6. Protect private material. Receiving-address verification never requires you to enter a seed phrase or private key into a website.

For large or operationally sensitive transfers, organizations often add independent destination verification procedures. Those procedures are an operational control, not a property of one specific Bitcoin address format.

Address Reuse Is a Separate Issue

A Bitcoin address does not expire at the protocol level simply because it has been used once. If the corresponding spending condition remains controllable, future payments to the same address can still create valid outputs.

That does not make address reuse desirable. Reusing a receiving address can make transactions easier to associate on the public blockchain and can reduce privacy.

This privacy question is separate from whether the address is P2PKH, P2SH, P2WPKH or P2TR. A modern address format does not make repeated use of the same visible destination private.

The Limits of Address Validation

Format validation answers a narrow question: whether the string can be decoded as the expected kind of Bitcoin destination under the relevant address rules. It does not authenticate the person who supplied it, prove ownership of a private key, prove a wallet’s total balance, guarantee that a service supports the format, or determine the final transaction fee.

It also cannot reveal information deliberately hidden by the output construction. A P2SH address does not expose the full redeem script before spending, and a P2TR address does not tell you in advance whether the future spend will use the key path or reveal a script path. Treat successful decoding as one check in the payment process, not as proof that every surrounding assumption is correct.

Choosing a Receiving Format

The safest default is to use an address generated by the wallet you actually control rather than constructing or converting an address manually.

If the receiving wallet offers more than one address type, use the type that matches the wallet’s intended script policy and that the sender can decode. A P2WPKH address is appropriate when the wallet intentionally generates a witness-version-0 key-hash destination. A P2TR address is appropriate when the wallet intentionally generates a Taproot destination and the sender supports it. Older P2PKH or P2SH destinations remain valid when a workflow requires those formats.

Do not select a format solely because someone claims it is “the cheapest.” The output you create today becomes an input only when it is spent later, and the final cost of that future transaction depends on the full transaction structure and fee rate.

The address should come from the receiving wallet. The sender should support it. The network should match. Those three checks matter more than chasing a prefix by itself.

Bitcoin Address FAQ

What is the difference between bc1q and bc1p?

bc1q is commonly the beginning of a Bitcoin mainnet witness-version-0 address encoded with Bech32, such as P2WPKH or P2WSH. bc1p identifies a mainnet witness-version-1 P2TR address encoded with Bech32m.

Does every Bitcoin address beginning with 3 use SegWit?

No. A mainnet address beginning with 3 is a P2SH address. Nested SegWit can use P2SH, but P2SH can commit to other redeem scripts, so the prefix alone does not prove that the output is nested SegWit.

Are Bitcoin addresses case sensitive?

Base58Check addresses use a case-sensitive alphabet. Bech32 and Bech32m encodings must not mix upper- and lowercase characters; Bitcoin wallets normally display them in lowercase. Do not change the case of an address manually.

Can I send Bitcoin from one address type to another?

Yes, when the sending wallet supports the destination format. A transaction can spend one supported input type and create a different supported output type. Source and destination prefixes do not have to match.

Does a Bitcoin address expire?

No protocol rule makes a normal Bitcoin address expire after a set date or after one payment. Wallets often generate new receiving addresses because address reuse can reduce privacy, not because previously generated addresses automatically become invalid.

Which Bitcoin address type should I use?

Use an address generated by the receiving wallet for the Bitcoin network and script type you intend to use, then confirm that the sender supports that format. Native SegWit is common for modern payments, while Taproot is appropriate when both sides support P2TR. Do not manually transform one address format into another.

Technical Sources

The address-format descriptions above are based on Bitcoin Improvement Proposals and Bitcoin Core documentation. These references define address encodings, witness programs and script behavior; they do not prove the identity or safety of a specific receiving address. BitcoinToolkit’s broader sourcing approach is described on the Data Sources page.

• BIP 13: Address Format for pay-to-script-hash — specifies the Base58Check P2SH address format.
• BIP 16: Pay to Script Hash — defines the P2SH spending model and redeem-script evaluation.
• BIP 49: Derivation scheme for P2WPKH-nested-in-P2SH — documents the common single-key nested-SegWit construction discussed in this guide.
• BIP 141: Segregated Witness — defines witness programs, transaction Weight and SegWit output semantics.
• BIP 173: Base32 address format for native v0-16 witness outputs — introduced Bech32 native SegWit address encoding.
• BIP 350: Bech32m format for v1+ witness addresses — defines Bech32m and the checksum rule for newer witness versions.
• BIP 341: Taproot — defines Taproot output and spending rules, including P2TR witness version 1.
• Bitcoin Core Output Descriptors — documents structured descriptions of common Bitcoin output scripts and key expressions.

Sources

1. BIP 13: P2SH address format
2. BIP 141: Segregated Witness
3. BIP 173: Bech32 native SegWit addresses
4. BIP 350: Bech32m
5. BIP 341: Taproot
6. Bitcoin Core output descriptors

Found an error? Report a content issue or read our Corrections Policy.