What Is a Bech32 Address?

Introduction

Bech32 addresses are the address format Bitcoin introduced for native SegWit outputs. They look different from older Bitcoin addresses for a reason: the design is trying to solve two practical problems at once. First, an address is something humans and software copy, paste, scan, display, and sometimes type by hand, so it needs strong error detection. Second, SegWit changed the underlying output format on-chain, so Bitcoin needed an address encoding that represented those outputs cleanly instead of wrapping them in older conventions.

If you have mostly seen Bitcoin addresses that start with 1 or 3, Bech32 is the family that usually starts with bc1 on mainnet and tb1 on testnet. That visible prefix is not cosmetic. It tells both people and software what network the address belongs to, and it is part of the checksum design. The rest of the format is also highly deliberate: only a restricted alphabet is allowed, mixed case is forbidden, and the last six characters are checksum only.

The key idea is simple: a Bech32 address is not the payment rule itself; it is a safer human-facing encoding of a SegWit witness version and witness program. Once that clicks, the rest of the structure makes sense. The address is a packaging layer around data that will eventually become a scriptPubKey on-chain. The packaging is optimized for transmission accuracy, not for cryptographic secrecy or compactness at all costs.

Bech32 also sits at an important transition point in Bitcoin wallet design. It was created for native SegWit version 0 outputs, and later experience showed that the original checksum design had a weakness for certain insertion and deletion patterns. That did not make Bech32 useless, but it did matter enough that Bitcoin later adopted Bech32m for SegWit version 1 and higher, while keeping original Bech32 for version 0. So when people casually say “Bech32 address,” they often mean a broader family of modern SegWit-style addresses, but the exact checksum variant depends on the witness version.

Why did Bitcoin adopt a new address format for SegWit?

Older Bitcoin addresses were designed around older script types. A legacy pay-to-public-key-hash address encodes a hash of a public key using Base58Check and typically starts with 1. A pay-to-script-hash address typically starts with 3. Those formats worked, but they carried compromises. Their character set was not especially well suited to high-reliability human transcription, and more importantly, they did not map naturally onto native SegWit outputs.

When SegWit arrived, wallet developers had two ways to expose it to users. They could wrap SegWit inside older address conventions, producing addresses that still looked like the old world, or they could expose SegWit natively. Wrapped SegWit helped compatibility, but it preserved extra structure that existed mainly for old software. Native SegWit removed that wrapper. On-chain, that means a cleaner output form such as OP_0 followed by a 20-byte key hash for P2WPKH, or OP_0 followed by a 32-byte script hash for P2WSH.

That cleaner on-chain structure created a user-interface problem: how should wallets represent it as an address string? Reusing the old address encoding would have blurred important distinctions and missed the chance to improve error detection. Bech32 was the answer defined in BIP-173: a checksummed base32 format for native SegWit addresses.

There is also a fee consequence hiding inside that encoding decision. Native SegWit outputs generally produce smaller virtual transaction sizes than their P2SH-wrapped equivalents, so they often cost less to spend. That means the address format is not merely visual. If a wallet gives out native SegWit Bech32 receive addresses, it is steering future spending toward a more efficient transaction form. In practice, that is one of the main reasons users encounter Bech32 at all.

How does a Bech32 address encode witness version and witness program?

A useful way to think about an address is as a lossless translation layer between human-facing text and script-facing bytes. In the SegWit case, the underlying payload has two parts: a witness version and a witness program.

The witness version is a small integer in the range 0 through 16. The witness program is a byte string between 2 and 40 bytes long. For version 0, Bitcoin applies stricter rules: the program must be exactly 20 bytes for P2WPKH or exactly 32 bytes for P2WSH. Those are not arbitrary wallet preferences; they are part of the validation rules for SegWit addresses.

A Bech32 SegWit address takes that witness data and turns it into text in a very specific way. The human-readable part is bc for Bitcoin mainnet and tb for testnet. After that comes the separator character 1. Then comes the data part: first a single 5-bit value for the witness version, then the witness program converted from ordinary 8-bit bytes into 5-bit groups, and finally six checksum characters.

That “converted into 5-bit groups” step is why the format uses a 32-character alphabet. A 5-bit value can represent 2^5 = 32 possibilities, so each output character carries one 5-bit chunk. This is the core reason the format is called “Bech32”: it is using a base-32 alphabet with a checksum scheme designed around that structure.

The important consequence is that the address is not storing a public key or script directly in text form. It is storing a versioned witness program in an encoding chosen for robust transport. When wallet software decodes the address, it reconstructs the witness version and program, verifies they obey the version-specific length rules, and then derives the corresponding scriptPubKey.

What are the HRP, separator, data, and checksum parts of Bech32?

Every Bech32 string has three structural pieces. The first is the human-readable part, often abbreviated HRP. In Bitcoin addresses this is usually bc or tb, but the Bech32 format itself is more general and allows other registered prefixes on other networks. The HRP must be between 1 and 83 printable ASCII characters. Its job is to provide context before any decoding happens.

Then comes the separator, always the character 1. This is the boundary between context and payload. The choice is practical: the separator should be easy to spot, and since 1 is not allowed in the data alphabet, it cannot be confused with payload characters.

After the separator comes the data part. The allowed character set is:

qpzry9x8gf2tvdw0s3jn54khce6mua7l

This alphabet was chosen to support the checksum and to avoid some of the most easily confused characters. In particular, Bech32 excludes 1, b, i, and o from the data part. The last six characters of the data part are the checksum. They do not carry payload information.

A full Bech32 string must be at most 90 characters long. It must be all lowercase or all uppercase; mixed case is invalid. In practice, encoders are expected to produce lowercase. That is why modern Bitcoin receive addresses are typically shown as lowercase bc1... strings.

The subtle but important design choice here is that the HRP participates in checksum computation. So bc1... and tb1... are not just different labels pasted onto the same payload. Changing the network prefix without recomputing the checksum makes the string invalid. This reduces the risk that an address is accidentally moved from one network context to another.

Why does Bech32 use a six-character checksum and how does it protect funds?

Addresses are dangerous strings. If you mistype a website password, the server rejects it. If you mistype a cryptocurrency address and the result still happens to be valid, funds may be sent irreversibly to the wrong destination. So the format’s real safety story is not “it is modern” but it is designed to detect likely human and software errors before money moves.

Bech32’s checksum is based on a BCH-like polymod construction. You do not need the polynomial details to understand the purpose. The format processes the expanded HRP and the data values through a specific remainder calculation, then chooses six checksum characters so that the overall result matches a target constant. On decode, software repeats the calculation. If the remainder is wrong, the address is invalid.

What does this buy you in practice? BIP-173 states that the checksum guarantees detection of any error affecting at most four characters, and for more complicated errors the chance of an undetected failure is less than 1 in 10^9. That is the kind of property address formats need: not cryptographic collision resistance in the abstract, but strong detection of the ways humans actually damage strings.

There is also a usability boundary here. Because some invalid strings can be close to a valid one, implementations are explicitly warned not to do automatic error correction that silently changes an invalid input into a valid address. That might sound helpful, but it is dangerous. If software “fixes” an address into the wrong valid destination, the checksum has not saved the user; the wallet has overridden the user’s intent. At most, implementations may indicate where an error seems to be located without proposing a concrete correction.

Bitcoin Core’s implementation follows that philosophy. It contains logic that can help locate likely error positions, but it intentionally does not return a guessed corrected value to use automatically. That distinction matters. Error detection is good. Error correction is risky unless the system has much stronger guarantees than a user-entered payment address usually provides.

How is a bc1... Bech32 string turned into an on-chain SegWit output?

Suppose Alice’s wallet shows her a receive address beginning with bc1q... . Bob pastes it into his wallet to send her bitcoin. What happens mechanically is more interesting than the text suggests.

Bob’s wallet first checks that the string is structurally Bech32: printable characters only, no mixed case, a valid separator position, permitted data alphabet, overall length within the maximum, and a passing checksum. If any of those checks fail, the wallet should reject the address before even considering payment.

Next, the wallet reads the HRP. If Bob is sending on Bitcoin mainnet, it expects bc. If he pasted a testnet address with tb, the wallet should reject it as the wrong network. This is one reason the HRP is not decorative.

Then the wallet decodes the data part. The first 5-bit value becomes the witness version. In an address beginning bc1q..., that initial q often corresponds to version 0, which is why many native SegWit version 0 addresses start that way. The remaining data is converted from 5-bit groups back into bytes, recovering the witness program.

If the witness version is 0, the wallet checks that the recovered program is either 20 or 32 bytes. If it is 20 bytes, the address corresponds to a native P2WPKH output. The wallet then constructs the output script as OP_0 plus a push of that 20-byte program. If it is 32 bytes, it constructs a native P2WSH output instead.

Notice what the wallet never needed to do: it did not need to guess what type of output this was from a legacy prefix convention, and it did not need a wrapper script. The address decodes directly into the witness version and program that define the spending conditions on-chain. That directness is the main conceptual improvement.

What’s the difference between Bech32 and Bech32m and when is each used?

At this point the obvious question is: if Bech32 was the right design, why did Bitcoin later introduce Bech32m?

The answer is not that Bech32 failed at its main job. For native SegWit version 0 outputs, it remains the specified format. The issue was narrower and more technical: later analysis uncovered an insertion/deletion weakness in the original checksum design. BIP-173 itself now notes that the checksum is not always robust against insertion or deletion of fewer than five consecutive characters. BIP-350 addressed this by defining Bech32m, which keeps the overall format and polymod machinery but changes the final checksum constant from 1 to 0x2bc830a3.

That sounds like a tiny patch, but it has a precise effect. The original Bech32 checksum had a mutation class that could survive certain length-extension style edits. Bech32m changes the target remainder so those simple mutations no longer preserve validity in the same way. The surrounding format stays the same: same HRP rules, same character set, same separator, same base conversion, same six-character checksum length. The difference is the final constant used when verifying the polymod result.

The version mapping is crucial. **SegWit version 0 addresses use Bech32. SegWit version 1 and later use Bech32m. ** Wallets therefore need decoders that can recognize both checksum variants and then enforce that the checksum type matches the decoded witness version. A valid-looking address with the wrong pairing is not acceptable.

This is why Taproot addresses, which are SegWit version 1, use Bech32m rather than original Bech32. The ecosystem deliberately accepted some forward-compatibility breakage for v1+ outputs in order to avoid carrying the old checksum weakness into future witness versions.

How do wallets and users use Bech32 addresses in practice?

In everyday Bitcoin use, Bech32 mostly appears when a wallet gives out a receive address for a native SegWit account. For a single-key wallet following BIP-84 conventions, that usually means native P2WPKH receive addresses. For more complex scripts, it may mean native P2WSH. For Taproot single-key outputs under BIP-86, the visible address still looks like the same broader family, but under the hood it is Bech32m because the witness version is 1.

This matters operationally because address format influences compatibility, fees, and wallet workflow. A wallet that can receive to Bech32 but cannot send to all Bech32 output types is only partially compatible. Community tracking such as the Bitcoin Optech feature matrix exists precisely because “supports Bech32” can mean several different things unless you specify whether you mean sending, receiving, P2WPKH, P2WSH, or Bech32m/Taproot support.

Developers also encounter Bech32 in libraries and hardware wallet APIs. Reference implementations exist in multiple languages, and major libraries expose address creation and validation that select Bech32 for witness version 0 and Bech32m for higher versions. Hardware wallets add another layer: they often derive the address from a path and script type, display it on-device, and ask the user to confirm that the host software and the device agree. That on-device confirmation does not change Bech32’s checksum rules, but it helps defend against malware that replaces addresses in the host environment.

There is an important human factor here. Even with a strong checksum, a user who only glances at the first and last few characters of an address can still be vulnerable to clipboard replacement or lookalike attacks. Bech32 improves transcription safety; it does not eliminate the need to verify the full destination, especially when the address is shown on a trusted hardware device.

What can go wrong if Bech32 validation or usage assumptions change?

Bech32 depends on a few assumptions that are easy to miss if you only see the address as text.

The first assumption is that software validates strictly. A decoder should reject mixed case, invalid characters, impossible lengths, checksum failures, wrong HRP, invalid witness versions, invalid witness program lengths, and wrong checksum variant for the witness version. If any of those checks are relaxed, the format’s safety margin shrinks.

The second assumption is that users and interfaces treat addresses as exact data, not fuzzy strings. That is why auto-correct is discouraged. It is also why QR scanning and copy-paste are usually safer than manual re-entry, even though the checksum helps with both.

The third assumption is version awareness. If software supports only original Bech32 and not Bech32m, it may mishandle Taproot-era addresses. Conversely, accepting both checksum types indiscriminately for the same witness version would weaken error detection. BIP-350 explicitly avoids that: version 0 remains Bech32-only, and version 1+ is Bech32m-only.

There are also privacy and compatibility tradeoffs around when wallets choose native SegWit addresses by default. Native outputs are more efficient, but when adoption was uneven, using them in some contexts could make wallet behavior more identifiable. That is not a flaw in Bech32’s checksum design; it is a reminder that address formats live inside a broader wallet and network environment.

Finally, Bech32 is not a universal blockchain address standard. The general encoding format can be used outside Bitcoin with different HRPs, and some ecosystems have adopted Bech32-style prefixes for their own reasons. But when people say “Bech32 address” in wallet discussions, they are usually talking about Bitcoin native SegWit addresses specifically. The meaning comes from the combination of the text encoding and the SegWit address rules, not from the character set alone.

What is the concise technical summary of how a Bech32 SegWit address works?

If you want the shortest rigorous summary of how a Bitcoin Bech32-style address works, it is this.

A valid native SegWit address consists of an HRP such as bc or tb, the separator 1, and a data part drawn from a fixed 32-character alphabet. The data part contains a witness version encoded as one 5-bit value, followed by the witness program converted from 8-bit bytes to 5-bit groups, followed by six checksum characters. The checksum is verified by computing a polymod over the HRP expansion and data. For version 0, the checksum constant must be Bech32’s 1; for version 1 and above, it must be Bech32m’s 0x2bc830a3. After decoding, software must still verify the witness version and witness program length rules before constructing the corresponding output script.

That last sentence matters because the checksum alone is not the whole validity story. A string can be structurally valid Bech32 or Bech32m and still not be a valid SegWit address unless the version-program combination obeys the address rules.

Conclusion

Bech32 addresses exist because Bitcoin needed a better human-facing encoding for native SegWit outputs. Their unusual look is the result of engineering tradeoffs: a visible network prefix, a restricted alphabet, lowercase output, and a checksum designed to catch realistic errors before funds move.

The enduring idea is easy to remember: a Bech32 address is a careful textual wrapper around a witness version and witness program. For SegWit v0 that wrapper is Bech32; for v1 and later it is Bech32m. If you remember that the address is encoding versioned script data (not just “some random string”) the format stops looking arbitrary and starts looking inevitable.

How do you secure your crypto setup before trading?

Secure your crypto setup by verifying addresses, device confirmations, and small test transfers before trading. On Cube Exchange, your keys are managed with a non-custodial MPC model, so these checks help stop address-replacement, network-mismatch, and format errors before you move meaningful value.

1. Verify the address HRP and full checksum before sending funds: confirm the prefix (e.g., bc1 vs tb1) and that the address is all-lowercase and the expected length.
2. Confirm the full destination on a hardware device or other trusted signer: approve the exact Bech32/Bech32m string on-device before broadcasting any transaction.
3. Send a small test transfer and wait for the chain-specific confirmations: confirm the test amount settles on-chain to the intended HRP/network before sending larger sums.
4. Fund your Cube account (fiat on-ramp or crypto transfer), then place the trade or withdrawal using the funded balance and the order type you need (limit for price control, market for immediate execution).