Base32 §6 (A-Z 2-7)
- Input
- test
- Expected output
- ORSXG5A=
Standard for 2FA and .onion addresses.
base32 rfc 4648 alphabet
Base32 per RFC 4648 — alphabet, padding and variants
RFC 4648 defines three encoding schemes: Base64 (§4), Base32 (§6) and Base32hex (§7). Each Base32 variant has specific uses. This page documents the differences and helps you choose the correct variant.
Base32 §6 vs Base32hex §7
- Base32 §6 uses A-Z and 2-7 — no 0/O/l/1/8. This is the standard for TOTP, Tor, human identifiers. Base32hex §7 uses 0-9 and A-V — it sorts lexicographically the same as the binary values, making it useful for NSEC3 (DNSSEC) and systems needing consistent ordering.
Variant comparison
Base32hex §7 (0-9 A-V)
- Input
- test
- Expected output
- EHI6GU0=
For DNSSEC and lexicographic ordering.
Full tool FAQ
Base64 uses 64 characters (A-Z, a-z, 0-9, +, /) and is more compact (~33% overhead vs ~60% for Base32). Base32 uses only 32 unambiguous uppercase characters (no l/1, 0/O confusion), making it better suited for human typing, case-insensitive systems and contexts that restrict the character set.
Frequently asked questions
Why does standard Base32 not use 0, 1, 8 and 9?
Base32 §6 uses digits 2-7 (not 0, 1, 8, 9) because: 0 and O are ambiguous, 1 and l are ambiguous. 8 and 9 were excluded to reserve space for 2-7 after the 26 letters, keeping the total at 32. Base32hex §7 uses 0-9 and A-V because the goal is lexicographic ordering, not human typing.
Does this page replace official or professional review?
No. It helps explain the scenario and use the tool more safely, but real decisions should consider official sources, full context and qualified guidance when needed.