Which Base32 alphabet does this use?

It uses the standard RFC 4648 alphabet: the uppercase letters A–Z and the digits 2–7, with = for padding. This is the same encoding used by TOTP authenticator secrets.

How does Base32 encoding work?

It reads the input as a stream of bits and regroups them into 5-bit chunks (2^5 = 32), mapping each chunk to one alphabet character. Every 40 bits of input become 8 characters, and the output is padded with = signs to a multiple of 8.

Why is Base32 used instead of Base64?

Base32 is case-insensitive and avoids easily confused characters, so it survives being typed by hand, spoken aloud or stored in case-insensitive systems like DNS. It is less compact than Base64 but more robust.

Why are 0, 1, 8 and 9 missing from the alphabet?

The RFC 4648 alphabet deliberately omits digits that look like letters (0/O, 1/I/l) to reduce transcription errors. It keeps only 2–7 alongside A–Z to make 32 unambiguous symbols.

Is decoding case-sensitive?

No. The decoder upper-cases your input first, so both lowercase and uppercase Base32 decode correctly. Whitespace and trailing = padding are ignored.

Why is my Base32 longer than the original text?

Base32 packs 5 bits per character versus 8 bits per byte of input, so encoded output is about 60% larger than the raw text. That is the trade-off for being case-insensitive and DNS-safe.

No — encoding and decoding happen entirely in your browser with no network requests.

What is the Base32 Encoder & Decoder?

Free Base32 encoder and decoder using the RFC 4648 alphabet. Convert text to and from Base32 for TOTP secrets and DNS-safe data — runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Base32 Encoder & Decoder

Name: Base32 Encoder & Decoder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Base32 encoder and decoder (RFC 4648)

Base32 encodes binary data using 32 case-insensitive characters — the uppercase letters A–Z and the digits 2–7 — defined in RFC 4648. Because it avoids ambiguous characters and is case-insensitive, it is ideal for values that may be typed by hand or read aloud, such as TOTP two-factor secrets and DNS-safe identifiers.

How it works

To encode, the tool converts your text to UTF-8 bytes, then treats those bytes as one long bit stream and slices it into 5-bit groups. Each group (0–31) maps to one alphabet character. Since 5 and 8 do not divide evenly, the output is padded with = until its length is a multiple of 8. Decoding reverses the process: each character contributes 5 bits, which are reassembled into 8-bit bytes and decoded as UTF-8. The decoder upper-cases input and ignores whitespace and padding.

Why 2–7 and not 0–9?

The RFC 4648 Base32 alphabet uses the digits 2 through 7 — skipping 0 and 1 — to avoid confusion with the letters O (looks like 0) and I or L (look like 1). The result is a 32-character alphabet where every symbol is unambiguous enough for a human to transcribe or speak. This is the key distinction from Base64, which includes both + and / and requires URL encoding.

Example

Encoding the text Gera:

Gera → bytes 47 65 72 61 → I5SXEYI= (after padding)

Input	Base32 encoded
`A`	`IE======`
`Hi`	`JBUQ====`
`Gera`	`I5SXEYI=`

Note the = padding characters at the end. Each = represents bits that were added to reach a complete 5-bit group; the decoder strips them before reconstructing the bytes.

The TOTP secret use case

TOTP authenticator apps (Google Authenticator, Authy, and others) store shared secrets as Base32-encoded strings. When you scan a QR code to set up two-factor authentication, the underlying data is a URL containing a Base32 secret. Tools for debugging or migrating TOTP configurations need to decode those secrets back to raw bytes. This encoder/decoder handles that round-trip: paste the Base32 secret to see its raw bytes, or paste raw bytes to get the Base32 form to re-encode.

Base32 vs alternatives

Encoding	Alphabet size	Output overhead	Portable	Case-insensitive
Base32 (RFC 4648)	32	+60%	Yes (IETF)	Yes
Base64	64	+33%	Yes (IETF)	No
Crockford Base32	32	+60%	No (de facto)	Yes (with corrections)
Hex (Base16)	16	+100%	Yes	Yes

Base32 is the right choice when compactness matters less than human-safety and DNS/case-insensitivity compatibility. For smaller overhead at the cost of URL-safety, use Base64url.

Everything runs in your browser — your data is never uploaded.