Base32 is the quiet workhorse of the encoding world: it turns arbitrary bytes into a short alphabet of capital letters and the digits 2–7, so the result survives being read aloud, typed by hand, printed in a manual or stored in systems that mangle case and punctuation. You meet it in two-factor authentication secrets, in DNS-based protocols, and in identifiers designed to be error-resistant. This Base32 encoder and decoder implements the standard RFC 4648 encoding exactly — the same one the RFC’s own test vectors define — with full UTF-8 handling, so accented characters and emoji encode correctly as their byte sequences. Encoding uses the canonical alphabet with = padding; decoding is forgiving about lowercase input, spaces and missing padding, but strict about characters outside the alphabet, and it tells you which character broke the rules. Everything runs in your browser: a TOTP secret pasted here never leaves your machine, which is precisely how a tool that touches secrets should behave.
How Base32 encoding works
Base32 processes the input five bytes (40 bits) at a time and splits those 40 bits into eight groups of five — each group indexes the 32-character alphabet, so five bytes become eight characters. A short final group is padded with = signs to a multiple of eight characters: one leftover byte gives two characters and six padding signs, two bytes give four and four, three bytes give five and three, four bytes give seven and one. The RFC 4648 test vectors pin the behaviour exactly: “f” encodes to MY======, “fo” to MZXQ====, “foo” to MZXW6===, “foob” to MZXW6YQ=, “fooba” to MZXW6YTB and “foobar” to MZXW6YTBOI====== — the tool above is preloaded with “foobar” so you can watch the last of those appear. Decoding reverses the bit packing; leftover partial bits that cannot form a byte are discarded, which is why a decoder can accept input whose padding was stripped.
Base32 versus Base64 (and Base32hex)
Base64 is denser — three bytes become four characters instead of five becoming eight — so Base32 output is about 60% longer than the original where Base64 is about 33% longer. You pay that size for robustness: Base32’s alphabet contains no lowercase, no + or / or other symbols that get mangled in URLs, filenames, case-insensitive filesystems or human transcription, and it avoids characters that look alike in most fonts (there is no 0 to confuse with O, no 1 to confuse with I — those digits are deliberately absent). A separate variant, Base32hex, uses digits 0–9 then letters A–V so that encoded values sort in the same order as the original data; it is a different alphabet, and this tool implements the standard Base32 of RFC 4648, not Base32hex — decoding one with the other produces garbage, a distinction worth checking whenever a spec just says “base32”.
Where you will actually meet it
The most common encounter is the TOTP secret: when a site shows you a string like JBSWY3DPEHPK3PXP to type into an authenticator app (that example literally decodes to “Hello!Þ¾ï” — the classic test string), it is Base32 because a human might have to type it. Tor’s onion service addresses are Base32. Some licence keys, recovery codes and device pairing codes choose it for the same read-aloud safety. When you decode a Base32 string here and get binary-looking output, that is usually correct behaviour — the payload was bytes, not text — though if the bytes are not valid UTF-8 this decoder will tell you rather than print mojibake, which is the honest failure mode for a text tool.
Frequently asked questions
Is lowercase Base32 valid?
The RFC writes the alphabet in uppercase, but decoders conventionally accept lowercase. This tool uppercases before decoding, so pasted lowercase works; encoding always produces the canonical uppercase with padding.
Why does the decoder reject my string?
Either it contains a character outside A–Z and 2–7 (0, 1, 8 and 9 are the usual suspects — they are not in Base32), or it decoded to bytes that are not valid UTF-8 text. The status line names the offending character in the first case.
Can it handle the padding being missing?
Yes — padding is stripped before decoding and the bit math does not need it. Encoded output always includes the canonical padding.
Is it safe to paste a real TOTP secret?
The tool runs entirely in your browser tab with no network calls, and nothing is stored. That said, treat authenticator secrets like passwords as a matter of habit: use the tool, then close the tab.
Related tools
Versión en español: Codificador y Decodificador Base32 — Base32 RFC 4648 en tu Navegador. You may also like: JWT Decoder Tool — Read JWT Headers and Payloads Safely Online · JSON to XML Converter — Turn JSON Data into Clean XML Online.
Embed this tool on your website — free
Copy the code below to add this working tool to your own page. A small credit link stays with it — that’s all we ask.