Base32 is a byte encoding, not a numeral system
Base32, as implemented here, follows RFC 4648 and belongs to a different family of conversions than binary, octal, or base36. Those are positional numeral systems — the same integer, rewritten with a different digit alphabet. Base32 instead takes a sequence of raw bytes and re-encodes the underlying bits, five at a time, into a 32-character alphabet (A–Z and 2–7), so the output depends on byte boundaries and bit alignment, not just the numeric value of the input. Converting the hex bytes48656C6C6F (the ASCII text "Hello") to Base32 gives JBSWY3DP — there's no simple arithmetic relationship between that string and the number 310,939,249,775 that those bytes would represent if read as one large integer, because Base32 was never designed to preserve numeric value, only to preserve the bytes themselves in a text-safe form.
Why five bits, and why that alphabet
Base32 packs 5 bits into each output character because 2⁵ = 32, matching the alphabet size exactly. That doesn't align evenly with 8-bit bytes, which is why Base32 output length isn't simply proportional to input length in a clean way — the encoder buffers bits across byte boundaries and pads the final group with zero bits and = characters until the output reaches a multiple of 8 characters (the least common multiple of 5 and 8 bits, arranged as 40 bits, is the shortest span where both byte and character counts come out even). The 32-character alphabet itself was chosen to avoid characters that are easy to confuse when read aloud or misread in print — no 0 (confusable with O), no 1 (confusable with I or L), and no lowercase, so Base32 strings are also case-insensitive to decode without ambiguity.
Where Base32 is actually used
The clearest everyday example is two-factor authentication. TOTP apps like Google Authenticator or Authy store the shared secret key as a Base32 string specifically because it's meant to be typed by hand or read from a QR code fallback, where ambiguous characters would cause real setup failures. DNS also uses Base32 in DNSSEC's NSEC3 record type, again because DNS labels are case-insensitive and Base32 respects that constraint natively, unlike Base64 which relies on case to fit more bits per character. Some filesystems and case-insensitive storage systems use Base32 for the same reason when they need to encode arbitrary binary data (like a hash) into a filename-safe string.
Base32 versus Base64
Base32 and Base64 solve the same underlying problem — representing binary data as text — with different trade-offs. Base64 packs 6 bits per character instead of 5, so its output is shorter (roughly 133% of the input size in bytes, versus Base32's roughly 160%), but its 64-character alphabet requires both uppercase and lowercase letters plus + and /, all of which can cause problems in case-insensitive or URL-sensitive contexts. Base32 trades some compactness for robustness in exactly those environments. Neither is more "correct" — the choice depends on whether the destination format cares about case sensitivity and special characters, or mainly about output size.
A worked byte-alignment example
To see why byte and character boundaries don't line up neatly, consider a single byte: hex0xFF, or binary 11111111. Split into 5-bit groups from the left, that's11111 and 111 — the second group is only 3 bits, so it's padded with two zero bits to become 11100. Those two groups are indices 31 and 28 in the Base32 alphabet, which map to the characters 7 and 4, then padded with six = characters to reach the required 8-character block: 74======. A single input byte producing eight output characters, six of them padding, is normal for Base32 and is exactly the kind of expansion the encoding accepts in exchange for its safer character set.
Padding behavior
The = padding characters at the end of a Base32 string aren't optional decoration — they indicate how many bits of the final character group were real data versus zero-padding, which a decoder needs to reconstruct the exact original byte count. Some systems strip padding when they can infer the original length another way (many TOTP implementations do this), but a decoder that doesn't know to expect stripped padding may reject an otherwise valid string, so it's worth checking whether padding is expected before removing it.