when to use base32 instead of base64
The difference between Base32 and Base64 starts with how many bits each output character carries: 5 in Base32, 6 in Base64. One bit less per symbol looks small, but it pushes the overhead from 33% to 60%, almost double. The trade only pays off when the reason is something else: text that needs to be typed by hand, read out over the phone, or saved as a file name on a system that does not tell upper case from lower case.
24 characters for 15 bytes, exactly 60% expansion: 15 times 8 bits divided by 5 bits per symbol closes out at 24 with no leftover and no padding.
20 characters for the same 15 bytes, 33.3% expansion: the same input, the same size, a result 4 characters shorter than Base32.
On macOS and Windows by default, upper and lower case do not tell file names apart, so a Base64 identifier with distinct upper and lower case letters risks colliding with another; Base32 has no such risk because it decodes the same either way.
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.
Because Base32 uses 5 bits per output character (32 symbols) and Base64 uses 6 (64 symbols). A byte has 8 bits, so Base32 needs 8/5 = 1.6 characters per byte and Base64 needs 4/3 ≈ 1.33. It is a direct consequence of the alphabet's math, not an implementation choice.
It depends on where the encoded text will live. In a file name, a DNS subdomain or a code read aloud over the phone, yes: the extra 27 percentage points of overhead buy the guarantee that upper and lower case never change the result. In a JSON API or an HTTP header, it usually is not worth it, because nothing there folds the text's case.
No. Every standard Base64 variant (including the URL-safe one, with - and _ instead of + and /) tells A apart from a, so decoding with the case swapped produces a different result or an error. To become case-insensitive, a system would need to normalise the text before decoding, something Base32 already solves in its alphabet.
ABCDEFGHIJKLMNOPQRSTUVWXYZ234567Everything is computed in your browser, including the loaded file and any pasted secret. Nothing is sent to a server.