About

Base64 and Base32 are binary-to-text encoding schemes defined in RFC 4648. Base64 uses a 64-character alphabet (A - Z, a - z, 0 - 9, +, /) and produces output at 133% of input size. Base32 uses a 32-character alphabet (A - Z, 2 - 7) and produces output at 160% of input size. The trade-off is case-insensitivity and human readability in Base32 versus compactness in Base64. Choosing the wrong encoding in API tokens, TOTP secrets, or data URIs causes silent authentication failures and data corruption that surface only in production.

This converter performs real byte-level transcoding. It decodes the source encoding into a raw byte array, then re-encodes into the target format. It does not perform naive character substitution. Note: this tool assumes standard Base32 per RFC 4648 Section 6. Extended hex (Base32-HEX) and Crockford variants are not supported. Pro tip: TOTP authenticator secrets (Google Authenticator, Authy) are always Base32. If you receive a Base64 key from a server, you must transcode it before provisioning.

Formulas

Base64 encodes every group of 3 bytes (24 bits) into 4 characters of 6 bits each. Base32 encodes every group of 5 bytes (40 bits) into 8 characters of 5 bits each. The transcoding process operates in two stages:

Input_Base64 ⟶ atob(Input) → Bytes[n] → Base32Encode(Bytes) → Output_Base32

Output length for Base64:

L_Base64 = 4 ⋅ ceil(n3)

Output length for Base32:

L_Base32 = 8 ⋅ ceil(n5)

Where n = number of raw bytes. The padding count p for Base32 follows: if n mod 5 = 1 → p = 6; if 2 → p = 4; if 3 → p = 3; if 4 → p = 1; if 0 → p = 0.

Reference Data

Property	Base64 (RFC 4648 §4)	Base32 (RFC 4648 §6)
Alphabet Size	64 characters	32 characters
Characters Used	A - Z, a - z, 0 - 9, +, /	A - Z, 2 - 7
Padding Character	=	=
Bits per Character	6	5
Encoding Group	3 bytes → 4 chars	5 bytes → 8 chars
Size Overhead	~33%	~60%
Case Sensitive	TRUE	FALSE
Human Readable	Low (confuses 0/O, 1/l)	High (no ambiguous chars)
Common Uses	MIME, Data URIs, JWT, PEM	TOTP, Onion addresses, GeoHash
URL Safe Variant	A - Z, a - z, 0 - 9, −, _	Same (inherently URL safe)
1 byte input	4 chars (2 padding)	8 chars (6 padding)
2 bytes input	4 chars (1 padding)	8 chars (4 padding)
3 bytes input	4 chars (0 padding)	8 chars (1 padding)
4 bytes input	8 chars (2 padding)	8 chars (0 padding) + partial
5 bytes input	8 chars (1 padding)	8 chars (0 padding)
Max Line Length (MIME)	76	Not specified
Padding Requirement	Required per spec	Required per spec
Regex Validation	`^[A-Za-z0-9+/]*={0,2}$`	`^[A-Z2-7]*={0,6}$`

Frequently Asked Questions

Base32 uses 5 bits per character compared to Base64's 6 bits per character. For n raw bytes, Base64 produces 4 ⋅ ceil(n/3) characters while Base32 produces 8 ⋅ ceil(n/5) characters. This means Base32 output is roughly 20% longer than Base64 for the same payload. The trade-off is that Base32 is case-insensitive and avoids ambiguous characters.

Yes. The converter decodes Base64 into a raw byte array without assuming UTF-8 text encoding. Every byte value from 0x00 to 0xFF is preserved during transcoding. PEM certificates, image data URIs, and encrypted blobs will convert correctly. However, the output textarea displays the Base32 string. You can download the result as a file for programmatic use.

No. This tool implements strictly RFC 4648 Section 6 standard Base32 with alphabet A - Z and 2 - 7. Base32-HEX (Section 7) uses 0 - 9 and A - V. Crockford omits I, L, O, U and uses no padding. Feeding Crockford-encoded input will produce incorrect output. Verify your source encoding before converting.

The converter strips all whitespace characters (spaces, tabs, newlines, carriage returns) before processing. MIME-formatted Base64 with 76-character line wrapping is handled correctly. PEM files with header/footer lines (-----BEGIN-----) should have those lines removed before pasting. Only the Base64 payload should be provided.

TOTP secrets per RFC 6238 must be Base32-encoded. If your server provides a Base64 key, paste it into the input field with direction set to Base64 → Base32. The output is your provisioning secret. Remove any padding (=) characters if your authenticator app does not accept them. Verify by generating a TOTP code and comparing it against your server's expected value.

Per RFC 4648, padding with = is required for canonical encoding. However, many implementations (notably Google Authenticator) strip padding. This converter produces padded output by default. You may safely remove trailing = characters if your consumer tolerates unpadded input. For decoding, the converter accepts both padded and unpadded Base32 input.