Base32 Encoder & Decoder

About This Tool

Base32 encodes binary data using only 32 characters: the uppercase letters A to Z and the digits 2 to 7. It's the encoding format used for all TOTP 2FA secret keys (Google Authenticator, Authy, Microsoft Authenticator), defined in RFC 4648. Compared to Base64, Base32 is case-insensitive and avoids characters that look similar in different fonts (0, O, 1, l). This tool encodes any text to Base32 and decodes Base32 strings back to plain text, entirely in your browser.

How to Use

1. Select Encode (text → Base32) or Decode (Base32 → text) mode.
2. Type or paste your input into the text field.
3. The result appears instantly. Click Copy to copy to clipboard.
4. Note: Base32 input is case-insensitive, lowercase letters are automatically converted.

Common Use Cases

• Typing a secret into a hardware token or feature phone app: some older devices require you to manually enter a custom string that must first be encoded as valid Base32.
• Decoding a raw secret pulled from a config file or database backup: reverse a Base32 string to plain text to verify which account or service it actually belongs to.
• Building a test otpauth:// URI: convert a short test passphrase into Base32 to embed inside a custom URI while developing or debugging a TOTP integration.
• Validating an exported string before importing it: check whether a value copied out of a password manager export is genuinely valid Base32 before pasting it into another app.
• Learning bit-level encoding: useful for a computer science assignment or interview prep on how binary data maps to a restricted character alphabet.

Base32 vs Base64: Why 2FA Uses Base32

Base64 packs 6 bits of data into every output character from a 64-character alphabet, giving about 33% size overhead versus the original binary data. Base32 packs only 5 bits per character from a 32-character alphabet, giving roughly 60% overhead, which is noticeably less space-efficient. The tradeoff exists entirely for human usability: the Base32 alphabet used here (RFC 4648) contains only uppercase A to Z and digits 2 to 7, deliberately excluding 0, 1, 8, and 9 because they are easily confused with the letters O, I or L, B, and g in many fonts. Base64 includes both cases plus + and /, which are more prone to transcription mistakes and are also unsafe to embed directly in URLs or filenames without further escaping. Since 2FA secret keys are sometimes typed by hand from a printed backup sheet, RFC 6238 and every major authenticator app standardized on Base32 specifically to minimize those transcription errors, even at the cost of a longer string.

Troubleshooting

"Invalid Base32 character" error while decoding: only A to Z and 2 to 7 are valid. The digits 0, 1, 8, and 9 do not exist in the Base32 alphabet at all, so a common cause is accidentally swapping 0 for O or 1 for I when typing.

The encoded result ends in one or more = signs and a target system rejects it: the trailing equals signs are padding required to round the output to a multiple of 8 characters. Many systems, including most 2FA apps, accept Base32 without padding, so you can safely strip the = characters if the destination field rejects them.

Decoding produces garbled or unreadable output: the input you pasted is probably not actually Base32, it may be Base64, hexadecimal, or some other encoding entirely. Check the source of the string before assuming this tool is broken.

Concerned about case sensitivity: decoding automatically converts lowercase letters to uppercase before processing, since standard Base32 is case-insensitive. This does not affect the accuracy of the encode or decode roundtrip for the underlying bytes.

Frequently Asked Questions

Why do 2FA apps use Base32?

Base32 is chosen for 2FA secrets because it can be safely typed by humans, it uses only uppercase letters and digits 2 to 7, avoiding look-alike characters like 0/O and 1/l. It's also case-insensitive, reducing transcription errors when users manually type their secret key.

What is the difference between Base32 and Base64?

Base64 uses 64 characters (A to Z, a to z, 0 to 9, +, /) producing about 33% overhead. Base32 uses only 32 characters, producing about 60% overhead but is case-insensitive and more human-friendly for typed input. Base64 is more efficient, Base32 is more readable.

Why does my Base32 string end in = signs?

Base32 pads the output to a multiple of 8 characters using = signs. Like Base64 padding, it's required by the spec but some implementations, including most 2FA apps, accept Base32 without padding, both forms decode to the same result.

Can I decode a 2FA secret key with this tool?

Yes, since 2FA secret keys are themselves Base32 strings, you can paste one into decode mode to see the raw underlying bytes. This is rarely needed for normal use but can help when debugging a custom TOTP implementation.

Is Base32 the same as Base32hex?

No. RFC 4648 defines two different Base32 alphabets. This tool uses the standard alphabet (A to Z, 2 to 7) used by 2FA apps. Base32hex uses a different character set (0 to 9, A to V) and is mainly seen in DNSSEC and some legacy systems, the two are not interchangeable.