Base32 encode and decode
Encode and decode RFC 4648 Base32 and base32hex locally — the alphabet used by TOTP secrets, DNSSEC records and Tor addresses.
- Runs in your browser
- Nothing you enter is sent
- Free, no account
The converted value appears here.
Accents, CJK and emoji become multiple bytes each, exactly as they are stored on disk.
Standard RFC 4648: ABCDEFGH… — no 0, 1 or 8, so it survives being read aloud.
What Base32 is for
Base32 encodes binary using 32 characters — A–Z and 2–7. That is five bits per character rather than Base64's six, so the output is 60% larger instead of 33%. You accept that cost to get three properties Base64 does not have: the alphabet is case-insensitive, it contains no characters that look alike, and it survives being spoken, handwritten or typed from a screen.
Why 0, 1 and 8 are missing
They were removed deliberately. Zero and capital O are indistinguishable in many fonts; one, capital I and lowercase L are worse; eight and capital B are close enough to matter on a low-resolution display. Dropping those digits eliminates the transcription errors people actually make — which is exactly why two-factor-authentication secrets are Base32 and not Base64.
Two alphabets
| RFC 4648 standard | base32hex (§7) | |
|---|---|---|
| Alphabet | A–Z then 2–7 | 0–9 then A–V |
| Sorts in byte order | No | Yes |
| Used by | TOTP secrets, Tor v3 addresses, some S3 keys | DNSSEC NSEC3 records |
| Value of the character A | 0 | 10 |
The two produce completely different output for the same input, so decoding with the wrong one gives plausible-looking rubbish rather than an error. If a decode is nonsense, try the other alphabet before assuming the data is corrupt.
Padding
Base32 works in 40-bit groups — five bytes in, eight characters out. When the input does not
divide evenly, the RFC pads to a multiple of eight with =, which is why you see
one, three, four or six equals signs but never two, five or seven. In practice most
implementations accept unpadded input, and TOTP secrets are almost always shared without
padding. The decoder here ignores padding entirely.
Reading a TOTP secret
When an authenticator app shows you a secret like JBSW Y3DP EHPK 3PXP, that is
Base32 with spaces added every four characters for legibility. Decode it here and you get the
raw key bytes — 10 bytes for that example, 20 for the RFC-recommended 160-bit secret. Spaces
and lowercase are both handled, so paste it exactly as shown. If you want to see the codes that
secret produces, our TOTP generator does that entirely offline as well.
Size comparison
| Encoding | Bits per character | Growth | Case-sensitive |
|---|---|---|---|
| Hex | 4 | +100% | No |
| Base32 | 5 | +60% | No |
| Base64 | 6 | +33% | Yes |
Pick hex when a human must read individual bytes, Base32 when a human must transcribe the whole value, and Base64 when nobody will ever read it and size matters.
Questions
Why does Base32 avoid 0, 1 and 8?
To survive being read aloud, handwritten or typed from a screen. Removing the digits that look like O, I/L and B eliminates the most common transcription mistakes — which is why 2FA secrets use it.
What is base32hex and when do I need it?
The extended-hex alphabet from RFC 4648 §7, using 0-9 then A-V. Its sort order matches the underlying bytes, which is why NSEC3 records in DNSSEC use it. Standard Base32 does not have that property.
Is the padding with = signs required?
The RFC says yes, but most real implementations accept unpadded input, and TOTP secrets are almost always shared without it. This decoder ignores padding entirely; the encoder adds it and you can strip it.
How much larger is Base32 than Base64?
Base32 expands data by 60% versus Base64's 33%, because each character carries 5 bits rather than 6. You trade size for a case-insensitive, unambiguous alphabet.