Skip to main content
AllDevToolsHub
🔐

Base32 Encoder/Decoder

100% Local

Convert text to Base32 encoding and back. Base32 is used in TOTP/2FA secrets, DNS records, and other systems that need case-insensitive encoding. Includes proper padding and swap functionality.

Base32 Encoder/Decoder
Try:
This tool runs entirely in your browser. Your input is never uploaded, logged, or sent to AllDevToolsHub or anyone else, and it keeps working offline once the page has loaded.

Paste text or a TOTP secret to encode/decode in Base32 (RFC 4648). Useful for OTPAuth URIs.

Overview

What is Base32 Encoder/Decoder?

Convert text to Base32 encoding and back. Used in TOTP/2FA secrets, DNS records, and systems needing case-insensitive encoding. Padding and swap built in.
FAQ

Frequently Asked Questions

Reference

Technical Deep Dive

ENCODERS & DECODERS

Base32 Encoder/Decoder

Convert text to Base32 encoding and back. Base32 is used in TOTP/2FA secrets, DNS records, and other systems that need case-insensitive encoding. Includes proper padding and swap functionality.

🧬

Spec-Compliant

Follows the RFC or de-facto encoding rules, no custom dialects, no surprises.

🔄

Lossless Round-Trip

Encode then decode and you get back exactly what you put in, byte for byte.

📡

Handles Edge Cases

Unicode, padding, invalid input, surfaced clearly instead of silently mangling output.

01 Encoding Comparison Matrix

Feature Base32 Base64 Hex
Bits per Char5 bits6 bits4 bits
Expansion60%33%50%
AlphabetA-Z, 2-7A-Z, a-z, 0-9, +/0-9, A-F
Case SensitiveNoYesNo

02 Conversion Pipeline

1
Bit-Stream Alignment The input binary stream is padded and re-aligned from 8-bit bytes into 5-bit chunks.
2
Alphabet Mapping Each 5-bit chunk is mapped to one of the 32 safe characters in the RFC 4648 alphabet (A-Z, 2-7).
3
Padding Finalization If the input length is not a multiple of 5 bytes, = padding characters are appended to maintain chunk integrity.

03 When You Reach for Base32

Base32 wins whenever the encoded blob has to survive being read aloud, typed by hand, or stored in a case-folding system. It is the wrong fit for anything where bandwidth matters more than human transcription.

  • 🔑
    TOTP / 2FA shared secrets Google Authenticator, Authy, 1Password and the otpauth:// URI scheme all expect the secret in Base32. RFC 6238 picked it precisely because users sometimes type the seed from a printed backup, no 0/O or 1/I confusion.
  • 🧅
    Tor v3 onion addresses A v3 onion is a Base32-encoded Ed25519 public key plus a checksum and version byte, 56 characters that end in .onion. The case-insensitive alphabet means a user can dictate it over the phone without losing the destination.
  • 🌐
    DNSSEC NSEC3 hashes and DNS-friendly IDs DNS labels are case-insensitive and limited to a tight character set. NSEC3 records store an iterated SHA-1 of the owner name as base32hex so it round-trips through any resolver without normalization changing the bytes.
  • ⚠️
    User-visible file or object IDs Base32 makes a 16-byte UUID into a 26-character lower-case string with no homoglyph traps. Fine for S3 keys and share links, just remember the 60% size hit vs Base64 when you're serializing millions of them.
  • 🚫
    Stuffing binary into JSON payloads If a machine is the only consumer, Base64 is 23% denser than Base32 and every language has it built in. Reach for Base32 only when a human will eventually look at the string.

04 Worked Examples

EXAMPLE 1 · THE ALPHABET HAS NO 0, 1, 8, 9
RFC 4648 §6 alphabet:
A B C D E F G H I J K L M

N O P Q R S T U V W X Y Z
2 3 4 5 6 7


Notice what is missing:

no 0 (confuses with O)
no 1 (confuses with I and L)
no 8, 9 (kept the count at 32)

This is why Google Authenticator picked Base32 over Base64 for printed/dictated backup codes. A user squinting at JBSWY3DPEHPK3PXP will not misread it the way they would l1lO0O in a denser alphabet.




EXAMPLE 2 · PADDING RULES (5 BYTES → 8 CHARS)

Inputs of length 1 through 5 bytes:

"f"      → MY======
"fo" → MZXQ====
"foo" → MZXW6===
"foob" → MZXW6YQ=
"foobar" → MZXW6YTBOI======

Padding count by input remainder mod 5:

1 byte  remainder → 6 '=' chars
2 bytes remainder → 4 '=' chars
3 bytes remainder → 3 '=' chars
4 bytes remainder → 1 '=' char
0 (full block) → no padding

Output length is always a multiple of 8 characters. Some implementations strip padding to save space (e.g. otpauth:// URIs often do); a strict RFC 4648 decoder will reject the un-padded form.




EXAMPLE 3 · 160-BIT HMAC SECRET → 32 BASE32 CHARS

Raw 20-byte HMAC-SHA1 key (hex):

3132333435363738393031323334353637383930

Same key in Base32 (what Authenticator imports):

GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ

160 bits / 5 bits per character = exactly 32 characters, no padding required. This is why TOTP seeds are almost always 32 chars: the underlying HMAC-SHA1 key is 160 bits by convention.




05 Related Tools

Base32 sits next to a small family of tools focused on secrets, identifiers, and human-readable encoded strings.

You Might Also Need