Base32 Encoder
Encode text or hex bytes to Base32 (RFC 4648) with the standard A–Z2–7 alphabet or base32hex. UTF-8 safe, optional padding, runs in your browser.
24 characters · 28 bytes (UTF-8)
0 characters · 0 bytes (UTF-8)
Runs entirely in your browser. Your data is never uploaded.
What is Base32 Encode?
Encodes text or raw bytes with Base32 from RFC 4648. Base32 uses only uppercase letters and digits 2–7, so it is case-insensitive and avoids easily confused characters – that is why it is used for TOTP secrets, onion addresses and file systems that ignore case.
How to use Base32 Encode
- Enter text in Input, or choose Hex bytes as Input format for raw bytes.
- Pick the Alphabet: Standard (A–Z, 2–7) or Extended hex (0–9, A–V).
- Keep or remove Add = padding.
- Copy the Base32 from Output.
Example
foobar
MZXW6YTBOI======
RFC 4648 §10 test vector; base32hex gives CPNMUOJ1E8======.
When to use Base32 Encode
Choose Base32 when the encoded value may be typed by humans, compared case-insensitively or used in DNS names and file names. It is 60% larger than the input (vs. 33% for Base64), so use Base64 when size matters and case is preserved.
How Base32 Encode works
Bytes are read as a bit stream and cut into 5-bit groups; each group (0–31) selects one alphabet character. Five input bytes (40 bits) give exactly eight characters. A shorter final block is zero-filled to a full 5-bit group and the output is padded with = to a multiple of 8 characters. Text is converted to UTF-8 first.
Common Use Cases
- Creating TOTP/2FA secrets for authenticator apps
- Generating case-insensitive identifiers
- Encoding data for DNS labels or case-insensitive file systems
- Testing RFC 4648 implementations against known vectors
FAQs
What is base32hex?
The "Extended Hex" alphabet from RFC 4648 §7 (0–9, A–V). It keeps the sort order of the original bytes and is used in DNSSEC NSEC3 records.
Is Base32 the same as Crockford Base32?
No. Crockford Base32 uses a different alphabet without I, L, O and U; this tool implements the RFC 4648 alphabets.
Should I keep the = padding?
Keep it for strict RFC 4648 consumers. TOTP secrets are usually shown without padding, and most decoders (including ours) accept both.