Bech32 Encoder/Decoder

Bech32 is a binary-to-text encoding format defined in BIP-173 that pairs a human-readable prefix with data encoded in a 32-character alphabet, protected by a strong, purpose-built checksum. Unlike Base58 or Base64, Bech32 was designed specifically to make transcription errors detectable — and, in most cases, tell you exactly which characters were mistyped — rather than merely producing a compact string.

What it's used for

• Bitcoin SegWit addresses — native SegWit (P2WPKH/P2WSH) addresses use the bc1... (mainnet) or tb1... (testnet) format, which is exactly a Bech32 string: a human-readable part (HRP), a 1 separator, and the encoded witness data with its checksum. (Taproot addresses use a closely related variant called Bech32m, defined in BIP-350, which is not covered by this tool.)
• Lightning Network invoices — Lightning payment requests (lnbc...) use Bech32 encoding to combine an amount, routing hints, and other invoice fields into a single copy-pasteable string with built-in error detection.
• Any protocol needing typo-resistant identifiers — Bech32's checksum design (a BCH code) can detect any error affecting up to 4 characters in strings up to 89 characters long, and it's resistant to common transcription mistakes.

How to use this tool

1. Choose Encode or Decode with the mode selector.
2. Encode: enter the data to embed as a hex string (e.g. 220e2145fa4a1f9e913265ef30f7d6f02c4ae914) and set the Human-Readable Part (HRP) — bc for Bitcoin mainnet, tb for testnet, or any custom prefix your protocol uses. The tool converts the bytes into Bech32's 5-bit groups, appends a checksum, and produces the encoded string.
3. Decode: paste a Bech32 string. The tool splits it into its HRP and data, verifies the checksum, and — if valid — shows the HRP, the raw 5-bit data values, and the data re-assembled as hex bytes (when the bit length is byte-aligned).
4. The result appears automatically as you type — no button click needed. Use the copy or download icon to grab it.

FAQ

Why did decoding fail with a "checksum verification failed" error? That's Bech32 doing its job. Every valid Bech32 string ends with a 6-character checksum computed over the whole string (HRP included). If even a single character was mistyped, copied incorrectly, or corrupted, the checksum won't match and the tool reports it as invalid — it never silently accepts or "repairs" bad input.

Why does decoding reject a string with mixed upper- and lowercase letters? BIP-173 requires a Bech32 string to be entirely lowercase or entirely uppercase (never mixed), because the checksum is computed after normalizing to one case. A mixed-case string can't be unambiguously validated, so it's rejected outright rather than guessed at.

What's the difference between Bech32 and Bech32m? Both use the same alphabet and general structure, but Bech32m (BIP-350) uses a different constant in the checksum formula. Bech32 is used for SegWit witness version 0 addresses; Bech32m is used for witness version 1 and above (including Taproot). This tool implements the original Bech32 (BIP-173) checksum only.

Is the HRP case-sensitive? The HRP is conventionally lowercase (as in bc1... addresses), and this tool normalizes what you enter to lowercase before encoding. Decoding accepts either an all-lowercase or all-uppercase string, per the spec.

Why do I get "not byte-aligned" in the decoded output? Bech32 stores data in 5-bit groups, which don't always divide evenly into 8-bit bytes. If the decoded data can't be cleanly reassembled into whole bytes, the tool shows the raw 5-bit values instead of a hex string — this is expected for some non-address use cases (like Lightning invoices) that don't pack byte-aligned data.

Privacy

All encoding and decoding happens entirely in your browser — your data, addresses, and any other input never leave your device or get sent to a server.