Home › Developer Tools › Base32 Encoder / Decoder

Base32 Encoder / Decoder

Encode text, hex bytes or a file to Base32, or decode Base32 back to text or hex. Supports the standard RFC 4648 alphabet, Base32hex, Crockford's Base32 and z-base-32, with optional padding and lowercase output.

Alphabet

Input Padding (=) Lowercase Wrap

Text to encode

Base32 output

All Base32 variants for this input

How to use the Base32 Encoder / Decoder

Choose Encode or Decode with the tabs at the top.
Pick the Base32 variant: RFC 4648 is the common one (used by TOTP secrets), Base32hex keeps sort order, Crockford is human-friendly.
Enter your input: type text, paste hex bytes (set Input to Hex), or click Encode a file.
Adjust options such as padding, lowercase and line wrapping. The result updates instantly.
Copy or download the output, or press Swap to feed the result back as input.

How Base32 encoding works

Base32 reads the input as a stream of bits and splits it into groups of 5 bits. Each group (a value from 0 to 31) becomes one character of the alphabet. Five bytes (40 bits) map exactly to eight characters; if the input does not end on a 5-byte boundary, the last group is padded with zero bits and, in RFC 4648 Base32, the output is filled up to a multiple of 8 characters with =.

Example: Hi is the bytes 0x48 0x69 = 01001000 01101001. Regrouped into 5-bit chunks: 01001 00001 10100 1(0000) = 9, 1, 20, 16 → J B U Q, then padding gives JBUQ====.

Input bytes	Output characters	Padding
1	2	`======` (6)
2	4	`====` (4)
3	5	`===` (3)
4	7	`=` (1)
5	8	none

Base32 alphabets compared

Variant	Alphabet (values 0 to 31)	Padding	Used by
RFC 4648 Base32	`ABCDEFGHIJKLMNOPQRSTUVWXYZ234567`	Yes	TOTP/2FA secrets, onion addresses, many APIs
Base32hex	`0123456789ABCDEFGHIJKLMNOPQRSTUV`	Yes	DNSSEC NSEC3 hashes; preserves sort order
Crockford	`0123456789ABCDEFGHJKMNPQRSTVWXYZ`	No	ULIDs, human-readable codes
z-base-32	`ybndrfg8ejkmcpqxot1uwisza345h769`	No	Tahoe-LAFS, Mnet, some key fingerprints

Test vectors from RFC 4648

Use these to check any Base32 implementation: "f" → MY======, "fo" → MZXQ====, "foo" → MZXW6===, "foob" → MZXW6YQ=, "fooba" → MZXW6YTB, "foobar" → MZXW6YTBOI======. In Base32hex, "foobar" is CPNMUOJ1E8======.

Frequently asked questions

What is Base32?

Base32 is a binary-to-text encoding that represents every 5 bits with one of 32 characters. RFC 4648 defines the standard alphabet A-Z and 2-7, with = padding so the output length is a multiple of 8 characters. Every 5 input bytes become 8 output characters, so Base32 is 60% larger than the input.

Base32 vs Base64: when should I use Base32?

Base64 is more compact (33% overhead versus 60%), but Base32 uses a single case and avoids symbols, so it survives case-insensitive systems, file names, DNS labels and being read aloud or typed by hand. That is why authenticator apps use Base32 for TOTP secrets.

What is the difference between Base32 and Base32hex?

Both come from RFC 4648 and use the same bit layout. Base32hex uses the alphabet 0-9 and A-V, so encoded strings sort in the same order as the original bytes. Standard Base32 uses A-Z then 2-7.

What is Crockford's Base32?

Douglas Crockford's variant uses 0-9 and A-Z without I, L, O and U, so it avoids characters that are easy to confuse. Decoders treat O as 0 and I or L as 1, ignore hyphens, and are case-insensitive. ULIDs use this alphabet.

Do I need the = padding?

Padding makes the length a multiple of 8, which some strict decoders require. Many systems (TOTP secrets, Crockford, z-base-32) omit it. This decoder accepts input with or without padding.

Why does decoding show hex instead of text?

If the decoded bytes are not valid UTF-8, they are probably binary data (an image, a key or a hash), so the tool shows them as hex. You can also download the raw bytes as a file.

Is my data uploaded?

No. Encoding and decoding run entirely in your browser with JavaScript, including files.

Related tools