How to use the Base32 Encoder
Encode text to Base32 in three steps:
1
Paste your text
Paste any plain text or binary-safe string into the input area.
2
Configure options
Toggle padding (= characters) on or off. Standard RFC 4648 includes padding; some applications (like TOTP) strip it.
3
Copy the encoded output
The Base32 string appears instantly in uppercase. Copy or download. The footer shows encoded length and the ratio vs input length.
When to use this tool
Use Base32 encoding when you need human-readable, case-insensitive encoded output:
- →Encoding TOTP (Time-based One-Time Password) secret keys which are distributed as Base32 strings in authenticator apps like Google Authenticator
- →Encoding data for use in DNS labels where only alphanumeric characters and hyphens are allowed
- →Generating case-insensitive encoded strings for file names on case-insensitive file systems (Windows, macOS)
- →Encoding binary identifiers for use in URLs or systems where + and / characters (used in Base64) cause problems
- →Producing human-typeable encoded strings where users may need to transcribe the value — Base32 avoids visually confusing characters
- →Encoding data for storage in systems that normalise text to uppercase, where Base64's lowercase letters would be corrupted
Frequently asked questions
Q:What is Base32 and how does it differ from Base64?
Base32 uses an alphabet of 26 uppercase letters (A–Z) and 6 digits (2–7) — 32 characters total. Base64 uses 64 characters including lowercase letters, digits, and the symbols + and /. Base32 output is approximately 60% larger than the input (compared to Base64's 33% overhead) but is fully case-insensitive, contains no symbols, and is safer for use in contexts like DNS names, file systems, and human transcription.
Q:Why does Base32 use digits 2–7 instead of 0–9?
The digits 0 and 1 are excluded from the Base32 alphabet because they are visually similar to the letters O and I (or l), which could cause transcription errors. Using 2–7 avoids all ambiguous character pairs, making Base32 strings reliable for human entry and display in printed materials or UI elements where font clarity may vary.
Q:What is Base32 used for in TOTP / two-factor authentication?
TOTP (RFC 6238) and HOTP secret keys are distributed as Base32-encoded strings — for example, the text strings shown as QR codes or manual entry keys in Google Authenticator, Authy, and similar apps. The Base32 encoding is used because it is case-insensitive (users may type it in any case), contains no ambiguous symbols, and is easy to group into readable blocks (e.g. JBSW Y3DP EB3W 64TM).
Q:What is the size overhead of Base32 compared to the original input?
Base32 encodes 5 bytes of input into 8 characters. The ratio is 8/5 = 1.6, meaning the output is 60% larger than the input before padding. Padding (= characters) may add up to 6 extra characters to make the output length a multiple of 8. This is substantially more overhead than Base64's 33%, which is why Base32 is reserved for use cases where its human-readability and case-insensitivity benefits outweigh the size cost.
Q:Can I encode Unicode or emoji characters?
Yes — the encoder first converts the input to UTF-8 bytes and then Base32-encodes those bytes. Unicode characters including emoji, CJK characters, and other multi-byte scripts are fully supported. The decoder must also use UTF-8 interpretation to correctly recover the original text.
Q:What is the difference between Base32 and Base32Hex?
Standard Base32 (RFC 4648) uses the alphabet A–Z, 2–7. Base32Hex (also defined in RFC 4648) uses the alphabet 0–9, A–V — chosen to preserve sort order between the original data and its encoded form. Base32Hex is used in DNS NSEC records (DNSSEC) and some database applications. This tool implements standard Base32. Base32Hex is less common in everyday usage.