Bech32 / Bech32m Address Encoder

Bech32 is the encoding behind every native SegWit Bitcoin address. When you see an address starting with bc1q, you are looking at a 20-byte or 32-byte witness program that has been grouped into five-bit chunks, mapped through a 32-character case-insensitive alphabet, and protected by a 6-word checksum that catches any single-character error with probability 1 minus 2^-30. The human-readable part before the separator (bc for Bitcoin mainnet, tb for testnet, cosmos for Cosmos Hub) is also covered by the checksum, so a cross-chain paste fails loudly rather than silently.

BIP-350 introduced Bech32m in 2021 for Taproot addresses. The two schemes share the same alphabet and the same polymod, differing only in the constant XORed at the end: Bech32 uses 1, Bech32m uses 0x2bc830a3. Witness version 0 (P2WPKH, P2WSH) requires Bech32; witness versions 1 through 16 (Taproot) require Bech32m. This is the single most common bug in address validators: checking a Taproot address with the v0 constant produces a checksum failure that looks like a typo. This tool names that case explicitly.

Worked Example: the BIP-173 Canonical P2WPKH Vector

The first Load Sample click fills the encode input with bc|751e76e8199196f38d7f5f3ccc9560b0c7b3e0b, the canonical 20-byte witness program from the BIP-173 specification itself. WithBech32 selected, the tool produces bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4, a 42-character P2WPKH address. The metadata strip reports 20 payload bytes, 42 total characters, and confirms the 6-word checksum was appended. Press Round trip and the address feeds the decoder, which recovers the same hex, confirms the HRP as bc, and marks the checksum as verified.

What It Accepts and How It Encodes

• Encode input format: hrp|hexbytes, a pipe separating the human-readable part from the payload hex. The HRP may be 1 to 83 printable ASCII characters; the hex may carry an optional 0x prefix and whitespace. An odd digit count is refused with “Hex needs an even number of digits — this has N, so one nibble has no byte to sit in.”
• Variant selector: Bech32 (constant 1, BIP-173) for witness version 0 addresses (P2WPKH, P2WSH); Bech32m (constant 0x2bc830a3, BIP-350) for Taproot and any witness version 1 through 16. The decoder auto-detects the variant from the checksum.
• Decode input: any Bech32 or Bech32m string, upper or lower case (but not mixed). The output shows the HRP, the payload as hex, the detected variant, and a checksum-verified badge.
• Round trip button: in encode mode, sends the result straight to the decoder. In decode mode, sends the recovered hrp|hex back to the encoder with the detected variant pre-selected, so you can verify the round trip is lossless.
• HRP beyond Bitcoin: the third Load Sample entry in encode mode demonstrates a Cosmos Hub address (HRP cosmos, 20-byte payload), showing that Bech32 is not Bitcoin-specific.
• Input is capped at 10,000 characters.

Tricky Inputs and What Can Go Wrong

• 90-character cap (BIP-173 §3): an encoded string longer than 90 characters is rejected. With a 2-character HRP like bc, that limits the payload to roughly 51 bytes before the separator and checksum push the total over the line.
• Wrong variant: decoding a bc1p Taproot address produces “Checksum looks valid as Bech32, not Bech32m. The witness version and checksum scheme do not match.” This is distinct from a mistype: the string is structurally valid, just built with the wrong constant.
• Mixed case: BC1QW5 and bc1qw5decode identically, but Bc1qW5 is refused with “Mixed upper and lower case characters.”
• Non-zero padding: a hand-crafted data part whose final 5-bit group carries a non-zero remainder is refused with “Non-zero padding in the final 5-bit group — the encoded data is malformed.” Valid encoders never produce this, but truncated strings do.
• Empty HRP: an encode input without a pipe, or with nothing before the pipe, is refused with “The human-readable part (HRP) must not be empty.”