An exact 5-byte block
- Input
- "Hello" (5 bytes) em Base32 §6
- Expected output
- JBSWY3DP
8 characters, zero "=": 5 bytes is the size that closes a Base32 block with nothing left over.
Carregando ferramenta… / Loading tool…
base32 rfc 4648 alphabet and padding
RFC 4648 settles the Base32 math in one sentence: every 5 input bytes (40 bits) become exactly 8 output characters (8 × 5 bits), with nothing left over and nothing lost. That exact fit, not the alphabet, is what dictates when a final block needs padding, and how much.
8 characters, zero "=": 5 bytes is the size that closes a Base32 block with nothing left over.
2 data characters plus 6 "=", one of the 5 padding combinations the spec allows, never any other count.
The first 7 characters are the data; the trailing "V" is the remainder of (byte value) mod 37, drawn from the extra set outside the 32-symbol alphabet.
If the other side says RFC 4648 without qualifying, it means the A-Z2-7 alphabet with padding. Use base32hex when the alphabetical order of the encoded text has to follow the numeric order of the data, which is the case for NSEC3 in DNSSEC. Use Crockford when the code will be read and typed by people and you want to catch errors on the spot with the check symbol. Use z-base-32 when the value will be spoken aloud. Picking the wrong one corrupts nothing, but the other side will not be able to decode it.
Exactly 6, to round the block out to 8 characters: 1 byte only yields 2 data characters (fewer than 5 remaining bits), so RFC 4648 fills the rest with "=". The only valid padding amounts in §6 Base32 are 0, 1, 3, 4 or 6; any other number signals a malformed string.
It is the remainder of dividing the original bytes' numeric value by 37, read as a single large integer. Since 37 is larger than the data alphabet's 32 symbols, the check digit draws from 5 extra symbols (*, ~, $, =, U) reserved only for that position, never showing up in the encoded data itself.
Because Base32hex's alphabet (0-9 then A-V) follows the same ascending order as the numeric values it represents, so comparing two encoded strings as text gives the same result as comparing the original bytes. Standard Base32's A-Z then 2-7 alphabet lacks that property, because letters sort before digits in the ASCII table used to compare text.
ABCDEFGHIJKLMNOPQRSTUVWXYZ234567Everything is computed in your browser, including the loaded file and any pasted secret. Nothing is sent to a server.