Base32 Encode & Decode Online

What is Base32 encoding

Base32 is a binary-to-text encoding scheme that represents arbitrary data using a 32-character alphabet. The standard alphabet defined in RFC 4648 consists of the uppercase letters A–Z and the digits 2–7, with = used for padding. Every 5 bytes of input produce 8 characters of output.

A key design advantage of Base32 is that it is case-insensitive. The alphabet deliberately excludes lowercase letters, the digits 0, 1, 8, and 9 to avoid visual ambiguity between characters like O and 0, or I and 1. This makes Base32 ideal for scenarios where humans need to read or type encoded values manually, such as entering a two-factor authentication secret key.

The encoding process works by reading input 5 bits at a time (since 2⁵ = 32) and mapping each group to a character in the alphabet. Because input bytes are 8 bits wide, the encoder processes 5 bytes (40 bits) at a time, producing exactly 8 output characters. If the final block has fewer than 5 bytes, the remaining positions are filled with = padding characters to maintain alignment.

Base32 vs Base64

Both Base32 and Base64 solve the same fundamental problem: encoding binary data as printable text. The main difference is the trade-off between compactness and human-friendliness.

• Size overhead. Base64 encodes 3 bytes into 4 characters (33% overhead), while Base32 encodes 5 bytes into 8 characters (60% overhead). For the same input, Base32 output is roughly 20% longer than Base64.
• Alphabet size. Base64 uses 64 characters including both uppercase and lowercase letters, plus + and /. Base32 uses only 32 characters, all case-insensitive and free of special symbols that could cause issues in URLs or filenames.
• When to use Base64. Choose Base64 when output size matters and the encoded string will be handled by machines: data URIs, email attachments (MIME), JWT tokens, PEM certificates.
• When to use Base32. Choose Base32 when the encoded value will be read, spoken, or typed by humans, or when case sensitivity is a problem: TOTP secret keys, file names on case-insensitive systems, DNS labels.

You can convert between these formats using this tool alongside our Base64 Encode/Decode tool: decode the source format first, then re-encode in the target format.

Where Base32 is used

Base32 appears in many real-world systems where case-insensitive, human-readable encoding is important:

• TOTP/HOTP two-factor authentication. Apps like Google Authenticator, Authy, and 1Password store shared secret keys as Base32 strings. When you scan a QR code for 2FA, the otpauth:// URI contains a Base32-encoded secret in the secret parameter. Base32 was chosen here specifically because users sometimes need to type the key manually.
• Tor onion addresses. The .onion domain names used by Tor hidden services are Base32-encoded public key hashes. Version 3 onion addresses are 56 characters of Base32, encoding a 256-bit Ed25519 public key plus a version byte and checksum.
• DNSSEC (NSEC3). The NSEC3 record type in DNSSEC uses Base32hex encoding (a variant with 0–9 A–V) to represent hashed domain names. Since DNS is case-insensitive by design, Base32 is a natural fit.
• Crockford's Base32. Douglas Crockford proposed an alternative Base32 alphabet that excludes I, L, O, and U to further reduce transcription errors. It is used in systems like Zoho CRM IDs, some cryptocurrency address formats, and the ULID specification.
• Geohash. The popular geohash geocoding system uses a custom Base32 alphabet to encode latitude and longitude pairs into short, human-readable strings like 9q8yyk.

Related encoding tools

• Base64 Encode / Decode — the more compact encoding for machine-to-machine data like data URIs, JWTs, and email attachments.
• URL Encode / Decode — percent-encoding for special characters in query strings and URL paths.
• Hash Generator — one-way cryptographic hashes (SHA-256, MD5, and more) for data integrity verification and fingerprinting.