Base32 Decoder Guide: Turn Base32 Text Back Into Readable Data

Base32 looks like a jumble of capital letters and digits, such as NBSWY3DP, and it appears in places where binary data must travel as plain text: one-time password secrets, certain tokens and configuration values, and systems that restrict characters to a safe alphabet. The Base32 Decoder turns such a string back into the original bytes, shown as text where the bytes are printable. Understanding the alphabet and the padding rules lets you decode confidently and recognise errors instead of guessing at garbled output.

Base32 encodes binary data in groups of 5 bits. Since 2 to the power of 5 equals 32, each group maps to one of 32 symbols. The standard RFC 4648 alphabet uses the capital letters A to Z for values 0 to 25, and the digits 2 to 7 for values 26 to 31. Digits 0, 1, 8 and 9 never appear in standard Base32, which is a useful error check: if your string contains a 1 or an 8, it is not standard Base32, or it has been mistyped. Lowercase letters are accepted by many decoders as equivalent to uppercase, but the canonical form is uppercase, and converting to uppercase before decoding avoids surprises.

Padding fills the final group. Input bytes come in groups of 5, which is 40 bits, and 40 bits divide exactly into eight 5-bit characters. If the input length is not a multiple of 5 bytes, the final character group is shorter, and equals signs pad it out to 8 characters. A 1-byte input produces 2 characters plus 6 padding signs, a 2-byte input produces 4 characters plus 4 padding signs, a 3-byte input produces 5 characters plus 3 padding signs, and a 4-byte input produces 7 characters plus 1 padding sign. A 5-byte input needs no padding. Many decoders accept unpadded input, but the padded form is the portable one to store and share.

To decode, paste the string into the decoder, confirm the alphabet setting if the tool offers variants, and read the output as text or as bytes. If the output is readable text, you are done. If it is binary, the tool may show it as hexadecimal or offer a download, because not all byte sequences form printable characters. If the tool reports an error, check the usual suspects in order: stray spaces or line breaks, lowercase handled inconsistently, a missing or extra padding sign, and a character outside the alphabet such as 0, 1, 8 or 9. Removing whitespace and uppercasing the string fixes most failures.

A worked example you can follow

Decode the sample string NBSWY3DP, which is the well-known Base32 encoding of the word hello. First, map each character to its 5-bit value: N is 13, B is 1, S is 18, W is 22, Y is 24, 3 is 27, D is 3, and P is 15. Written as 5-bit groups, those values give 40 bits in total, because 8 characters multiplied by 5 bits equals 40 bits. Split the 40 bits into five 8-bit bytes: the first byte is 01101000, which is 104 in decimal, the letter h. The second is 01100101, which is 101, the letter e. The third and fourth are both 01101100, which is 108, the letter l, appearing twice. The fifth is 01101111, which is 111, the letter o. Together they spell hello. The string needs no padding because hello is 5 bytes, and 5 bytes encode to exactly 8 characters.

Test the padding rule with a shorter sample. The single letter h is 1 byte, so it encodes to 2 characters plus 6 padding signs. The word hi is 2 bytes, giving 4 characters plus 4 padding signs. If you decode a string and the padding count does not match its length pattern, suspect a truncated copy: a string copied from a wrapped line or a chat message often loses its trailing equals signs, and restoring them by the length rule usually repairs it.

Common mistakes to avoid

The most common mistake is confusing Base32 with Base64: the two alphabets and group sizes differ, and feeding a Base64 string to a Base32 decoder produces errors or nonsense. A second mistake is pasting a live secret, such as a two-factor authentication seed, into an online decoder you do not control; the tool on this site presents its work as running locally in your browser, but as a general rule, never paste secrets into a tool you have not verified, and prefer offline decoding for anything sensitive. A third mistake is ignoring case and whitespace: some decoders reject lowercase or spaces while others accept them, so normalise the input first. A fourth mistake is treating decoded binary as text when it is not: a decoded key or image will look like garbage as text, and that is expected, not an error.

Base32 remains popular where human handling matters, because its alphabet avoids easily confused characters and works in systems that are case-insensitive or restrict digits. When you need the reverse direction, the Base32 Encoder encodes text to Base32, and the Binary to Text Decoder handles raw binary strings. For arithmetic practice with the bit-group calculations in this guide, see Percentage Calculator Guide. Decode carefully, check the alphabet first, and a string of capital letters will stop looking like noise.

One place you will meet Base32 in everyday life is two-factor authentication. When you set up an authenticator app by scanning a QR code or typing a setup key, that key is usually a Base32 string representing a shared secret. The app decodes it, combines it with the current time, and produces the six-digit codes you type at sign-in. That is also why setup keys deserve the same care as passwords: anyone who obtains the key can generate the same codes. Store the key in a password manager or a safe offline note, never in a screenshot shared casually, and if a key is ever exposed, revoke it and generate a fresh one rather than hoping nobody noticed.