Quick answer: Base32 decoding turns a Base32-encoded
string (using A-Z and 2-7) back into its original text or binary data.
Example: JBSWY3DPEB3W64TMMQ======
decodes to Hello, world.
Paste your Base32 string above, click Decode, copy the result.
What is Base32?
Base32 is a binary-to-text encoding defined in
RFC 4648.
It uses an alphabet of 32 characters (A-Z and 2-7)
to represent binary data as plain ASCII text. Every 5 bytes of input
become 8 characters of output, with = padding at the end if
needed.
Compared to Base64, Base32 is bigger (~60% larger output vs ~33%) but has
practical advantages: it's case-insensitive, avoids visually-confusable
characters (no 0/O, 1/l,
8/B), and survives copy-paste through systems that
mangle case or special characters.
How Base32 decoding works
- Strip
=padding and any whitespace from the input. - Validate every character is in the Base32 alphabet (
A-Z,2-7). - Map each character to its 5-bit value (
A=0,B=1, ...,7=31). - Concatenate those 5-bit groups into a continuous bit stream.
- Re-split the bit stream into 8-bit bytes — those are the original bytes.
- Decode the byte sequence as UTF-8 text (or keep as raw bytes for binary data).
Examples
| Base32 input | Decoded output | Notes |
|---|---|---|
| JBSWY3DPEB3W64TMMQ====== | Hello, world | Standard with padding |
| JBSWY3DPEB3W64TMMQ | Hello, world | Same input, no padding |
| JBSWY3DPFQQHO33SNRSCC | Hello, base32! | Punctuation included |
| MFRGGZDFMZTWQ2LK | abcdefghij | 10 chars → 16 chars Base32 |
Where Base32 shows up in practice
- 2FA / TOTP secrets — When you scan a Google
Authenticator QR code, the embedded secret is Base32. Manual setup keys
are also Base32, formatted as 4-char groups for readability
(
JBSW Y3DP EB3W 64TM MQ). - Tor .onion addresses — Tor v3 onion services use Base32-encoded public keys (56 chars + ".onion").
- DNS-encoded data — Some protocols smuggle binary data through DNS labels using Base32 because DNS is case-insensitive and rejects many special chars.
- Voice transmission / radio — Base32 is unambiguous when spoken aloud (no "is that an O or a zero?" problem).
- Filename-safe identifiers — Some systems use Base32 for IDs because it works in any filesystem regardless of case sensitivity.
- Cryptocurrency addresses — Bech32 and Cashaddr are Base32 variants used by Bitcoin SegWit addresses and Bitcoin Cash.
Doing it in code
Python
import base64
base64.b32decode("JBSWY3DPEB3W64TMMQ======").decode("utf-8")
# 'Hello, world' JavaScript (Node.js with hi-base32)
const base32 = require("hi-base32");
base32.decode("JBSWY3DPEB3W64TMMQ======");
// "Hello, world" Go
import "encoding/base32"
b, _ := base32.StdEncoding.DecodeString("JBSWY3DPEB3W64TMMQ======")
// b = []byte("Hello, world") Bash (with python)
echo "JBSWY3DPEB3W64TMMQ======" | python3 -c "import sys, base64; print(base64.b32decode(sys.stdin.read().strip()).decode())" Base32 variants (not all the same)
- RFC 4648 standard — A-Z + 2-7. What this tool decodes.
- Crockford's Base32 — 0-9 + A-Z (excluding I, L, O, U). Used in some logging/ID systems. Different alphabet — decode with a Crockford-aware tool.
- z-base-32 — Permuted alphabet for human readability. Also incompatible.
- Base32hex (RFC 4648 §7) — 0-9 + A-V. Preserves sort order. Uncommon.
Related tools
- Base32 Encode — reverse direction
- Base64 Decode — more compact encoding
- Hex Decode — base16 / hexadecimal
- Binary Decode — base2
Frequently asked questions
What is Base32 decoding?
Base32 decoding converts a Base32-encoded string back into its original binary or text data. Base32 uses 32 characters (A-Z and 2-7) to represent binary data — for example, JBSWY3DPEB3W64TMMQ====== decodes to Hello, world. It is defined in RFC 4648.
How is Base32 different from Base64?
Base64 uses 64 characters (A-Z, a-z, 0-9, +, /) and is more compact: every 3 bytes encode to 4 characters (~33% overhead). Base32 uses 32 characters (A-Z, 2-7) and every 5 bytes encode to 8 characters (~60% overhead). Base32 is case-insensitive, avoids visually similar characters (no 0/O, 1/l, 8/B), and is safer in URLs, filenames, and voice transmission.
Why does Base32 have = at the end?
The = character is padding. Base32 outputs in 8-character blocks, but data may not be an exact multiple of 5 bytes. Padding fills the remaining slots so the output is always a multiple of 8 characters. Decoders strip = before processing — the data length is encoded in how many = there are (0, 1, 3, 4, or 6).
Does this decoder work without padding?
Yes. The decoder accepts Base32 strings with or without = padding. Many real-world Base32 outputs (especially TOTP/2FA secrets and Cloud Storage object names) omit padding for brevity.
What are common uses for Base32?
TOTP/HOTP secrets in 2FA apps (Google Authenticator, Authy), Bitcoin and other cryptocurrency addresses (Cashaddr, Bech32 variants), Tor .onion addresses, DNS-encoded text, voice-over-radio identifiers (because Base32 is unambiguous when spoken aloud), and any place case-insensitive identifiers are needed.
I'm getting "Invalid base32 characters" — why?
Base32 only allows A-Z, 2-7, and =. Spaces, lowercase letters (RFC 4648 standard is uppercase), and characters like 0, 1, 8, 9 are not valid. Try removing whitespace and converting to uppercase first. Some implementations use Crockford's Base32 (different alphabet) or z-base-32 — those need a different decoder.
Are decoded values sent to a server?
No. The decoder runs entirely in your browser using JavaScript. Input is never uploaded, logged, or stored. Sensitive data like 2FA secrets stays on your device.