Tools/Converters

Bech32 Encoder/Decoder: Bitcoin SegWit Address Tool

Encode and decode Bech32 and Bech32m strings used in Bitcoin SegWit addresses. Validate bc1 addresses, inspect witness versions, and understand the Bech32 format.

Spark TeamInvalid Date

Bech32 (BIP-173) is used for witness version 0 addresses. Bech32m (BIP-350) is used for witness version 1+ addresses including Taproot.

What Is Bech32?

Bech32 is an encoding format introduced in BIP-173 by Pieter Wuille and Greg Maxwell in 2017. It was designed specifically for Bitcoin's Segregated Witness (SegWit) upgrade to replace the older Base58Check encoding used in legacy addresses. The name "Bech32" combines "BCH" (the error-correcting code family it uses) with "32" (the size of its character set).

Unlike Base58Check addresses that start with 1 or 3, Bech32 addresses start with bc1 for Bitcoin mainnet and tb1 for testnet. The format uses only lowercase alphanumeric characters (excluding 1, b, i, o) to avoid visual ambiguity between similar-looking characters. This makes Bech32 addresses easier to read aloud, copy accurately, and encode in QR codes.

Bech32 encoding is not limited to Bitcoin. It has been adopted by other protocols and blockchains, including the Lightning Network for encoding payment invoices (with the lnbc prefix) and Cosmos-based chains for account addresses. Any system that needs a human-readable, error-detecting encoding can use the Bech32 format with a custom human-readable part.

Bech32 vs Bech32m

After Bech32 was deployed, researchers discovered a subtle weakness in its error-detection properties. When the last character of a Bech32 string is p, inserting or deleting q characters immediately before it does not invalidate the checksum. While this weakness does not affect witness version 0 addresses (which have fixed lengths that catch such errors), it posed a risk for future witness versions with variable-length programs.

BIP-350 introduced Bech32m in 2021 as the fix. Bech32m changes a single constant in the checksum algorithm: the original Bech32 uses a final XOR value of 1, while Bech32m uses 0x2bc830a3. Everything else about the encoding remains identical: same character set, same human-readable part, same separator.

The rule for Bitcoin addresses is straightforward: witness version 0 uses Bech32, and witness version 1 and above use Bech32m. This means P2WPKH and P2WSH addresses (starting with bc1q) use the original Bech32 encoding, while Taproot addresses (starting with bc1p) use Bech32m.

How SegWit Addresses Work

A SegWit address encodes two pieces of information: a witness version and a witness program. The witness version is a number from 0 to 16 that indicates which set of validation rules the spending script follows. The witness program is the hash or public key data that identifies the specific output.

Witness Version 0: P2WPKH and P2WSH

Witness version 0, defined in BIP-84, covers two output types. P2WPKH (Pay-to-Witness-Public-Key-Hash) uses a 20-byte witness program that is the HASH160 of a compressed public key. P2WSH (Pay-to-Witness-Script-Hash) uses a 32-byte witness program that is the SHA-256 of the redeem script. These addresses always begin with bc1q because the witness version 0 maps to the character q in the Bech32 alphabet.

Witness Version 1: Taproot (P2TR)

Witness version 1, defined in BIP-86, introduced Taproot outputs. A P2TR witness program is a 32-byte tweaked public key. These addresses begin with bc1p because witness version 1 maps to the character p in the Bech32 alphabet. Taproot addresses use Bech32m encoding to benefit from the improved error-detection properties.

Bech32 Address Format

Every Bech32 or Bech32m string consists of three parts separated by a specific structure:

ComponentDescriptionExample
Human-Readable Part (HRP)Identifies the network or protocolbc (mainnet), tb (testnet)
SeparatorAlways the character 11
Data PartWitness version + witness program + 6-char checksumqw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

The data part is encoded using a 32-character alphabet: qpzry9x8gf2tvdw0s3jn54khce6mua7l. Each character represents 5 bits of data. The first character of the data part encodes the witness version (0 through 16), and the remaining characters (excluding the last six) encode the witness program. The final six characters form a BCH error-detecting checksum that protects the entire string, including the human-readable part.

This table compares the four Bitcoin address formats in common use:

FormatPrefixEncodingExample Use
Legacy (P2PKH)1...Base58CheckOriginal Bitcoin addresses
P2SH-SegWit3...Base58CheckWrapped SegWit for compatibility
Native SegWit (v0)bc1q...Bech32P2WPKH and P2WSH outputs
Taproot (v1)bc1p...Bech32mP2TR outputs (Schnorr signatures)

Error Detection

One of Bech32's most important features is its strong error-detection capability. The 6-character checksum uses a BCH code that can guarantee detection of any error affecting up to 4 characters. It can also detect most errors affecting more characters, with a failure probability of less than 1 in a billion for random errors.

The checksum is computed over the entire string: the human-readable part, the separator, and the data characters. This means that even swapping two characters, changing a single character, or accidentally inserting or deleting a character will almost certainly be caught before funds are sent to an invalid address.

Beyond detection, the BCH code used in Bech32 can also locate errors. If a wallet detects that a Bech32 string has a checksum mismatch, it can identify which character positions are likely wrong and suggest corrections. This is particularly useful for manual entry scenarios where users might misread a character.

Bech32 Adoption

Since SegWit activation in August 2017, Bech32 addresses have steadily grown in adoption. As of 2026, the majority of Bitcoin transactions use native SegWit or Taproot outputs. Major wallets, exchanges, and payment processors now support both sending to and receiving from Bech32 and Bech32m addresses.

The transition has been driven by tangible benefits: native SegWit transactions are roughly 38% cheaper in fees compared to equivalent legacy transactions because the witness data receives a discount in block weight calculations. Taproot transactions further improve efficiency for complex spending conditions by allowing multisig and script-path spends to appear as simple single-key spends on-chain.

For developers building Bitcoin applications, supporting Bech32 and Bech32m is now considered a baseline requirement. Libraries for encoding and decoding are available in every major programming language, and the algorithm is simple enough to implement from scratch using the polynomial checksum defined in BIP-173 and BIP-350.

Frequently Asked Questions

What is a Bech32 address?

A Bech32 address is a Bitcoin address format introduced by BIP-173 for native SegWit outputs. It starts with bc1 on mainnet and uses a 32-character lowercase alphabet with a built-in error-detecting checksum. The format encodes a witness version and witness program, allowing wallets to construct the correct scriptPubKey for spending.

What is the difference between Bech32 and Bech32m?

Bech32m is an updated version of Bech32 defined in BIP-350. It changes a single constant in the checksum algorithm to fix a weakness where inserting or deleting characters before a trailing p could go undetected. Witness version 0 addresses use original Bech32, while witness version 1 and above (including Taproot) use Bech32m.

Why do SegWit addresses start with bc1?

The bc prefix is the human-readable part (HRP) that identifies Bitcoin mainnet. The 1 is the separator between the HRP and the data part of the Bech32 encoding. Testnet addresses use tb1 instead. Other protocols choose their own HRP values: Lightning invoices use lnbc, for example.

What does bc1q vs bc1p mean?

The character after bc1 indicates the witness version. q represents witness version 0 (used for P2WPKH and P2WSH outputs), while p represents witness version 1 (used for Taproot/P2TR outputs). In the Bech32 alphabet, q is the character at index 0 and p is at index 1.

Can Bech32 detect errors in an address?

Yes. Bech32 uses a BCH error-correcting code that guarantees detection of any error affecting up to 4 characters. For longer error bursts, the probability of an undetected error is less than 1 in a billion. The checksum covers the entire string including the human-readable part, making it extremely reliable for catching typos and copy-paste errors.

Are all bc1 addresses the same format?

All bc1 addresses use the Bech32 family of encoding, but they differ in the specific variant. Addresses starting with bc1q (witness version 0) use original Bech32 encoding, while addresses starting with bc1p (witness version 1) use Bech32m encoding. A valid decoder must check the witness version and verify the checksum against the correct variant.

What witness versions exist in Bitcoin?

Bitcoin currently uses witness version 0 (P2WPKH and P2WSH) and witness version 1 (Taproot/P2TR). Versions 2 through 16 are reserved for future upgrades and are not yet assigned any consensus meaning. When encoding these future versions, Bech32m must be used per BIP-350.

Can I use Bech32 encoding for non-Bitcoin data?

Yes. Bech32 is a general-purpose encoding format. You can use any human-readable part (HRP) you choose and encode arbitrary data in the payload. The Lightning Network uses it for invoices (lnbc), and several other blockchain projects have adopted it for their own address formats. The only requirement is that the HRP contains characters in the ASCII range 33 to 126 and the data can be represented in 5-bit groups.

This tool runs entirely in your browser. No data is transmitted to any server. Spark does not provide financial, legal, or investment advice. Always verify addresses using your wallet software before sending funds.

Build with Spark

Integrate bitcoin, Lightning, and stablecoins into your app with a few lines of code.

Read the docs →