Encode and decode Base32

Base32 in two alphabets.

Encode and decode text using standard Base32 (RFC 4648 A-Z2-7=) or the Base32-Hex alphabet (RFC 4648 0-9A-V=). Pure browser; no upload.

Output

Base32: an encoding people can read aloud

Base32 writes bytes using 32 characters: the letters A to Z and the digits 2 to 7. It drops the lowercase letters and the digits 0, 1, 8 and 9, which are easy to confuse with O, I, B and g, so the result survives being typed by hand, read over the phone or used in places that ignore letter case, such as file names on Windows and DNS names.

That robustness is why the secret keys behind authenticator apps, the codes in many licence keys and some file-sharing links use Base32. This tool encodes text to Base32 and decodes it back, in the standard alphabet or the extended hex alphabet, from RFC 4648.

How to use it

  1. Choose a direction: Encode to Base32 or Decode from Base32.
  2. Choose the alphabet. Standard (A–Z, 2–7) is what you will meet almost everywhere; Hex (0–9, A–V) keeps the sort order of the original bytes.
  3. Type or paste into the input box. The output updates as you type.
  4. Copy the result. Spaces and line breaks in pasted Base32 are ignored when decoding.

Example: three bytes in both alphabets

Input
Hi!
Output
Standard: JBUSC===
Extended hex: 91KI2===

Three bytes are 24 bits, which fill four characters of 5 bits each with 4 bits left over. A fifth character carries those, and three = signs pad the result to a multiple of eight.

How Base32 compares with Base64

Each Base32 character carries 5 bits, against 6 for Base64, so Base32 output is about 60% longer than the input instead of 33%. You pay that extra length for an alphabet without lowercase letters or look-alike symbols, and without + and /, which have special meanings in URLs and file paths.

Use Base64 when only machines read the data and size matters. Use Base32 when people will type it, when the medium is case-insensitive, or when the value has to be safe in a domain name.

Authenticator app secrets

When a site shows a QR code to set up two-factor authentication, the code contains a link with a secret= parameter, and that secret is Base32. The app decodes it into the raw key it uses to compute the six-digit codes. Many sites also print the secret as text, in groups of four letters, for people who cannot scan the code. Treat that secret like a password: anyone who has it can generate your codes.

Padding and the hex alphabet

Base32 works on groups of five bytes, which become eight characters. When the input does not fill the last group, the encoder pads the output with = signs. Many systems, including authenticator secrets, leave the padding off; this decoder accepts input with or without it. The extended hex alphabet uses 0–9 and A–V so that encoded values sort in the same order as the bytes they encode, which some databases rely on.

Questions

Is Base32 encryption?

No. It is a reversible encoding with no key, so anyone can decode it. It only makes bytes safe to write down.

Why does decoding fail?

The input uses the other alphabet, contains a character outside it such as 0, 1 or 8 in standard Base32, or decodes to bytes that are not valid UTF-8 text.

Does case matter?

The alphabets are upper case. Convert lowercase input to upper case before decoding, as many authenticator apps do automatically.