Guide
Base32 encoding: alphabets, padding and authenticator secrets
Base64 is the best-known way to put binary data into text, but it has two awkward properties: it is case-sensitive, and it uses symbols such as + and / that mean something in URLs and file names. Base32 trades size for robustness. It uses only letters and digits, ignores case, and so survives being read over the phone, typed on a keyboard or stored on a system that lowercases everything.
How the encoding works
Base32 reads the input five bytes (forty bits) at a time and cuts those bits into eight groups of five. Each 5-bit value from 0 to 31 picks a character from a 32-letter alphabet. In the standard alphabet of RFC 4648, the values 0 to 25 are the letters A to Z and 26 to 31 are the digits 2 to 7. The digits 0, 1 and 8 are missing on purpose, so that O, I and B are not mistaken for numbers.
Padding
When the input is not a multiple of five bytes, the last block has fewer than eight characters, and the = sign fills it to eight. One byte gives two characters and six pads, two bytes give four and four, three bytes give five and three, four bytes give seven and one. The “Pad with =” switch controls this on output. When decoding, padding is optional.
The two alphabets
The standard alphabet is the one used by TOTP authenticator secrets, by onion addresses and by many tokens. The extended hex alphabet (“base32hex”) uses 0–9 and A–V instead, so that the sort order of encoded strings matches the sort order of the original bytes. It is used in some DNS record formats. The alphabet buttons switch between them, and the decoder checks the characters against the one you chose.
Using the page
Select encode or decode, pick whether the input is text or hex bytes, and paste. For text, the page encodes the UTF-8 bytes, so an accented letter takes two bytes. The result appears with the number of bytes read and characters produced, and can be copied or downloaded. When decoding, spaces, hyphens and lower-case letters are ignored, so a secret displayed in groups of four, such as JBSW-Y3DP, can be pasted as it is. An invalid character is reported with its position.
A worked example
The test vectors in RFC 4648 are the best check. Encoding the six characters “foobar” gives MZXW6YTBOI======: the first five bytes “fooba” produce the eight characters MZXW6YTB, and the last byte “r” produces OI plus six pad signs. The three characters “foo” give MZXW6===, and “f” alone gives MY======. Pasting any of these into the decoder returns the original text, and with the extended hex alphabet the same input gives different letters.
Limits
Base32 makes data about 60 percent longer, which is the price of its safety. It is an encoding, so anyone can reverse it, and it gives no protection to a secret. This page offers the standard and extended hex alphabets of RFC 4648 only; the Crockford variant and other custom alphabets are not included. The text mode assumes UTF-8, so to encode data in another character set, enter the bytes as hexadecimal instead.
Related tools
- Base64 Encoder is the denser alternative for binary data.
- Base64URL Encoder is the URL-safe form of Base64 used in tokens.
- Base58 Encoder avoids look-alike characters for addresses.
- Ascii85 Encoder is more compact than Base64.
Checked against the current version of the Base32 Encoder on .

