That 32 character alphabet deliberately excludes visually confusing pairs such as the digit 0 and the letter O, or the digit 1 and the letters I and L, which is precisely why base32 shows up in contexts meant for humans to transcribe, most notably the shared secret keys used to set up two factor authentication apps, and in identifiers such as those used by some content addressed and distributed systems.
The tricky part almost every hand rolled implementation gets wrong is padding. Base32 output length must always be a multiple of 8 characters, achieved by adding equals sign padding at the end according to specific rules based on how many bytes were left over. This tool validates that padding strictly before decoding, so a base32 string with a missing or extra character produces a clear, specific error rather than silently corrupted output.
When to reach for this base32 encoder decoder
Base32 solves the same underlying problem as base64, representing arbitrary bytes as text, but trades a slightly larger output size for an alphabet that is unambiguous when read aloud, typed by hand, or displayed in a case insensitive context such as a DNS record or certain file systems. That tradeoff is exactly why authenticator apps encode their shared secrets in base32 rather than base64: a person occasionally does need to type that secret manually.
It is the wrong tool when output size matters more than human readability, since base32 expands data by roughly 60 percent compared to the original bytes, noticeably more than base64's roughly 33 percent expansion. For anything that only ever moves between machines and never needs a human to read or type it, base64 is usually the more compact and more common choice.
- Encode a two factor authentication shared secret so it can be typed by hand into an authenticator app.
- Use base32 for identifiers that must survive a case insensitive system, such as certain DNS labels.
- Decode a base32 string you received to recover the original bytes or text.
- Prefer base64 instead when output size matters more than human readability and case sensitivity is not a concern.
How RFC 4648 base32 padding actually works
Base32 processes input five bytes, or 40 bits, at a time, splitting each block into eight 5 bit groups that each map to one of the 32 alphabet characters. When the final block has fewer than five bytes, the specification pads the output to a fixed length of 8 characters using trailing equals signs, with the exact padding count determined by how many bytes remained: one leftover byte produces 6 padding characters, two produce 4, three produce 3, and four produce a single padding character.
This is precisely why base32 output length is always a multiple of 8, and why this tool rejects a base32 string whose total length, or whose padding placement, does not match one of those exact patterns defined in RFC 4648 base32. A string with padding character in the middle, or a data length that does not correspond to any valid leftover byte count, is not valid base32 no matter how close it looks.
Base32 compared with base64
Both encodings exist to represent arbitrary bytes as printable text, but they make different tradeoffs. Base64 packs more bits per output character, giving a more compact result, while base32 sacrifices some of that compactness in exchange for an alphabet with no lowercase letters and no visually similar character pairs, which matters enormously the moment a human has to read or retype the value correctly.
As a rule of thumb, reach for base64 by default and switch to base32 specifically when the output needs to survive being read aloud, typed by hand, or passed through a system that folds case, such as certain file systems and some DNS record types.
Five bits at a time: the bit packing loop underneath
Encoding runs text through TextEncoder first to get real UTF-8 bytes, then packs those bytes 5 bits at a time into the RFC 4648 base32 alphabet, adding the correctly computed padding at the end. Decoding reverses the process exactly: padding and character set are validated first, then each character is converted back into its 5 bit value and the bits are reassembled into whole bytes, which are finally decoded as UTF-8 when the result forms valid text.
Everything happens locally inside your browser tab. The only moving parts are TextEncoder, TextDecoder and the bit packing loop that groups 5 bits at a time into the alphabet, none of which are capable of making a network call on their own. A two factor authentication secret you paste in for decoding is transformed entirely through local variables in memory and never gets serialised into a request of any kind.
| Leftover bytes | Output characters | Padding added |
|---|---|---|
| 1 | 2 | ====== |
| 2 | 4 | ==== |
| 3 | 5 | === |
| 4 | 7 | = |
| 0 (exact multiple of 5) | 8 | None |
How to use this base32 encoder decoder
- 1
Choose encode or decode
Pick whether you are turning text into base32 or turning a base32 string back into text.
- 2
Enter your input
Type or paste the text to encode, or paste the base32 string you want to decode.
- 3
Run the conversion
Press convert. Malformed base32, such as incorrect padding, produces a specific, readable error.
- 4
Copy the result
Copy the base32 text or the decoded text to your clipboard for use elsewhere.
Related tools worth bookmarking
Sources and further reading
- RFC 4648: The Base16, Base32, and Base64 Data EncodingsThe specification this tool follows exactly, including the base32 alphabet and its padding rules.rfc-editor.org
- MDN: TextEncoderThe browser API this tool uses to convert text to UTF-8 bytes before base32 encoding it.developer.mozilla.org
- WHATWG Encoding StandardThe living standard that governs how browsers convert between text and byte encodings.encoding.spec.whatwg.org
Frequently asked questions
Common questions about the base32 encoder decoder.
Base32 output length must always be a multiple of 8 characters, with equals sign padding added according to strict rules from RFC 4648. This tool checks the total length and the placement of padding before decoding, and reports specifically what is wrong, since a base32 string with the wrong padding count is not valid no matter how close it looks.
RFC 4648 defines the base32 alphabet as uppercase A through Z plus the digits 2 through 7, deliberately excluding 0, 1 and 8, 9 because they are easily confused with the letters O, I, L and B in handwriting or certain fonts. That choice makes base32 the more forgiving option when a value must be read aloud or typed by hand.
Base64 packs data more densely, producing a shorter result, but uses both uppercase and lowercase letters plus symbols that can be confused or altered in case insensitive systems. Base32 to text conversion trades some compactness for an alphabet that survives being retyped by hand or passed through a system that does not preserve letter case.
Yes. This page lets you encode base32 online directly in your browser tab, with no software to install and no account to create. The same page also decodes base32 back to text, so both directions are covered in one place.
Yes. Authenticator apps almost universally store their shared secret in base32, so you can paste a secret here to decode base32 string values and confirm what raw bytes it actually represents, or encode a value to base32 if you are generating a secret manually.
No. Every step of encoding or decoding runs locally in your browser using TextEncoder, TextDecoder and plain bit level JavaScript arithmetic. Nothing is transmitted anywhere, which matters especially since people frequently paste authentication secrets into a base32 encoder decoder.
Only when the original input was text. If the base32 came from arbitrary binary data, such as a cryptographic key, the decoded bytes may not form valid UTF-8 text, and this tool detects that automatically rather than displaying broken characters in place of a meaningful result.