Base32 Encode
Encode text to RFC 4648 Base32, with optional Base32hex alphabet and padding control.
Input
Output
Where Base32 is used
Base32 uses 32 characters — A–Z and 2–7 — chosen so the result survives case-insensitive systems and is readable aloud without ambiguity. That is why TOTP secrets in authenticator apps, onion addresses and some DNS records use it rather than Base64.
The trade-off is size: Base32 expands data by 60%, against Base64’s 33%.
- RFC 4648 standard: A–Z, 2–7. The default, used by TOTP and most protocols.
- RFC 4648 extended hex: 0–9, A–V. Sorts in the same order as the raw bytes.
- Crockford: omits I, L, O and U to avoid transcription mistakes, and accepts them as their look-alikes when decoding.
Frequently asked questions
Why does my TOTP secret not have padding?
Authenticator apps generally strip the = characters. Turn padding off when generating, and paste unpadded values freely when decoding — both are accepted.
Base32 or Base64?
Use Base64 when size matters and the transport is case-sensitive. Use Base32 when a human may have to read, type or dictate the value, or when the storage layer folds case.
Related tools
Base32 DecodeDecode RFC 4648 Base32 (or Base32hex) back to text or bytes, with a selectable output character set.Base64 EncodeEncode text or files to Base64, with standard or URL-safe alphabets and optional line wrapping.Base58 EncodeEncode data with the Bitcoin/IPFS Base58 alphabet, optionally with a Base58Check checksum.