Bech32 / Bech32m Decoder (segwit address)
Decode any bech32 or bech32m string: human-readable part, data symbols, witness version, program and scriptPubKey — and which checksum it verifies under.
Checksum valid. It verifies under bech32
Human-readable part
bc
Checksum characters
v8f3t4
Data symbols (5 bits each)
33
Data as bytes (hex, padded from 165 bits)
03a8f3b740cc8cb6a2a4a0e22e8d9d191f8a19deb0
0 14 20 15 7 13 26 0 25 18 6 11 13 8 21 4 20 3 17 2 29 3 12 29 3 4 15 24 20 6 14 30 22
Read as a segwit address
Witness version
0
Program length (bytes)
20
Witness program (hex)
751e76e8199196d454941c45d1b3a323f1433bd6
scriptPubKey (hex)
0014751e76e8199196d454941c45d1b3a323f1433bd6
Witness version 0 with a bech32 checksum, which is the pairing BIP-350 requires.
How to use
- Paste the string. Any bech32 or bech32m string works, not only an address — the four example buttons cover a version 0 P2WPKH, a version 0 P2WSH, a taproot output and the first with one character changed.
- Read the checksum verdict first. It names which of the two constants the string satisfies, and a failure names the reason: mixed case, a character outside the alphabet, no separator, over 90 characters, or a checksum that simply does not verify.
- If the string decodes as an address, check the witness version against the encoding. Version 0 must be bech32 and every later version must be bech32m; the page says outright when the pairing is wrong.
- Copy what you need: the human-readable part, the witness program, or the scriptPubKey the output would carry. Each card copies its own value.
About this tool
ShowHide
Bech32 is the address format Bitcoin uses below the surface of every string starting bc1, and it is two formats rather than one. BIP-173 defined bech32, whose checksum leaves a residue of 1; BIP-350 defined bech32m, identical except that the residue is 0x2bc830a3. Witness version 0 addresses keep bech32 and every later version, taproot included, takes bech32m. This page verifies both, tells you which one the string actually satisfies, and says so separately from whether the result is a usable address.
That separation is the whole point. BC1SW50QA3JX3S has a perfectly valid bech32 checksum and decodes to witness version 16, so a validator written before BIP-350 calls it an address — but version 16 requires bech32m, so it is not one. The page reports the checksum as valid and the address as wrong in the same breath, because those really are two different answers.
BIP-350 exists because bech32 has a specific, narrow flaw, and you can watch it happen here: when a bech32 string ends in p, inserting any number of q characters just before that p leaves the checksum valid. bc188la77m0yfgp still verifies as bc188la77m0yfgqp, and as bc188la77m0yfgqqqqqp. Paste a bech32m string through the same treatment and it fails, which is what the new constant bought. For segwit addresses the flaw was harmless — the length is fixed by the witness version — but it would not have stayed harmless for the variable-length payloads later versions allow.
The rest of what you see is structural. The data part is base-32 symbols of five bits each, over an alphabet that leaves out the digit 1 and the letters b, i and o so that a handwritten character cannot slide into a neighbour. A version 0 P2WPKH address carries 33 symbols, which is 165 bits — not a whole number of bytes, so the generic byte view has to pad and this page says when it did. Only the witness program is regrouped strictly, because that is the one place the specification forbids padding. The scriptPubKey is then OP_0 or OP_1 through OP_16 followed by a push of the program, which is why a taproot output begins 5120.
Everything is checked in your browser and nothing is sent anywhere, so a string you are not yet sure about does not leave the machine. What this cannot tell you is whether an address belongs to anyone, holds anything, or was the one you were given: a checksum catches typos, not substitutions.
Frequently asked questions
What is the difference between bech32 and bech32m?
One constant. Both run the same BCH code over the same alphabet, but a valid bech32 string leaves a residue of 1 while a valid bech32m string leaves 0x2bc830a3. BIP-350 introduced the second because bech32 has an insertion weakness: a string ending in p keeps a valid checksum when q characters are inserted before that p. Witness version 0 stayed on bech32 for compatibility, so both formats are live and a decoder has to try both.
Why does my taproot address fail in an older wallet?
Because taproot is witness version 1, which requires bech32m, and a wallet written against BIP-173 alone only knows the residue 1. It will report a valid-looking bc1p address as having a bad checksum. This page distinguishes the two cases: the checksum line tells you which constant verified, and the address line tells you whether that is the constant the version requires.
Why are 1, b, i and o missing from the alphabet?
To keep handwritten and read-aloud strings from collapsing into each other: 1 against l, b against 6, i against 1, o against 0. The 32 remaining characters are qpzry9x8gf2tvdw0s3jn54khce6mua7l, in that order, and the value of a symbol is its index in that string. The digit 1 doubles as the separator between the human-readable part and the data, which only works because it cannot appear in the data.
Why is the byte view padded?
Because five-bit symbols rarely group into whole bytes. A version 0 P2WPKH address has 33 data symbols, which is 165 bits: twenty bytes of program, five bits of witness version, and no clean split. The spec avoids this by converting the program alone, without the version symbol and without padding — 32 symbols, 160 bits, 20 bytes exactly. The generic byte view on this page pads and tells you the bit count so the difference is visible.
Does a valid checksum mean the address is safe to pay?
No. A checksum catches accidental damage — a mistyped character, a truncated copy — and nothing else. An attacker who swaps an entire address for one of their own produces a string with a perfectly valid checksum. Verify the address through a second channel, and for a version 0 address note that the 20-byte and 32-byte programs mean quite different things: a single key against a script whose terms you cannot see from the address at all.
Related tools
Hash Generator (SHA)
Generate SHA-1, SHA-256, SHA-384, and SHA-512 hashes from text.
Developer
CRC-32 Calculator (CRC-32 & CRC-32C)
Compute the CRC-32 (IEEE 802.3, used by zip/gzip/PNG) or CRC-32C (Castagnoli) checksum of text or hex bytes, in hex and unsigned decimal.
Developer
ISBN Validator (ISBN-10 / ISBN-13)
Validate ISBN-10 and ISBN-13 checksums and convert between the two formats. Hyphens and spaces are handled.
Developer
Base64 Encoder / Decoder
Encode text to Base64 or decode Base64 back to text, instantly.
Developer
URL Encoder / Decoder
Percent-encode text for URLs, or decode encoded URLs back to text.
Developer
JWT Decoder
Decode a JSON Web Token to inspect its header, claims, and expiration.
Developer