Bech32 / Bech32m decoder & checksum verifier

What this page does

A bech32 address is a base-32 string with a BCH checksum, and it decodes to exactly two facts: a witness version and a witness program. Those two facts are the whole address — the scriptPubKey is literally OP_n followed by the program:

Paste any bc1…, tb1…, v0 or v1 address. This page shows every stage of the decode, tells you which checksum constant matched (and therefore whether BIP173 or BIP350 applies), and for invalid input prints the decoder's exact reason instead of guessing.

1. The shape of a bech32 string

The separator exists so the hrp needs no escaping, and it is the digit 1 rather than a symbol because punctuation survives copy-paste badly. 1 is safe because it is deliberately not in the data charset, so the hrp boundary is never ambiguous.

2. The 5-bit charset, and why 5 bits

The data part is a base-32 string over this alphabet, in this order:

Exactly 32 characters, so exactly 5 bits each — that is the whole reason for the number. Note which characters are missing: 1 (it is the separator), b, i and o, so no two similar-looking glyphs both encode data. The alphabet also minimises the number of visually similar pairs that differ in more than one bit, because the checksum is optimised for detecting small numbers of bit errors.

The cost is length — base32 needs about 15% more characters than base-256 — and the benefit is no mixed case to get wrong, unambiguous reading out loud, and QR alphanumeric mode, which is 45% more compact than byte mode.

3. 8-to-5 conversion and the zero-padding rule

The witness program is a byte string; the data part is a string of 5-bit values. Conversion is most-significant-bit first: take the program's bits, chop them into groups of five, and pad the last group with zero bits if it is short.

Because the padding is at most four bits, the rule is strict, and a decoder must enforce it:

A decoder that ignores this accepts several distinct strings for the same program, and it makes the padding bits a place where a typo hides. Both BIPs ship test vectors for exactly this: bc1zw508d6qejxtdg4y5r3zarvaryvqyzf3du uses "zero padding of more than 4 bits" and tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3pjxtptv has "non-zero padding". This page's decoder rejects both with Invalid padding: invalid padding — it requires the leftover bits after the last complete byte to be fewer than 5, and the shifted accumulator to be zero.

4. The BCH checksum

The checksum is not a hash. It is a BCH code over GF(32) — a linear error-correcting code whose algebra gives guarantees about which errors are caught:

GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3]

def polymod(values):
    chk = 1
    for v in values:
        b = chk >> 25
        chk = (chk & 0x1ffffff) << 5 ^ v
        for i in range(5):
            chk ^= GEN[i] if ((b >> i) & 1) else 0
    return chk

# hrp is folded in as [high 3 bits of each char] + [0] + [low 5 bits of each char]
verify:  polymod(hrp_expand(hrp) + data) == 1          # bech32
verify:  polymod(hrp_expand(hrp) + data) == 0x2bc830a3 # bech32m

The hrp is checksummed too, folded in high-bits-first: [ord(c) >> 5 for c in hrp] + [0] + [ord(c) & 31 for c in hrp]. An error confined to the low five bits of an hrp character therefore still lands inside the protected region. This is also why M1VUXWEZ is invalid — its checksum was computed over the uppercase hrp — while BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4 is valid.

BIP173 measured behaviour beyond four wrong characters. Counts are "per billion attempts"; a random 30-bit checksum fails 0.931 times per billion:

BIP350 repeats the exercise for bc1-shaped addresses. For a bech32m string checked by a bech32m decoder: 24.34% of single-error patterns are detected with certainty and 75.66% with probability 1 − 2⁻³⁰; for up to two errors inside a 28-character window, 16.85% / 83.15%; for up to two errors anywhere, 15.72% / 84.23%, with 0.039% at 2⁻²⁵. The same strings checked by a bech32 decoder do markedly worse — the point of the clean break.

5. bech32 vs bech32m — the insertion weakness that forced BIP350

This is the most important part of the page, because it explains why two nearly identical encodings exist for the same kind of address.

In 2020 it was discovered that bech32's checksum has a hole. Quoting BIP350:

Reproduced here with this page's own decoder — take a valid bech32 v0 address ending in p and insert q characters before that final p:

BIP350's fix is minimal: keep everything and change only the constant XORed into the checksum, from 1 to 0x2bc830a3. The same insertion against a bech32m string no longer verifies (polymod returns 920205498, not 734539939), so the mutation is caught by the checksum rather than by luck.

Two follow-on facts complete the picture. First, existing v0 addresses were never in danger: BIP350 notes the weakness "does not affect existing uses of witness version 0 BIP173 addresses due to their restriction to two specific lengths". Inserting a character changes the word count, so the program either changes size or breaks the padding rule — in our reproduction the mutated string is in fact rejected here by the Invalid padding check, and a v1+ insertion is caught by the bech32m constant. Second, BIP173 itself added a 2024 disclosure: the scheme "is not always robust against the insertion and deletion of fewer than 5 consecutive characters", which is why BIP173 now applies only to v0 outputs.

6. Validity rules this page enforces

Address lengths are therefore tightly constrained: 14–74 characters, never a length ≡ 0, 3 or 5 (mod 8), and always 42 or 62 for v0.

7. Worked example: the demo P2WPKH address

The witness program here equals the hash160 printed by hash160 → addresses for the same key, and the testnet form carries the same program with a different 6-character checksum: the hrp is checksummed, so a mainnet/testnet mix-up cannot survive.

8. Worked example: the demo P2TR address

That last row is the difference between the two example addresses in one line: a P2WPKH program is the hash of a public key, while a P2TR program is a public key (the tweaked one). Everything else — the encoding, the separator, the five-bit words, the six-character checksum — is identical; only the version word and the checksum constant differ.

9. Failure paths, as this page shows them

The invalid strings below are tested live on every run, alongside whatever you paste:

One scoping note, because it surprises people: BIP350's own test vectors include valid bech32m strings such as A1LQFN3A that are not segwit addresses at all (their data part is nothing but a checksum). A segwit decoder applies the address rules on top, so it rejects them — correctly, with a reason, and not with a crash.

10. Security notes and common mistakes

• Never let software "repair" an address. BIP173 is explicit: implementations should not correct beyond possibly indicating where an error might be, because a corrected address may not be the intended one and the funds go to the wrong place. Detection only.
• Lowercase is the wire format. Encoders must emit lowercase; uppercase is for display and QR codes (alphanumeric mode); a string must never mix the two.
• bc1q… and bc1p… differ by one letter and one constant. The checksum constant is what makes it impossible to read one as the other.
• A valid address is not necessarily spendable. A witness v2–v16 address, or a v0 program whose script you do not know, decodes perfectly and may be unspendable by any current software. Sending to one burns the coins.

11. Quick reference