Base32 Encode & Decode

Free online Base32 Encode & Decode tool. 100% local processing — your data never leaves your device.

Output

Result will be displayed here...

Input → Encode

Usage Guide

About Base32

Base32 (RFC 4648) encodes binary data using 32 ASCII characters (A–Z and 2–7). It is designed for contexts that require alphanumeric-only, case-insensitive output — such as DNS labels, file names, and two-factor authentication secrets.

When to use Base32 vs Base64: Base32 produces longer output (~1.6× vs ~1.33× for Base64) but is safe in case-insensitive environments and avoids special characters. Use Base32 for TOTP secrets and DNS-safe identifiers; use Base64 for compact general-purpose binary encoding.

Usage Steps

Base32 is reversible — the same tool encodes and decodes:

•
1. Enter InputPaste or type the text to encode in the input box
•
2. Encode/DecodeClick "Encrypt" to encode, "Decrypt" to decode
•
3. Copy ResultClick "Copy" to copy the output
Privacy: All processing runs entirely in your browser via WebAssembly. No data is sent to any server.

Output Format

Base32 output uses uppercase A–Z and digits 2–7, padded with = to a multiple of 8 characters. Example: "hello" → "NBSWY3DPEB3W64TMMQ======".

•
AlphabetA–Z (26 letters) + 2–7 (6 digits) = 32 symbols
•
Padding= characters pad to 8-char boundary
•
Case-insensitiveDecoder accepts both upper and lowercase input
•
Size overheadOutput is ~1.6× input size (5 bytes → 8 chars)

Base32 vs Other Encodings

Choose the right encoding for your use case:

•
Base32 vs Base64Base32 is ~25% longer but uses only alphanumeric + 2–7 (safe in DNS, file systems, case-insensitive contexts)
•
Base32 vs HexBase32 is more compact than Hex (5 bytes → 8 chars vs 10 hex chars) while remaining URL/filename-safe
•
Primary usesTOTP/HOTP secret keys (Google Authenticator), DNS labels, file names, case-insensitive identifiers
For general binary-to-text encoding where case matters, use Base64 instead — it is 25% more compact.

FAQ

Q: Why does Base32 output end with = signs?

A: Base32 encodes 5 bits per character and processes input in 5-byte (40-bit) blocks. If the input length is not a multiple of 5, padding characters (=) are added to complete the last block. This padding can be stripped for compact storage and re-added before decoding.

Q: What is Base32 used for in practice?

A: The most common real-world use is TOTP/HOTP secret keys — Google Authenticator, Authy, and all RFC 6238-compatible apps encode the shared secret as Base32. Base32 is also used in DNS names (NSEC3 records), Tor .onion addresses (v3), Bitcoin Bech32 addresses, and file-system-safe identifiers where lowercase/uppercase must not differ.

Q: Can I decode Base32 that has no padding?

A: Yes — this tool accepts Base32 input with or without trailing = padding. Padding is automatically handled during decoding.

Q: What is the difference between Base32 and Base32Hex?

A: Standard Base32 (RFC 4648 §6) uses A–Z + 2–7. Base32Hex (RFC 4648 §7) uses 0–9 + A–V — it sorts in the same order as the raw binary data, which is useful for sorted lookups. This tool implements standard Base32.

Q: Is Base32 an encryption or security mechanism?

A: No. Base32 is purely an encoding scheme — it is completely reversible and provides zero confidentiality or integrity guarantees. Anyone who sees a Base32 string can decode it instantly. For encryption use AES-256-GCM or ChaCha20-Poly1305.

Use Cases

Recommended: TOTP/HOTP Secret Keys

Two-factor authentication apps (Google Authenticator, Authy, Microsoft Authenticator) encode the shared HMAC secret as a Base32 string. When you scan a QR code to set up 2FA, the embedded data contains a Base32-encoded key. This is the dominant real-world use of Base32.

Recommended Configuration:
  • ✅ Base32 is the standard encoding for TOTP/HOTP secrets (RFC 6238, RFC 4226)
  • ✅ Use Base32 when generating authenticator-compatible shared secrets
  • ❌ Do not confuse the Base32-encoded secret with an encrypted or hashed value — it is reversible
Recommended: DNS-Safe and Case-Insensitive Identifiers

Base32 output contains only alphanumeric characters (no +, /, =). Combined with case-insensitivity, it is safe for DNS labels, file names on case-insensitive filesystems (Windows, macOS HFS+), and email local parts.

Recommended Configuration:
  • ✅ Base32 for DNS-safe identifiers (NSEC3 hashes use Base32Hex)
  • ✅ Base32 for file names that must survive case-folding
  • ✅ Base32 for Tor v3 .onion hostnames
  • ❌ For compact binary-to-text in case-sensitive contexts, prefer Base64
Acceptable: Human-Transcribed Codes

Base32 avoids characters that are visually ambiguous in some fonts (0/O, 1/l). The 2–7 digit range is used specifically because 0 and 1 are excluded. This makes it suitable for printed codes, voice-read identifiers, or activation keys.

Recommended Configuration:
  • ✅ Base32 for activation codes or license keys that users may type manually
  • ⚠️ Consider Crockford Base32 if stricter human-readability is needed (excludes I, L, O, U)
  • ❌ Base32 for large binary blobs where compactness matters — output is ~1.6× input size
Not Recommended: General Binary Encoding

For storing or transmitting arbitrary binary data (images, cryptographic keys, certificates), Base64 is the better choice — it is 25% more compact and universally supported. Base32's main advantage (case-insensitivity) is irrelevant when data is not displayed.

Recommended Configuration:
  • ❌ Base32 for embedding binary files in JSON, XML, or HTTP headers — use Base64
  • ❌ Base32 for PEM certificates or SSH key material — use Base64
  • ✅ Base64 for all general-purpose binary-to-text encoding

Best Practice Summary

  • Use Base32 when you need case-insensitive, alphanumeric-only output — primarily for TOTP secrets and DNS-safe identifiers.
  • Base32 is NOT encryption — output is fully reversible by anyone.
  • For compact binary encoding in case-sensitive systems, prefer Base64 (25% more efficient).
  • The standard alphabet is A–Z + 2–7 (RFC 4648 §6). Digits 0 and 1 are intentionally excluded to reduce transcription errors.

Discussion & Feedback

0 comments
Me