Bech32 Encoder / Decoder – SegWit Address, Bech32m, LNURL, npub

What is a bech32 encoder / decoder?

A bech32 encoder / decoder converts between raw bytes and the BIP-173 string format: a human-readable part (bc, ltc, lnurl, npub), the separator 1, the payload as 5-bit groups in a 32-character alphabet, and a 6-character BCH checksum. Bech32m (BIP-350) is the same format with a different checksum constant, required for SegWit version 1 and higher (Taproot bc1p…).

Worked example

Witness program 751e76e8199196d454941c45d1b3a323f1433bd6 with version 0 and hrp bc encodes to bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4, the BIP-173 reference address. Decoding it returns version 0, a 20-byte program and encoding bech32. The same program with version 1 would require bech32m and start with bc1p.

Where bech32 shows up

Bitcoin: bc1q (P2WPKH, P2WSH), bc1p (P2TR), tb1 on testnet, bcrt1 on regtest.
Litecoin: ltc1. Other chains: Cosmos (cosmos1…), Cardano (addr1…), Zcash unified addresses, Harmony (one1…) use the same scheme with their own payloads and sometimes longer length limits.
Lightning: BOLT11 invoices (lnbc…) are bech32 without the 90-character limit; LNURL wraps a URL in bech32 with hrp lnurl.
Nostr: npub, nsec, note and nprofile identifiers (NIP-19).

Bech32 vs. bech32m vs. Base58Check

Encoding	Checksum	Error detection	Typical use
bech32 (BIP-173)	6 characters, constant 1	guaranteed for up to 4 substitutions in 90 characters	bc1q SegWit v0, LNURL, Lightning invoices, npub
bech32m (BIP-350)	6 characters, constant 0x2bc830a3	same, and fixes the insertion weakness before a final p	bc1p Taproot, SegWit v1 and later
Base58Check	4 bytes of double SHA-256	probabilistic, no guarantee	1… and 3… Bitcoin, Tron T…, XRP

Common mistakes

Mixed case. bc1Qw508… is invalid; the string must be all lowercase or all uppercase.
Wrong checksum variant. Encoding a version-1 program with bech32 instead of bech32m produces a string wallets reject.
Misreading the separator. The 1 after the human-readable part is a separator, not data; the digit 1 never appears in the payload alphabet.
Treating 5-bit groups as bytes. The decoded data must be regrouped from 5-bit to 8-bit values; a SegWit program drops the padding bits, LNURL keeps strict byte alignment.

Validate a full Bitcoin address, including Base58 legacy formats, with the Bitcoin address validator.

Frequently asked questions

What is bech32?

An encoding defined in BIP-173 for Bitcoin SegWit addresses: a human-readable part, the separator 1, and data in a 32-character alphabet with a 6-character BCH checksum that detects up to 4 errors. It is case-insensitive and QR-friendly in uppercase.

What is the difference between bech32 and bech32m?

Bech32m (BIP-350) changes the checksum constant from 1 to 0x2bc830a3 to fix a weakness in bech32 when the final character is a p. SegWit version 0 (bc1q) keeps bech32; version 1 Taproot and later (bc1p) use bech32m. The decoder tries both.

Why does the data not convert to whole bytes?

Bech32 carries 5-bit groups. A SegWit address has a 1-group witness version followed by the program, so the raw data is not byte-aligned; the tool shows the version and program separately. Other uses such as LNURL and npub encode whole bytes with padding.

Can I decode LNURL and Nostr keys?

Yes. lnurl1… decodes to the URL text; npub1… and nsec1… decode to 32-byte keys. Never paste an nsec or any private key anywhere, including here.

What is the maximum length of a bech32 string?

BIP-173 limits addresses to 90 characters so the 4-error guarantee holds. Lightning invoices and LNURL deliberately ignore the limit because they carry far more data; the checksum still works, just with weaker guarantees for very long strings.

How do I make a SegWit address from a public key?

Hash the compressed public key with SHA-256 then RIPEMD-160 to get the 20-byte program, choose witness version 0 and hrp bc. For Taproot, use the 32-byte x-only output key with version 1. This page does the encoding step; the key hashing is outside its scope.