Base32 Encoder / Decoder

Convert text or binary data to and from Base32 — the less common cousin of Base64, used specifically where case-insensitivity and human-readability matter more than compactness.

Why Base32 exists when Base64 already solves the same basic problem

Base64 and Base32 both exist to represent binary data using printable characters, but they make different tradeoffs. Base64 packs more information per character (using a 64-character alphabet including both uppercase and lowercase letters, numbers, and two symbols), making it more compact — but that case-sensitivity and inclusion of symbols like + and / makes it awkward for contexts where a human might need to read, type, or verbally communicate the value, or where the destination system doesn’t reliably distinguish uppercase from lowercase. Base32 uses a smaller, deliberately case-insensitive 32-character alphabet (typically A-Z and 2-7, avoiding easily-confused characters like 0/O and 1/I), which is why it shows up specifically in contexts like TOTP two-factor authentication secret keys, DNS labels, and some file-sharing and cryptocurrency address systems where human transcription accuracy matters.

How to use it

1. Switch between Encode and Decode mode.
2. Paste your text or Base32 string, and the conversion happens instantly.
3. Choose between the standard RFC 4648 Base32 alphabet and the Base32hex variant, since a small number of systems use the alternate hex-ordered alphabet instead of the standard one, and they aren’t interchangeable.
4. Toggle padding characters (=) on or off in the output, since some systems expect padded output while others (particularly URL-embedded uses) strip padding entirely.
5. For file input, drag and drop a file to Base32-encode its binary contents directly, useful for the same category of use cases as Base64 file encoding but where the case-insensitive property specifically matters.

Common situations this solves

• Manually verifying or debugging a TOTP two-factor authentication secret key, which is standardly stored and displayed in Base32 format specifically because users sometimes need to type it in by hand when scanning a QR code isn’t an option.
• Decoding a Base32-encoded value found in a config file or system you’re debugging, where you need to see the original underlying data.
• Working with systems that specifically require Base32 over Base64 due to case-insensitive infrastructure (like certain older or embedded systems, or DNS-adjacent tooling).
• Generating a human-readable-ish encoded identifier for a context where accidental case changes (like a system that lowercases all input) would otherwise corrupt a Base64-encoded value.
• Cross-checking a Base32 implementation in code against a known, independently-verified reference conversion during debugging.

Frequently asked questions

Is Base32 more secure than Base64?

No — like Base64, Base32 provides zero security or confidentiality. It’s purely an encoding scheme for representing binary data as text, fully and trivially reversible by anyone, with no cryptographic properties whatsoever. Choosing between them is about compatibility and readability requirements, never about security.

Why do TOTP authenticator secret keys specifically use Base32?

The TOTP standard (used by apps like Google Authenticator and Authy) settled on Base32 specifically because its case-insensitivity and avoidance of visually similar characters make manual transcription errors far less likely — relevant because setting up two-factor authentication sometimes requires a user to type in a secret key by hand rather than scanning a QR code, and a case-sensitive Base64 string would be considerably more error-prone to type correctly.

What’s the difference between standard Base32 and Base32hex?

Both use a 32-character alphabet and the same underlying algorithm, but the character-to-value mapping differs — Base32hex orders its alphabet so that the first 10 characters directly correspond to hexadecimal 0-9, which some systems (particularly certain DNS-related applications, per the NSEC3 specification) specifically require instead of the standard RFC 4648 alphabet. Using the wrong variant against a system expecting the other will produce a value that decodes to complete nonsense.

Why is Base32-encoded output noticeably longer than Base64 for the same input?

Base32 encodes 5 bits per character (since 2⁵ = 32) compared to Base64’s 6 bits per character (2⁶ = 64), meaning Base32 needs more characters to represent the same amount of underlying binary data — roughly a 60% size increase over the original input compared to Base64’s roughly 33% increase, which is the direct cost of Base32’s smaller, more transcription-friendly alphabet.

Does padding actually matter, or can I just always strip it?

It depends entirely on what’s consuming the encoded value — some parsers strictly require correct padding to know exactly where the encoded data ends, while others (especially URL-embedded values) expect it stripped since = has other meaning in some contexts. Check the specific system’s expectations rather than assuming one convention universally applies.