When building decentralized applications using Bitcoin-based tools, one of the foundational concepts you'll encounter is Bitcoin address formats. Whether you're integrating Ordinals, setting up Chainhook predicates, or using Clarity smart contracts to verify transactions, understanding how Bitcoin addresses work—and why they come in different forms—is essential for robust and future-proof development.
You may have noticed that Bitcoin addresses don’t all look the same. Some start with “1”, others with “3” or “bc1q”, and a newer type even begins with “bc1p”. These variations aren’t random—they reflect distinct script types, encoding methods, and network upgrades that have shaped Bitcoin’s evolution.
In this guide, we’ll break down the four primary Bitcoin address formats in use today: Legacy (P2PKH), Nested SegWit (P2SH), Native SegWit (P2WPKH), and Taproot (P2TR). We’ll explain what each one means, how they differ technically, and which use cases call for which format.
What Is a Bitcoin Address?
A Bitcoin address is a public identifier used to receive funds on the Bitcoin network. Think of it like an email address—you share it freely so others can send you Bitcoin.
Technically, every Bitcoin address is derived from a public key hash, tied to a specific script type that defines how the funds can be spent. The address also includes:
- A version prefix indicating the network and format,
- An encoding scheme (like Base58 or Bech32),
- And a checksum to prevent errors during transactions.
While all addresses serve the same basic purpose, their underlying structures vary significantly based on when and how they were created. This leads us to the different formats now in circulation.
The Four Main Bitcoin Address Formats
Legacy (P2PKH) – The Original Standard
Example: 12rYgz414HBXdhhK72BkR9VHZSU23dqqG7
Legacy addresses, also known as Pay-to-Public-Key-Hash (P2PKH), were among the first widely adopted formats. They begin with a "1" and use Base58 encoding with a version byte and checksum.
These addresses are derived by hashing a public key using SHA-256 followed by RIPEMD-160 (a process called Hash160). The result is then encoded into a human-readable string.
Legacy addresses were commonly used during the early days of Bitcoin.
Though outdated in terms of efficiency, P2PKH remains fully supported across wallets and services. Many long-term holders still use these addresses, so compatibility is important—even if you're building modern apps.
👉 Discover how to handle legacy address support in your app development workflow.
Native SegWit (P2WPKH) – Efficient and Modern
Example: bc1qhrnucvul769yld6q09m8skwkp6zrecxhc00jcw
Native SegWit (Pay-to-Witness-Public-Key-Hash) addresses emerged from the 2017 Segregated Witness (SegWit) upgrade. They start with "bc1q" and use Bech32 encoding, defined in BIP173.
SegWit improved Bitcoin by moving signature data (ScriptSig) out of the main transaction block and into a separate “witness” field. This change:
- Reduced transaction size,
- Lowered fees,
- Fixed transaction malleability issues,
- Enabled advanced features like the Lightning Network.
Bech32 encoding makes Native SegWit more efficient and error-resistant than Base58. QR codes are smaller, checksums are faster, and overall block space usage is optimized.
Native SegWit addresses are now the most common address type you'll see in wallets today.
Additionally, SegWit introduced P2WSH (Pay-to-Witness-Script-Hash), used for complex scripts like multisig and payment channels—core components of Layer 2 scaling solutions.
Nested SegWit (P2SH-P2WPKH) – Bridging Old and New
Example: 3BY19nUKCAkrnzrgRezJoekGv4AFzsTs2z
Nested SegWit addresses begin with "3" and appear identical to older Pay-to-Script-Hash (P2SH) addresses. However, they wrap a SegWit-compatible script inside a traditional P2SH container.
This design allowed early adoption of SegWit while maintaining backward compatibility with wallets that didn’t yet support native Bech32 addresses.
The flexibility of arbitrary scripts allows for the construction of complex transactions to secure your bitcoin in various ways.
For example, exchanges and older wallets could adopt SegWit benefits—like lower fees—without requiring full infrastructure overhauls. Today, many platforms still generate these addresses by default due to broad compatibility.
A key caveat: not all "3" addresses are SegWit. Some are legacy multisig scripts. Developers must inspect output scripts to determine actual format.
Taproot (P2TR) – The Future of Bitcoin
Example: bc1p5d7rjq7g6r4jdyhzks9smlaqtedr4dekq08ge8ztwac72sfr9rusxg3297
Taproot addresses, introduced in 2021 via a soft fork, use Bech32m encoding (an improvement over Bech32) and start with "bc1p". They correspond to the Pay-to-Taproot (P2TR) script type.
Taproot brought major upgrades:
- Enhanced privacy through Schnorr signatures,
- More efficient smart contract execution,
- Support for complex scripts without revealing them on-chain unless spent.
Taproot addresses support Bitcoin Ordinals, BRC-20 tokens, and Runes.
This makes Taproot essential for developers building apps around digital collectibles, inscriptions, or token protocols on Bitcoin. Unlike previous formats, Taproot enables rich functionality while preserving simplicity and low cost.
Because Native SegWit’s Bech32 had limitations for future script versions, Bech32m was introduced to avoid conflicts—ensuring forward compatibility.
👉 Learn how to integrate Taproot support for Ordinals and BRC-20 token handling.
Why Are There Multiple Address Formats?
Bitcoin’s development prioritizes security and decentralization over rapid change—but evolution still happens. Each new address format addressed real-world constraints:
| Format | Key Improvement |
|---|---|
| Legacy | Introduced public key hashing for security |
| Nested SegWit | Enabled SegWit adoption without breaking old systems |
| Native SegWit | Reduced fees and enabled Layer 2 networks |
| Taproot | Enhanced privacy, scalability, and scripting power |
Transaction sizes illustrate this progression clearly:
- Legacy: ~192 vbytes
- Nested SegWit: ~134 vbytes
- Native SegWit: ~110 vbytes
- Taproot: ~112 vbytes
Smaller transactions mean lower fees—critical during network congestion. As complexity increases (e.g., multisig or smart contracts), these savings compound significantly.
Do Wallets Use Different Address Formats?
Yes—wallets choose formats based on functionality, timing, and ecosystem needs.
For example:
- Leather Wallet uses Native SegWit (
bc1q) for efficiency. - Xverse Wallet uses Nested SegWit (
3...) because earlier versions of Stacks protocol didn’t support Native SegWit for stacking rewards.
As a developer, you must account for this diversity. Your app should be able to parse, validate, and interact with all major address types—not just the ones currently popular.
Tools like Chainhook from Hiro enable event indexing across all four formats, ensuring your app stays resilient regardless of user wallet choice.
Frequently Asked Questions
Q: Can I send Bitcoin from any address format to any other?
A: Yes. All Bitcoin address formats are interoperable. You can send from a Legacy address to a Taproot address without issue—the network handles the routing.
Q: Which address format should I use in my new app?
A: For receiving payments, Native SegWit (P2WPKH) offers the best balance of low fees and wide support. If you’re working with Ordinals or BRC-20s, Taproot (P2TR) is required.
Q: Are older address formats unsafe?
A: No. Legacy and Nested SegWit are still secure and fully supported. However, they incur higher fees and lack modern features like improved privacy or script efficiency.
Q: How can I detect what type of address I'm dealing with?
A: Check the prefix:
- Starts with
1→ Legacy (P2PKH) - Starts with
3→ Likely Nested SegWit (P2SH-P2WPKH) - Starts with
bc1q→ Native SegWit (P2WPKH) - Starts with
bc1p→ Taproot (P2TR)
For certainty, analyze the output script rather than relying solely on format.
Q: Does supporting multiple formats complicate development?
A: Slightly—but libraries like bitcoinjs-lib or Hiro’s stacks.js abstract much of the complexity. Focus on correct parsing and transaction construction.
Final Thoughts
Understanding Bitcoin address formats isn’t just about recognizing prefixes—it’s about grasping how Bitcoin has evolved to support greater efficiency, privacy, and functionality.
Whether you're building a wallet, indexing blockchain events, or launching a new token standard, choosing the right address format—or supporting multiple ones—is crucial for user experience and long-term viability.
As Bitcoin continues to grow beyond simple payments into areas like digital assets and smart contracts, staying informed about these foundational elements will keep your applications ahead of the curve.
👉 Start building with full format compatibility—explore tools that simplify Bitcoin integration today.