Base32 Encoder and Decoder

Base32 represents binary data using 32 characters, the ten digits 2-7 and the 26 uppercase letters, with no 0/O or 1/I to avoid reading mistakes. That makes it ideal for anything a human has to type or read aloud: two-factor TOTP secrets, voucher codes, case-insensitive identifiers. This tool encodes text to Base32 and decodes it back, following RFC 4648 with standard = padding.

How to encode or decode Base32

  1. 1

    Paste the text to convert

    Input is treated as bytes. UTF-8 is the default interpretation for text input.

  2. 2

    Pick direction

    Encode to turn raw bytes into a Base32 string; decode to recover the bytes.

  3. 3

    Note the padding behavior

    RFC 4648 pads the encoded output with `=` up to a multiple of 8 characters. The decoder accepts both padded and unpadded input.

  4. 4

    Copy the result

    Encoded output is uppercase, padded with `=` to a multiple of 8 characters.

The RFC 4648 alphabet

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 2 3 4 5 6 7

No 0, no 1, no 8, no 9. Each character encodes 5 bits (2^5 = 32), so 5 input bytes become 8 output characters.

Worked example

Encoding the ASCII string foo (bytes 0x66 0x6F 0x6F = 01100110 01101111 01101111):

  1. Chunk into 5-bit groups: 01100 11001 10111 10110 1111 (last group padded)
  2. Map to alphabet: M Z X W 6
  3. Add === padding to reach 8 characters: MZXW6===

Padding and length rules

Input bytes Output length Padding
1 8 ======
2 8 ====
3 8 ===
4 8 =
5 8 (none)

Variants beyond RFC 4648

  • Base32 Hex, Alphabet 0-9A-V, used by NSEC3 in DNSSEC.
  • Crockford’s Base32, Alphabet optimised for human typing; substitutes O0, I/L1 on decode. Used by ULIDs and some license keys.

This tool implements standard RFC 4648 only; use a dedicated converter for the variants above.

TOTP secrets

The otpauth:// URI format used by Google Authenticator and every modern 2FA app encodes the shared secret in Base32 without padding. When you scan a QR for “My Service”, the secret= parameter is a Base32 string. Decode it with this tool to inspect the raw bytes the HMAC uses.

Frequently Asked Questions

Base32 is case-insensitive and avoids look-alike characters, which matters for anything a human reads or types. Base64 is denser (fewer characters for the same bytes) but requires you to distinguish I from l and 0 from O, which fails in handwriting and small print.

RFC 4648 specifies padding for encoding. This tool always pads its encoded output with = to a multiple of 8 characters. Most real-world consumers (TOTP apps, ULID libraries, DNSSEC resolvers) accept unpadded input, and the decoder here accepts both padded and unpadded forms.

Standard Base32 has no 0, 1, 8 or 9 and is always uppercase. The decoder silently ignores any character outside the RFC 4648 alphabet, so lowercase or exotic input decodes to the wrong bytes. Normalize the input to uppercase letters A-Z and digits 2-7 before decoding.

Yes, the text travels to the page’s server so the result can be computed, and in the multi-step view the same text is also carried in the step link. It is not stored or logged.

Related Tools

Tool available in other languages