Base32 Encoder / Decoder

What RFC 4648 Base32 is

Base32 is a binary-to-text encoding that represents arbitrary bytes with the letters A through Z and the digits 2 through 7. It is defined in RFC 4648 alongside Base16 and Base64. Five input bits become one output character, so the alphabet needs exactly thirty-two symbols. The result is longer than Base64, but it avoids punctuation, is usually easy to read aloud, and works in environments that prefer case-insensitive alphanumeric identifiers.

This page treats the source as Unicode text and converts it to UTF-8 bytes before Base32 encoding. That detail matters for accented letters, CJK text, emoji, and every character outside plain ASCII. A converter that encodes JavaScript UTF-16 code units directly can produce values that no other UTF-8 tool understands. Decoding follows the reverse path: Base32 symbols become bytes, and the bytes must form valid UTF-8 before they are displayed as text.

The padding switch controls only the trailing equals signs. RFC 4648 pads output to a multiple of eight characters, but many systems omit padding when the length is already known. The decoder accepts both forms while still checking that the final unused bits are zero. That canonical check prevents several different strings from silently representing the same byte sequence.

How to use the Base32 converter

1. Choose Encode when the input is normal text, or Decode when the input already uses the Base32 alphabet.
2. For encoding, decide whether the receiving system expects RFC-style equals-sign padding. Leave padding enabled when a protocol explicitly requires fixed eight-character blocks.
3. Enter or paste the value. Conversion updates in the browser, and an error is shown instead of guessing when the alphabet, length, padding, or UTF-8 bytes are invalid.
4. Compare the result with one of the official vectors or Unicode examples. This is useful when validating another library, command-line tool, or API implementation.
5. Copy the result or swap direction to verify a round trip. A successful round trip confirms text recovery, but it does not prove that a separate protocol uses the same padding policy.

Base32 examples and official vectors

These examples combine RFC 4648 test vectors with Unicode and padding cases. Use the example buttons above to reproduce each conversion with the relevant direction and option.

Accepted input, padding, and canonical form

Encoding accepts any well-formed JavaScript string and uses the browser’s UTF-8 encoder. Decoding accepts A-Z, 2-7, optional lowercase letters, and an optional trailing run of equals signs. Spaces and line breaks are rejected deliberately because RFC 4648 does not require decoders to ignore arbitrary formatting characters. Removing whitespace automatically can hide copy errors in secrets or identifiers.

Unpadded lengths are not arbitrary. The number of data characters modulo eight can be 0, 2, 4, 5, or 7. Other remainders cannot correspond to a whole number of bytes. When padding is present, its count must match the final quantum: six, four, three, one, or zero equals signs respectively.

• Canonical encoder output uses uppercase A-Z and digits 2-7.
• Padding may appear only at the end and the total padded length must be divisible by eight.
• The digits 0, 1, 8, and 9 are not part of the RFC 4648 alphabet.
• Non-zero leftover bits are rejected instead of being discarded.
• Decoded arbitrary binary data may fail when it is not valid UTF-8 text.

How the Base32 algorithm processes bytes

The encoder reads the UTF-8 byte stream from left to right and collects bits in a small buffer. Whenever at least five bits are available, it removes the next five-bit value and uses that value as an index in the Base32 alphabet. If the final byte does not end on a five-bit boundary, the remaining bits are shifted toward the high side and zero bits fill the unused positions. Optional padding then extends the character count to an eight-character boundary.

The decoder maps every symbol back to a value from zero to thirty-one, appends those five bits to its buffer, and emits a byte whenever eight bits are available. The bytes are not interpreted as ASCII; they are decoded with a strict UTF-8 decoder. This distinction is why a string such as 你好 can round-trip correctly even though each character needs three UTF-8 bytes.

Strict validation happens before and after the bit loop. The parser checks the alphabet, allowable remainder, and exact padding count. At the end it verifies that bits which did not contribute to a complete byte are zero. RFC 4648 calls for rejecting non-alphabet characters unless a referring specification explicitly says otherwise, so this tool favors predictable protocol testing over permissive cleanup.

When Base32 is a practical choice

Base32 is useful when a value must remain text-only but punctuation or case sensitivity is inconvenient. It is not encryption and it does not provide integrity, so applications often combine it with a checksum, MAC, or a protocol-specific wrapper.

Common Base32 errors and boundaries

Most failures come from mixing alphabets, copying incomplete data, or applying a padding policy from a different system. A value can look plausible while still ending in an impossible number of symbols. The converter reports that condition instead of adding or deleting data characters.

A second boundary appears after decoding: Base32 represents bytes, not necessarily text. If the bytes are a compressed file, key, hash, or random secret, they may not be valid UTF-8. This text-focused page then reports an invalid UTF-8 result; a byte-oriented application should keep the decoded Uint8Array instead.

• Using 0 or 1 where O or I was intended produces an invalid-character error.
• A single data character cannot encode a complete byte and is rejected.
• Padding in the middle of a value is always invalid.
• Changing the final symbol can create non-zero unused bits even when the visible length looks correct.
• Base32 output is not confidential and can be decoded by anyone.

Base32 compared with related encodings

Choose an encoding based on the transport constraints, not on visual preference alone. Base32 spends more characters to obtain a smaller and more transcription-friendly alphabet. Base64 is denser, while Base58 removes visually ambiguous characters but uses big-integer conversion rather than fixed bit groups.

Do not assume that every string called Base32 uses this alphabet. Crockford Base32, base32hex, z-base-32, and protocol-specific variants choose different symbols or error-handling rules. This page implements the standard RFC 4648 alphabet only.