Base32 Encode / Decode

Overview

Encodes and decodes Base32 using the RFC 4648 standard alphabet A to Z plus the digits 2 through 7, with = padding added on encode. Input is treated as UTF-8 bytes in both directions, so emoji and non-Latin text survive the round trip. A toggle switches between encode and decode, and the output recomputes on every keystroke entirely in your browser.

How It Works

Pick Encode or Decode. On encode, type or paste any text and the Base32 string appears immediately, padded with = characters to a multiple of eight. On decode, paste a Base32 string; the tool strips the padding, maps each character through the 32-symbol alphabet, and decodes the reconstructed bytes back as UTF-8. Invalid characters produce an explicit Invalid result rather than a silently wrong value, and clicking the output area copies it.

Step-by-Step Usage Guide

1. Select the Encode mode and paste your text, or select Decode and paste a Base32 string.
2. Read the converted result in the lower panel; it updates as you type.
3. Check for = padding on encoded output; it is expected, not an error.
4. Click the output panel to copy the result.

Technical Specifications & Standards

Base32 regroups data at the bit level: every 5 bytes (40 bits) become exactly 8 alphabet characters, each representing 5 bits. That 5-to-8 ratio is why Base32 output is about 60 percent longer than the input, versus the 33 percent overhead of Base64, and why the encoder here zero-pads the final bit group and then pads the string with = to a full 8-character block. RFC 4648 also defines a second alphabet, base32hex (0-9, A-V), which sorts numerically; this implementation implements only the standard alphabet, so base32hex input containing digits beyond 7 will be rejected. Decoding is deliberately lenient about case and padding: lowercase letters are uppercased before the alphabet lookup and trailing = signs are discarded, but the decoder keeps only whole bytes and silently drops a trailing partial byte, matching how most decoders handle unpadded input. One everyday reason this alphabet matters: TOTP two-factor secrets are Base32 by convention because the alphabet excludes 0, 1, 8 and 9, characters that are easy to misread or mistype when a user transcribes a secret by hand.

Targeted Use Cases

• Preparing TOTP secrets in the form authenticator apps expect.
• Encoding data for systems and DNS records that are case-insensitive and dislike mixed case.
• Debugging provisioning strings from cloud providers that ship Base32 credentials.
• Cross-checking a Base32 encoder in another language against a reference implementation.

Notes & Gotchas

• Strip spaces and line breaks from pasted secrets before decoding; the decoder rejects them.
• Use the standard alphabet here only; do not feed it Crockford Base32, which substitutes letters for digits differently.
• When comparing outputs, keep RFC 4648 block padding on both sides so lengths are comparable.
• Remember the 60 percent size overhead and do not use Base32 for large payloads where Base64 would do.

Frequently Asked Questions