base32/

Base32 writes every 5 bytes as 8 characters from an alphabet of only 32 (A-Z and 2-7 in the standard form), so the output is about 60% longer than the input, where Base64 adds only about a third. In return it is case-insensitive and has no digits 0, 1, 8 or 9, so it is hard to mix up with the letters O, I and B. That suits copying by hand, reading aloud and case-insensitive places such as 2FA keys and file names.

The Base32 you meet day to day, including 2FA keys and the default output of most libraries, is the standard variant (RFC 4648 section 6, alphabet A-Z and 2-7). Base32Hex (section 7, alphabet 0-9 and A-V) keeps the sort order of the encoded text the same as the sort order of the original bytes, which is why DNSSEC NSEC3 uses it. They cannot decode each other: the wrong choice often gives a "not a Base32 character" error, and sometimes just produces garbage.

Yes. A TOTP secret (the secret parameter of the otpauth:// link in a QR code, or the key you type in by hand) is normally standard Base32, usually uppercase without =, and sometimes shown in groups of 4 characters separated by spaces; decoding here accepts all of that. The result is random bytes rather than text, so tick "Show result as hex" to see it. For example JBSWY3DPEHPK3PXP is 48 65 6c 6c 6f 21 de ad be ef. To generate one-time codes, use the 2FA tool on this site.

"Invalid length" means that after removing =, the number of characters leaves a remainder of 1, 3 or 6 when divided by 8; valid Base32 only leaves 0, 2, 4, 5 or 7, so characters were most likely missed when copying. "Not a Base32 character" points to the character position: the standard variant has no 0, 1, 8 or 9, and no punctuation or full-width characters; if the content contains 0-9 and A-V it may be Base32Hex, so switch the variant. "= can only appear at the end" means there is more content after an =, perhaps several strings pasted together, which you need to decode separately. Spaces, line breaks, lowercase letters and a missing = never cause an error.

The = characters pad the length to a multiple of 8 and are not part of the data. Decoding works with or without them; when encoding, "Add = padding" is ticked by default, so untick it if you do not need it. Whether you can leave it out depends on the receiver: the Google Authenticator otpauth link format says the secret does not need padding and it is usually omitted, while Python's base64.b32decode requires it and raises Incorrect padding without it.

It means the decoded bytes are not UTF-8 text. 2FA keys, hashes and encrypted data are binary to begin with; tick "Show result as hex" to see the raw bytes. This tool only shows text as UTF-8. If the original text used GBK or another encoding, tick hex first, then use the text / hex tool on this site and pick GBK to turn the bytes back into text.

Check three things. First, whether the input ends with an extra line break or space: this tool encodes it as UTF-8 exactly as typed and does not trim it. Second, whether the variant matches: in Python the standard form is base64.b32encode and Base32Hex is base64.b32hexencode (available since 3.10). Third, whether = padding is on. Variants with a different alphabet, such as Crockford and z-base-32, are not supported and will not match.

No. Encoding and decoding run in your browser, make no network requests and save nothing; a 2FA secret never leaves your browser.