Base32 Encoder/Decoder

What Base32 Encoder/Decoder helps you do

Encode and decode Base32 text using the RFC 4648 alphabet common in OTP secrets, some DNS records, and legacy binary-to-text pipelines. The alphabet uses uppercase A–Z and digits 2–7, so a value is easy to read aloud and survives a case-insensitive copy. Padding and case handling follow the tool's on-page options.

Encoding and decoding run entirely in your browser. Input is not uploaded to Haivix.

How it works

Text is converted to bytes and grouped into 5-bit values, each mapped to the RFC 4648 alphabet. Decoding reverses the mapping and strips whitespace, and the input is uppercased so lowercase copies still work. The tool uses the standard alphabet, not the Base32hex variant.

How to use Base32 Encoder/Decoder

1. Enter plain text to encode or a Base32 string to decode.
2. Choose padding behavior if offered, then copy the output for configs or tests.
3. Download decoded bytes if the result is not readable text.
4. Check the value against the protocol's expected alphabet before using it.

When to use it

• Format TOTP shared secrets for authenticator app setup docs.
• Translate Base32 test fixtures when validating codec implementations.
• Recover binary data from Base32 logs without command-line utilities.
• Check a secret for characters outside the A–Z and 2–7 alphabet.
• Encode a small fixture for a DNS or legacy protocol test.
• Compare a library's output with a known test vector.
• Encode a short binary fixture for a legacy protocol test.
• Read a Base32 secret aloud without ambiguous characters.

When not to use it

• Do not use Base32hex data here; the alphabet is different.
• Do not treat the secret as safe to paste into a shared document.
• Do not use Base32 for large files when a binary format would do.

Example

A TOTP setup value is pasted and decoded to confirm it contains only valid characters. A second value containing a 1 fails, which explains why the authenticator app rejected it. The corrected secret is used to generate the setup instructions.

What you can do with Base32 Encoder/Decoder

• Encode text or a file to RFC 4648 Base32.
• Decode Base32 back to text or bytes.
• Use the uppercase A–Z and 2–7 alphabet.
• Ignore whitespace when decoding a pasted secret.
• Accept lowercase input by normalizing case.
• Download decoded bytes when the result is binary.
• Strip spaces before decoding a pasted secret.

Example: format a TOTP secret for setup docs

Paste the shared secret into the decoder to confirm it is valid Base32. A secret with a stray 0 or 1 is not in this alphabet and will fail.

Encode a test value to see the expected length and padding before writing the setup instructions.

Keep the real secret out of documentation. Use a placeholder or a test vector when showing the format to users.

What to know before you start

• Standard RFC 4648 alphabet only; Base32hex is not supported.
• Large files are limited by browser memory.
• The tool does not validate a TOTP code or a secret's entropy.
• No checksum is added to the encoded value.
• Padding behavior may differ from a specific server's expectation.

Common mistakes

• Pasting a Base32hex value and expecting the standard decoder to read it.
• Leaving spaces in the middle of a secret and assuming they are significant; they are stripped.
• Confusing the digit 0 with the letter O, which is not in the alphabet.
• Publishing a real TOTP secret in a screenshot.
• Assuming padding is always required by every server.
• Assuming Base32 padding is always optional for every server.
• Using a Base32 value from a QR code without removing line breaks.
• Confusing Base32 with Base64 in a config file.

Troubleshooting

If decoding fails, check for 0, 1, 8 or 9 in the value; they are not part of the standard alphabet.

If a secret works in one app but not another, compare the padding and case handling expected by each.

If the decoded output is binary, download it rather than reading it as text.

If the value came from a QR code, confirm that the scanner did not add spaces or newlines.

If the length looks wrong, Base32 groups bits in fives, so the encoded length is not the same as the byte length.

If a TOTP secret contains lowercase letters, the decoder uppercases them; the authenticator app should do the same. If it does not, enter the uppercase form when enrolling.

If a secret has an equals sign in the middle, the paste is likely truncated or combined from two values; split it before decoding.

Related standards and documentation

• RFC 4648 defines Base32 and its padding rules.
• RFC 6238 defines TOTP, which commonly uses a Base32 shared secret.