🔐 RFC 4648 Base32 Encoder & Decoder
Encode text to Base32 or decode Base32 strings into plain text using standard RFC 4648 alphabet. Essential for two-factor authentication (2FA) OTP keys.
A–Z then 2–7. The one you will meet almost everywhere, including TOTP secrets.
J5XGY2LOMVKG633MJB2WE4Y=
14 bytes in, 24 characters out — Base32 costs about 60% more space than the raw bytes.
Base32 packs five bits per character, so every five bytes become eight characters and the output is 60% larger than the input — worse than Base64’s 33%. The reason to accept that is human handling: the standard alphabet is case-insensitive and omits 0, 1 and 8, so it survives being read aloud, written down or typed from a screen without 0/O and 1/I/l confusion. That is why two-factor secrets are Base32 and not Base64. Note that Crockford’s Base32 is a third, different alphabet and is not RFC 4648 — it will not decode here. Everything runs in your browser; nothing is uploaded.
What RFC 4648 Base32 Encoder & Decoder Does
Base32 turns arbitrary bytes into text using 32 characters, packing five bits into each one. Five bytes become exactly eight characters, so the output is 60% larger than the input — noticeably worse than Base64, which costs 33%.
The reason to accept that penalty is human handling. The standard alphabet is A to Z and the digits 2 to 7: case-insensitive, and deliberately missing 0, 1 and 8 so that nothing can be confused with O, I, l or B. A Base32 string survives being read aloud down a phone, written on paper, or typed from a screen. Base64 does not — it is case-sensitive and contains both O and 0.
That is why two-factor authentication secrets are Base32. When an app shows you a code to type into another device by hand, the encoding has to tolerate human transcription, and the size penalty is irrelevant for twenty bytes.
RFC 4648 actually defines two alphabets. The standard one above, and an "extended hex" variant using 0 to 9 then A to V, whose useful property is that encoded strings sort in the same order as the bytes they represent. DNSSEC NSEC3 records use it for exactly that reason.
How to Use RFC 4648 Base32 Encoder & Decoder
- Select Encode or Decode mode
- Type or paste your string in the input field
- Click Copy Output to use in authentication or cryptographic systems
Formula Used by RFC 4648 Base32 Encoder & Decoder
Five bits per character
5 bytes (40 bits) → 8 characters × 5 bits; output length = ceil(bytes ÷ 5) × 8 with padding
- padding
- "=" fills the final group to eight characters; valid remainders are 0, 2, 4, 5 or 7 characters
- overhead
- 8 ÷ 5 = 60% larger, against Base64's 4 ÷ 3 = 33%
- case
- the standard alphabet is case-insensitive on decode
Worked example
The five bytes "fooba".
- 40 bits divides evenly into eight groups of five
- Each group indexes the alphabet
- No padding needed, because the length is already a multiple of five
Result: MZXW6YTB — one of the RFC 4648 test vectors, and exactly eight characters.
RFC 4648 test vectors
The official conformance set. Any implementation should reproduce these exactly.
| Input | Base32 |
|---|---|
| (empty) | (empty) |
| f | MY====== |
| fo | MZXQ==== |
| foo | MZXW6=== |
| foob | MZXW6YQ= |
| fooba | MZXW6YTB |
| foobar | MZXW6YTBOI====== |
Base32 against the alternatives
| Encoding | Alphabet | Overhead | Suited to |
|---|---|---|---|
| Base16 (hex) | 0–9 A–F | 100% | Debugging; unambiguous but bulky |
| Base32 | A–Z 2–7 | 60% | Anything a person has to read or type |
| Base32 hex | 0–9 A–V | 60% | Where sort order must match the bytes |
| Base64 | A–Z a–z 0–9 + / | 33% | Machine-to-machine, where size matters |
| Base64url | A–Z a–z 0–9 - _ | 33% | URLs and filenames; no + or / to escape |
How to Read Your Result
Encoding is not encryption
Base32 is reversible by anyone, with no key. It exists to move bytes safely through systems that expect text, not to conceal anything. A two-factor secret encoded in Base32 is a secret written in a different alphabet, and it should be protected exactly as carefully as the raw bytes.
Padding is often optional in practice
RFC 4648 requires "=" padding, but many implementations accept and emit unpadded strings, and TOTP secrets are commonly shown without it. Decoders should tolerate both; encoders should pad unless the consumer specifically does not want it.
Crockford Base32 is a different thing
It uses a third alphabet, excludes I, L, O and U, treats some characters as interchangeable on decode, and adds an optional check symbol. It is a sensible design and it is not RFC 4648 — a Crockford string will not decode correctly here, and vice versa.
Whitespace is formatting, not data
Base32 is routinely wrapped across lines in configuration files and emails. A decoder that treats a newline as an invalid character will fail on most real-world input, which is a surprisingly common bug.
Limitations & Accuracy Notes
- Text input and output. Encoding an arbitrary binary file is not supported here.
- Decoded bytes that are not valid UTF-8 are shown as hex, which is the honest representation for keys and hashes.
- Crockford Base32 and z-base-32 are different alphabets and are not handled.
- Very large inputs are limited by browser memory, since everything runs in the tab.
- Nothing is uploaded — but a secret pasted into any web page should be treated as one to rotate.
Frequently Asked Questions
What is Base32 encoding used for?
Why is Base32 preferred over Base64 for 2FA keys?
Why does Base32 exist when Base64 is more compact?
Where will I actually encounter Base32?
How much does Base32 expand data?
Why does the output end in equals signs?
Is Base32 encryption?
Is my data sent anywhere?
References & Further Reading
- RFC 4648 — Base16, Base32 and Base64 encodings — Both alphabets, the padding rules, and the test vectors above
- RFC 6238 — TOTP — The time-based one-time password standard whose shared secrets are conventionally Base32