Base64 Encoder / Decoder

What Base64 is actually for

Base64 exists because many systems that move data around were designed for text, not bytes. Email headers, URLs, JSON string values, XML attributes and HTTP headers all assume printable characters, and some of them historically stripped or mangled anything outside a narrow ASCII range. Base64 sidesteps that by re-expressing arbitrary bytes using only 64 characters that survive every such channel intact. The cost is size: three bytes become four characters, a fixed 33% overhead before line breaks. That trade — a third more bytes in exchange for never being corrupted in transit — is the entire reason the encoding exists, and it is why using it for anything else, such as obscuring a value, is a misuse rather than a feature.

Padding, wrapping, and why implementations disagree

Base64 encodes in groups of three bytes. When the input length is not a multiple of three, the final group is short, and the = character pads the output back to a multiple of four. Some decoders require that padding, others reconstruct it from the length, and URL contexts often strip it because = needs escaping. Line wrapping is a separate convention entirely: MIME wraps at 76 characters, PEM at 64, and many APIs expect no wrapping at all. Neither padding nor wrapping changes the data, which is why this decoder accepts input with or without either — a string that a stricter tool rejects for cosmetic reasons will still decode correctly here.