User Rating 0.0 ★★★★★

Total Usage 0 times

Category Code Utilities

Input

0 chars

Output

0 chars

Strip whitespace from input Include padding (=) in output Wrap output at 76 characters

Is this tool helpful?

Your feedback helps us improve.

★ ★ ★ ★ ★

About

Base32 and Base64 are binary-to-text encoding schemes defined in RFC 4648. Base32 uses a 32-character alphabet (A - Z, 2 - 7) and maps every 5 input bytes to 8 output characters, producing ~160% size overhead. Base64 uses 64 characters and maps 3 bytes to 4 characters, yielding ~133% overhead. Choosing the wrong encoding in protocol integration causes silent data corruption - TOTP tokens (RFC 6238) require Base32 secrets, while MIME attachments and JWTs demand Base64. This tool decodes the source encoding to raw bytes, then re-encodes into the target format with strict padding and alphabet validation.

Conversion is lossless for any valid input. Malformed padding or illegal characters are rejected with a specific error offset. Note: this tool processes standard alphabets only - Base32hex (RFC 4648 §6) and Base64url are not equivalent and will produce incorrect results if pasted here without prior normalization.

Formulas

Base32 encoding maps each group of 5 input bytes (40 bits) into 8 output characters, where each character represents 5 bits. The output length for n input bytes is:

L₃₂ = 8 × n5 (rounded up)

Base64 encoding maps each group of 3 input bytes (24 bits) into 4 output characters, where each character represents 6 bits:

L₆₄ = 4 × n3 (rounded up)

The conversion pipeline is: Source Encoding → decode to raw byte array → Target Encoding. For Base32 decoding, each character is mapped to its 5-bit index b_i via the alphabet lookup. The bits are concatenated into a continuous stream, then sliced into 8-bit bytes:

byte_j = bits[j × 8 .. (j + 1) × 8]

Where L₃₂ = output length in characters (Base32), L₆₄ = output length in characters (Base64), n = number of raw input bytes, b_i = 5-bit value of the i-th Base32 character, byte_j = the j-th reconstructed byte from the bitstream. Padding characters (=) signal unused trailing bits and are stripped before bit extraction.

Reference Data

Property	Base32 (RFC 4648)	Base64 (RFC 4648)
Alphabet size	32	64
Characters used	A - Z, 2 - 7	A - Z, a - z, 0 - 9, +, /
Padding character	=	=
Bits per character	5	6
Input group size	5 bytes	3 bytes
Output group size	8 chars	4 chars
Size overhead	160%	133.3%
Case sensitive	No	Yes
Valid padding counts	0, 1, 3, 4, 6	0, 1, 2
Common use: Authentication	TOTP/HOTP secrets (RFC 6238)	HTTP Basic Auth
Common use: Email	Rare	MIME attachments (RFC 2045)
Common use: Web	Onion addresses (Tor v3)	Data URIs, JWTs
Common use: DNS	DNSSEC (RFC 4034)	DKIM signatures
Common use: Filesystem	Case-insensitive paths	Rarely (slash conflicts)
Hex variant exists	Base32hex (0 - 9, A - V)	Base64url (-, _)
Encoding “Hello”	JBSWY3DP	SGVsbG8=
Encoding “f”	MY======	Zg==
Encoding “fo”	MZXQ====	Zm8=
Encoding “foo”	MZXW6===	Zm9v
Encoding “foob”	MZXW6YQ=	Zm9vYg==
Encoding “fooba”	MZXW6YTB	Zm9vYmE=
Encoding “foobar”	MZXW6YTBOI======	Zm9vYmFy
RFC specification	RFC 4648 §6	RFC 4648 §4

Frequently Asked Questions

TOTP implementations (RFC 6238) expect the shared secret in Base32. If you convert to Base64 and feed it to an authenticator, it will decode different raw bytes (the Base64 decoder interprets the alphabet differently), producing wrong HMAC outputs. Convert back to Base32 before use, or decode to raw hex bytes and import those directly.

RFC 4648 specifies padding is required, but many implementations omit it. This tool infers the correct padding from the input length modulo 8. For example, an input length of 7 mod 8 = 7 implies 1 padding character was stripped. The missing pad is restored internally before decoding. If the length modulo produces an impossible remainder (e.g., 1 or 3 characters with no valid padding configuration), an error is raised.

No. RFC 4648 §6 states that Base32 decoders must accept both uppercase and lowercase input. This tool normalizes to uppercase before lookup. Base64, however, is fully case-sensitive - "A" (index 0) and "a" (index 26) map to different 6-bit values. Mixing case in Base64 input is valid and intentional.

Whitespace (spaces, tabs, newlines, carriage returns) is silently stripped before decoding. This matches common real-world behavior where encoded data is line-wrapped at 76 characters (MIME) or 64 characters (PEM). Only alphabet characters and padding are processed.

Yes, as long as the file's content is already Base32- or Base64-encoded text. Paste or upload the encoded string. The tool decodes it to raw bytes internally and re-encodes. The output is a text string in the target encoding - it preserves the underlying binary data exactly. For raw binary file conversion (not text-encoded), you would first need to encode the file to Base32 or Base64 externally.

Base32 uses 5 bits per character versus 6 bits per character for Base64. For n raw bytes, Base32 produces ceil(n × 8 / 5) data characters, while Base64 produces ceil(n × 8 / 6). The ratio is 8/5 ÷ 4/3 = 6/5 = 1.2×, meaning Base32 output is approximately 20% longer than Base64 output for identical input data.