Base32 Decode
Decode RFC 4648 Base32 (or Base32hex) back to text or bytes, with a selectable output character set.
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 EncodeEncode text to RFC 4648 Base32, with optional Base32hex alphabet and padding control.Base64 DecodeDecode Base64 back to text, choosing the character set (UTF-8, EUC-KR, Shift_JIS, GBK…) so the result reads correctly.Base64 EncodeEncode text or files to Base64, with standard or URL-safe alphabets and optional line wrapping.File to Base64 / Base64 to FileTurn any file into a Base64 string or a data URI, and turn Base64 back into a downloadable file.Base58 EncodeEncode data with the Bitcoin/IPFS Base58 alphabet, optionally with a Base58Check checksum.Base58 DecodeDecode a Base58 or Base58Check string back to bytes, hex or text.