Bitcoin Address Type Decoder: Identify Any Address Format
Decode any Bitcoin address to identify its type (P2PKH, P2SH, P2WPKH, P2TR), network, encoding format, and fee savings vs Legacy.
How to Decode a Bitcoin Address
Every Bitcoin address encodes specific information about the spending conditions required to move funds. By examining an address's prefix, length, and character set, you can determine its type (P2PKH, P2SH, P2WPKH, P2WSH, or P2TR), the network it belongs to (mainnet, testnet, signet, or regtest), and the encoding format used to represent it.
This reference covers every Bitcoin address type in active use today: from the original Legacy format introduced in 2009 to Taproot addresses activated in November 2021. For each type, you will find the prefix, byte structure, encoding scheme, and estimated fee savings compared to Legacy addresses.
Address Type Reference
The following table summarizes all standard Bitcoin address types. Each type corresponds to a different output script that defines how the recipient can spend received funds.
| Address Type | Mainnet Prefix | Encoding | Witness Version | Payload | BIP |
|---|---|---|---|---|---|
| P2PKH (Legacy) | 1 | Base58Check | N/A | 20-byte pubkey hash | BIP 13 |
| P2SH (Script Hash) | 3 | Base58Check | N/A | 20-byte script hash | BIP 16 |
| P2WPKH (Native SegWit) | bc1q | Bech32 | 0 | 20-byte pubkey hash | BIP 141/173 |
| P2WSH (SegWit Script) | bc1q | Bech32 | 0 | 32-byte script hash | BIP 141/173 |
| P2TR (Taproot) | bc1p | Bech32m | 1 | 32-byte tweaked pubkey | BIP 341/350 |
P2WPKH and P2WSH share the same bc1q prefix but differ in length: P2WPKH addresses are exactly 42 characters, while P2WSH addresses are 62 characters. P2TR addresses are also 62 characters but use the distinct bc1p prefix. For a full guide to each format, see our Bitcoin address format guide.
Encoding Formats Explained
Bitcoin uses three address encoding schemes. The encoding determines the character set, error detection capability, and which address types it can represent.
Base58Check
Base58Check is the original encoding used by P2PKH and P2SH addresses. It uses a 58-character alphabet that excludes visually ambiguous characters (0, O, I, l) to reduce transcription errors. The encoded payload consists of a 1-byte version prefix, a 20-byte hash, and a 4-byte checksum derived from double-SHA-256 hashing the version and payload bytes. This gives 32 bits of error detection.
Bech32 (BIP 173)
Bech32 was introduced in 2017 for SegWit version 0 addresses (P2WPKH and P2WSH). It uses a 32-character lowercase alphanumeric set and a BCH error-correcting code with a 6-character checksum that can detect up to 4 character errors. The format consists of a human-readable part (HRP), a separator (1), a witness version character, the data payload, and the checksum. For mainnet, the HRP is bc, making the full prefix bc1q where q encodes witness version 0.
Bech32m (BIP 350)
Bech32m was introduced in 2021 to fix a length-extension weakness in original Bech32. It is used for all witness versions 1 and above, which currently means Taproot (P2TR) addresses. The structure is identical to Bech32 except for a modified checksum constant (0x2bc830a3 instead of 1). The mainnet prefix is bc1p, where p encodes witness version 1.
Network Identification by Prefix
You can identify which network an address belongs to by examining its prefix. Testnet and signet share the same address prefixes for all types, so they are distinguishable only at the protocol level, not from the address itself. Regtest shares Base58 prefixes with testnet but has a distinct Bech32 HRP.
| Prefix | Network | Address Type | Encoding | Length |
|---|---|---|---|---|
1... | Mainnet | P2PKH | Base58Check | 25-34 chars |
3... | Mainnet | P2SH | Base58Check | 34 chars |
bc1q... | Mainnet | P2WPKH | Bech32 | 42 chars |
bc1q... | Mainnet | P2WSH | Bech32 | 62 chars |
bc1p... | Mainnet | P2TR | Bech32m | 62 chars |
m... / n... | Testnet / Signet | P2PKH | Base58Check | 25-34 chars |
2... | Testnet / Signet | P2SH | Base58Check | 34 chars |
tb1q... | Testnet / Signet | P2WPKH / P2WSH | Bech32 | 42 or 62 chars |
tb1p... | Testnet / Signet | P2TR | Bech32m | 62 chars |
bcrt1q... | Regtest | P2WPKH / P2WSH | Bech32 | 44 or 64 chars |
bcrt1p... | Regtest | P2TR | Bech32m | 64 chars |
Byte Structure Breakdown
Understanding the raw byte layout of each address type is essential for wallet developers and anyone building Bitcoin Script tooling.
Base58Check Structure (P2PKH, P2SH)
Base58Check addresses encode exactly 25 bytes before Base58 conversion:
- 1-byte version prefix:
0x00for mainnet P2PKH,0x05for mainnet P2SH,0x6ffor testnet P2PKH,0xc4for testnet P2SH - 20-byte hash payload: RIPEMD-160(SHA-256(public key)) for P2PKH, or RIPEMD-160(SHA-256(redeem script)) for P2SH
- 4-byte checksum: first 4 bytes of SHA-256(SHA-256(version + payload))
For nested SegWit (P2SH-P2WPKH), the redeem script is OP_0 <20-byte-pubkey-hash>, which wraps a SegWit witness program inside P2SH for backward compatibility with older wallets.
Bech32/Bech32m Structure (P2WPKH, P2WSH, P2TR)
Bech32 and Bech32m addresses have a fixed structure:
- Human-readable part (HRP):
bcfor mainnet,tbfor testnet/signet,bcrtfor regtest - Separator: the character
1 - Witness version: 1 character encoding the version number (
q= 0,p= 1) - Data payload: 20 bytes for P2WPKH, 32 bytes for P2WSH and P2TR
- Checksum: 6 characters (30-bit BCH error-detection code)
The P2TR payload is an x-only Schnorr public key (tweaked), not a hash. This means Taproot addresses commit directly to a public key rather than a hash of one, which enables key-path spending without revealing any script.
Fee Savings by Address Type
Different address types produce different transaction sizes when spending, directly affecting the fee rate you pay. The SegWit witness discount weighs witness data (signatures) at one quarter the cost of non-witness data: 1 weight unit per byte instead of 4. This is why newer address types cost significantly less to spend from.
| Address Type | Input Size (vbytes) | 1-in-2-out Tx (vbytes) | Savings vs P2PKH |
|---|---|---|---|
| P2PKH (Legacy) | ~148 vB | ~226 vB | Baseline (0%) |
| P2SH-P2WPKH (Nested SegWit) | ~91 vB | ~166 vB | ~27% |
| P2WPKH (Native SegWit) | ~68 vB | ~141 vB | ~38% |
| P2TR (Taproot key-path) | ~57.5 vB | ~132 vB | ~42% |
Taproot's additional savings come from fixed-size 64-byte Schnorr signatures (versus ECDSA's variable 71-73 bytes) and the fact that key-path spends do not require a separate public key in the witness. For multi-input transactions, the savings compound: a 10-input P2TR transaction saves roughly 900 vbytes compared to P2PKH. Use our SegWit savings estimator to calculate exact savings for your transaction profile.
For a deeper technical analysis of Taproot spend paths and their fee implications, see our research on P2TR spend path mechanics.
How to Identify Any Bitcoin Address
Follow this decision tree to decode any Bitcoin address:
- Check the first character. If it starts with
1, it is a mainnet P2PKH (Legacy) address. If it starts with3, it is a mainnet P2SH address (possibly nested SegWit). - If it starts with
bc1q, check the length. 42 characters indicates P2WPKH (Native SegWit). 62 characters indicates P2WSH (SegWit script hash). - If it starts with
bc1p, it is a P2TR (Taproot) address. It will always be 62 characters. - If it starts with
m,n, or2, it is a testnet or signet Base58Check address. - If it starts with
tb1, it is a testnet or signet Bech32/Bech32m address. Check the fourth character:qfor witness v0,pfor Taproot. - If it starts with
bcrt1, it is a regtest address.
A 3-prefixed address does not tell you whether it is a plain P2SH (e.g., multisig) or a nested SegWit (P2SH-P2WPKH) address. The redeem script is only revealed when the output is spent, so this distinction is not decodable from the address alone.
Adoption and Migration
As of mid-2026, approximately 85-90% of Bitcoin transactions include at least one SegWit input. Native SegWit (bc1q) is the default format for most major wallets, exchanges, and payment processors. Taproot (bc1p) accounts for roughly 15-20% of transaction activity, having settled from a peak above 40% in early 2024 driven by Ordinals and Runes inscriptions.
Legacy P2PKH addresses still account for much of the remaining non-SegWit activity, primarily from old unspent UTXOs and services that have not upgraded. If you are still receiving to 1-prefixed addresses, migrating to P2WPKH or P2TR will reduce your transaction fees by 38-42%. For a comprehensive overview of the evolution from Legacy to Taproot, see our research on Bitcoin address types from P2PKH to Taproot.
Layer 2 protocols like Spark build on top of these address types. Spark uses Taproot (P2TR) outputs under the hood to enable instant, low-cost Bitcoin and stablecoin transfers while inheriting the privacy benefits of Taproot's uniform key-path spends.
Frequently Asked Questions
What type of Bitcoin address starts with bc1q?
An address starting with bc1q is a Native SegWit address on mainnet. If it is 42 characters long, it is a P2WPKH (pay-to-witness-public-key-hash) address for single-key spending. If it is 62 characters long, it is a P2WSH (pay-to-witness-script-hash) address used for multisig or complex scripts. Both use Bech32 encoding as defined in BIP 173.
What is the difference between bc1q and bc1p addresses?
Both are mainnet Bech32-family addresses, but they differ in witness version and encoding. bc1q addresses are SegWit version 0 (P2WPKH or P2WSH) using Bech32 encoding. bc1p addresses are SegWit version 1 (Taproot/P2TR) using Bech32m encoding. Taproot addresses offer slightly lower fees due to 64-byte Schnorr signatures and improved privacy since key-path spends look identical regardless of the underlying spending conditions.
How can I tell if a Bitcoin address is mainnet or testnet?
Mainnet addresses start with 1 (P2PKH), 3 (P2SH), bc1q (SegWit v0), or bc1p (Taproot). Testnet and signet addresses start with m or n (P2PKH), 2 (P2SH), tb1q (SegWit v0), or tb1p (Taproot). Regtest uses the same Base58 prefixes as testnet but a distinct Bech32 HRP of bcrt. Testnet and signet share identical address prefixes and can only be distinguished at the protocol level.
Can I tell if a 3-address is multisig or nested SegWit?
No. A 3-prefixed P2SH address hashes the redeem script, so the spending conditions are opaque until the output is spent. A 3-address could be a traditional multisig, a nested SegWit (P2SH-P2WPKH) wrapper, or any other script. You can only determine the actual script type by examining the spending transaction's input data on a block explorer.
Why does Taproot use Bech32m instead of Bech32?
Original Bech32 (BIP 173) has a known weakness: inserting or removing q characters before a trailing p does not invalidate the checksum. For witness version 0 addresses, this is harmless because P2WPKH and P2WSH have fixed lengths. But future witness versions might allow variable-length programs, making this mutation dangerous. Bech32m (BIP 350) uses a different checksum constant (0x2bc830a3) that eliminates this weakness, ensuring safe encoding for witness version 1 and all future versions.
How much can I save by switching from Legacy to SegWit?
Switching from P2PKH to Native SegWit (P2WPKH) saves approximately 38% on transaction fees for a standard 1-input-2-output transaction. Switching to Taproot (P2TR) saves approximately 42%. The savings come from the witness discount, which weighs signature data at one quarter the cost of regular transaction data. For wallets with many UTXOs, the savings are even larger because the discount applies to each input's signature. Use our transaction fee savings calculator to estimate your savings based on your typical transaction profile.
What is a witness program?
A witness program is the data payload inside a SegWit output script. It consists of a version byte (0 for SegWit v0, 1 for Taproot) and a data push of 2 to 40 bytes. For P2WPKH, the witness program is a 20-byte public key hash. For P2WSH, it is a 32-byte script hash. For P2TR, it is a 32-byte x-only tweaked public key. The witness version determines which validation rules Bitcoin nodes apply when the output is spent.
This tool is for informational purposes only and does not constitute financial advice. Transaction sizes are approximate single-signature estimates based on publicly documented standards. Actual sizes vary with signature length, number of inputs/outputs, and script complexity. Always verify address types before sending funds.
Build with Spark
Integrate bitcoin, Lightning, and stablecoins into your app with a few lines of code.
Read the docs →
