1. Home
  2. Developer tools
  3. Base32 Encoder

Base32 Encoder

Base32 writes bytes using 32 characters that survive case changes and avoid look-alikes, which is why authenticator apps use it for secret keys. Encode or decode text or hex, and choose the alphabet and padding.

Free, no sign-up. Runs in your browser: nothing is uploaded.

How to use Base32 Encoder

  1. Choose encode or decode.
  2. Pick the alphabet and whether to pad with =.
  3. Paste text or bytes and copy the result.

Features

  • RFC 4648 standard alphabet and the extended hex alphabet
  • Optional = padding on output, tolerant on input
  • Reads and writes text as UTF-8 or as hex bytes
  • Case-insensitive decoding and ignored spaces
  • Names the first invalid character
  • Shows the byte count

Supported formats

Input

  • Typed or pasted text

You get

  • Base32

Private by design

Everything you enter is processed by your browser on this device. Nothing is sent to openWorkstand or anyone else, so the Base32 Encoder is safe for private and work data. After you have used it once while online, it also works without an internet connection. How local processing works

Good to know

  • Base32 is an encoding, not encryption: anyone can decode it.
  • Text is encoded as UTF-8; for other character sets, enter the bytes as hex.

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.

Checked against the current version of the Base32 Encoder on .

Frequently asked questions

Why do authenticator apps ask for a secret in Base32?

The key is meant to be typed or read aloud as well as scanned. The Base32 alphabet has no lower case and leaves out 0, 1, 8 and 9, so letters cannot be confused with digits, and a secret survives being written down.

Can the same secret be written with and without the equals signs?

Yes. The = characters only pad the last block to eight characters and carry no data. Most authenticator apps accept the secret without them, and a decoder that needs them can add them back from the length.

How is Base32 different from Base64?

It uses 5 bits per character instead of 6, so the output is about 60% longer than the input, but it is case-insensitive and contains no symbols that need escaping.

Why do authenticator secrets look like Base32?

The TOTP key URI format specifies Base32 for the secret parameter, because people sometimes type the key by hand and the alphabet has no 0, 1, 8 or 9 to confuse.

Keep working with the result

openWorkstand also includes a free workspace with documents, spreadsheets, tasks, projects and a calendar that save to a folder on your computer.