Input (Plain Text)
0 bytesOutput (Base32)
0 charsBase32 Alphabet Reference
| Value | Std Char | Hex Char | Value | Std Char | Hex Char |
|---|
| Value | Std Char | Hex Char | Value | Std Char | Hex Char |
|---|
Base32 Encoder and Decoder converts text or binary data to and from Base32 encoding. Supports standard Base32 (RFC 4648), Base32hex (extended hex alphabet), and z-base-32 variants. Enter text to encode or paste Base32 to decode. Also handles raw byte input via hex strings. Shows the character alphabet used, padding characters, and the size ratio compared to original input.
Base32 encoding represents binary data using 32 characters: A-Z and 2-7. Each Base32 character encodes 5 bits (2^5 = 32). Every 5 input bytes (40 bits) become 8 Base32 characters, so Base32 increases data size by 60% (vs Base64's 33% increase). Padding with = characters makes the output a multiple of 8 characters. Base32 is case-insensitive and uses only alphanumeric characters -- advantages over Base64 which uses + and / that require URL encoding.
Common uses of Base32: TOTP/HOTP 2FA secret keys (Google Authenticator, Authy -- secrets like JBSWY3DPEHPK3PXP are Base32). IPFS CIDs (Content Identifiers) use Base32 multibase encoding. Onion addresses (.onion v3) use Base32. DNS-safe encoding (Base32hex is safe for DNS labels). Data URIs in constrained environments where Base64 special characters cause issues. Secret key distribution where case-insensitive is important (user might type in all-caps or all-lowercase).
Encode 'Hello'
Result: JBSWY3DP (Standard Base32, no padding needed for 5 chars)
TOTP secret example
Result: Decode JBSWY3DPEHPK3PXP = Hello! (Google Authenticator uses Base32 for 2FA secrets)
Size comparison
Result: Original: 10 bytes -> Base32: 16 chars (+60%). Base64: 16 chars (+33%) for same data
What is the difference between Base32 and Base64?
Base64: uses 64 characters (A-Z, a-z, 0-9, +, /). Each character encodes 6 bits. Every 3 input bytes = 4 Base64 characters (33% size increase). Case-sensitive. + and / require URL encoding (%2B, %2F), which is why Base64url variants exist (use - and _ instead). Base32: uses 32 characters (A-Z, 2-7). Each character encodes 5 bits. Every 5 input bytes = 8 Base32 characters (60% size increase). Case-insensitive. No special characters -- safe for DNS, URLs, and user entry. Use Base64 when size matters and special chars are OK (binary data, HTTP auth). Use Base32 when case-insensitivity matters or special chars are problematic (TOTP secrets, DNS labels).
Why do TOTP authenticator apps use Base32 for secret keys?
TOTP (RFC 6238) and HOTP (RFC 4226) secrets are stored and transferred as Base32 strings. Reasons: case-insensitivity: users can type the secret in any case when setting up manually. Safe for QR codes and URIs (otpauth://totp/...). Human-readable: uses A-Z and 2-7 only -- digits 0, 1, 8, 9 are excluded to avoid confusion with letters O, I, B, Z. Google Authenticator, Authy, 1Password, and Bitwarden all use Base32 secrets. When an app shows a QR code for 2FA setup, the QR code encodes a URI like otpauth://totp/MyApp:user@example.com?secret=JBSWY3DPEHPK3PXP&algorithm=SHA1&digits=6&period=30.
What is Base32hex and how is it different from standard Base32?
Base32hex (Extended Hex Alphabet, RFC 4648 Section 7) uses the character set 0-9 and A-V (instead of A-Z and 2-7). Properties: the characters are in ASCII order (0123456789ABCDEFGHIJKLMNOPQRSTUV), which means lexicographic sort order is preserved -- sorted Base32hex strings are in the same order as the binary data they encode. This is useful for databases and systems that rely on lexicographic ordering. z-base-32 is another variant designed for human readability, avoiding easily-confused characters and preferring lowercase. IPFS uses multibase, which prefixes different base encodings: b = Base32 lowercase, B = Base32 uppercase, v = Base32hex lowercase.
How are .onion v3 addresses related to Base32?
.onion v3 addresses (Tor hidden services) use Base32 encoding. A v3 .onion address is 56 Base32 characters: example: facebookwkhpilnemxj7asber7cyf5ghm5bfqwhhlrm7szrax5bz6e6id.onion. The address encodes: 32 bytes of Ed25519 public key + 2 bytes version + 2 bytes checksum, then Base32-encoded. The earlier v2 addresses were 16 Base32 chars (10-byte SHA-1 hash of RSA key). Base32 is chosen because .onion addresses must be valid DNS hostnames, and DNS labels can only contain alphanumeric characters and hyphens -- Base32's A-Z2-7 alphabet (case-insensitive) satisfies this constraint.
How do I implement Base32 encoding in Python, JavaScript, or Go?
Python: import base64; encoded = base64.b32encode(b'Hello').decode(); decoded = base64.b32decode('JBSWY3DP'). For no-padding: base64.b32encode(data).rstrip(b'='). JavaScript (browser/Node): no built-in -- use hi-base32 library (npm install hi-base32): const base32 = require('hi-base32'); base32.encode('Hello'); base32.decode('JBSWY3DP'). Or use the base32-encoding package. Go: import 'encoding/base32'; encoded := base32.StdEncoding.EncodeToString([]byte('Hello')); decoded, _ := base32.StdEncoding.DecodeString('JBSWY3DP======'). Use base32.NoPadding for secrets. Rust: the base32 crate provides RFC 4648 encoding.