Base32 Encode / Decode
Convert UTF-8 text with RFC 4648 Base32
Choose encode or decode, paste text or a Base32 string, then convert it first; scenarios and fix hints are available in Advanced mode.
The full guide also includes pitfalls, worked examples, snippets, FAQs, and related tools for checking results or troubleshooting.
About this tool
This text converter uses the RFC 4648 alphabet A–Z and 2–7. Encoding preserves text whitespace and emits uppercase padded Base32. Decoding ignores whitespace and case, accepts omitted padding, and rejects impossible lengths, incorrect explicit padding, and nonzero pad bits. Output must be valid UTF-8 text; this interface does not accept raw byte input or inspect arbitrary OTP secret bytes. Processing is local without saved input drafts.
Production Snippets
RFC 4648 final blocks and strict decoding
text
f → MY======
foo → MZXW6===
foobar → MZXW6YTBOI======
Decode lowercase my without padding → f
M: impossible symbol count
MZ======: nonzero pad bits; rejected by this decoderFrequently Asked Questions
Which Base32 variant is supported?
RFC 4648 A–Z and 2–7. Base32hex and Crockford Base32 use different alphabets and are not supported here.
Can padding be omitted?
Yes. The final number of data symbols modulo eight must be 0, 2, 4, 5, or 7. If = is present, its count must match that final block.
Why reject nonzero pad bits?
The encoder must emit zero pad bits under RFC 4648. Rejecting nonzero pad bits is this decoder’s strict policy; the RFC permits, rather than requires, that decoder behavior.
Can this reveal every authenticator secret as text?
No. OTP secrets are arbitrary bytes and may not be UTF-8. A decoding error here does not prove an authenticator secret is invalid.
Is Base32 confidential or more compact than Base64?
No confidentiality is provided. Base32 generally uses more characters than Base64 for the same bytes, with a smaller alphabet.
Keep browsing