Base64 Encoder Decoder Calculator

The arithmetic behind Base64 is pure bit regrouping. Take the letter H, ASCII 72, binary 01001000, followed by e at 101 and l at 108: concatenating the three bytes gives the 24-bit string 010010000110010101101100, which splits into the 6-bit fields 010010, 000110, 010101, 101100, or the decimal indices 18, 6, 21, 44. Reading those positions from the alphabet A-Z, a-z, 0-9, plus, slash yields S, G, V, s. Indices 0 to 25 are uppercase, 26 to 51 lowercase, 52 to 61 the digits, 62 plus and 63 slash. When the input does not divide evenly by three, the leftover bits are padded with zeros on the right and the output is completed with equals signs: one remaining byte produces two characters plus two equals, and two remaining bytes produce three characters plus one equals. Because each output character carries 6 bits of information but occupies a full 8-bit byte of storage, the expansion is exactly 4 to 3, or about 33 percent, before padding. That places Base64 between the alternatives: Base16 hexadecimal spends 4 bits per character for 100 percent overhead, Base32 spends 5 bits for roughly 60 percent, and Ascii85 reaches about 25 percent using an 85-symbol alphabet. One point catches many naive implementations: Base64 encodes bytes, not characters. Text must first be serialised to bytes under a definite encoding, normally UTF-8, so a character such as the copyright sign becomes the two bytes 0xC2 0xA9 and most emoji become four bytes each before any expansion is applied. Decoding must reverse both steps in order, or the round trip corrupts the text.

Encoding binary as printable characters became necessary because early mail and file transfer paths assumed 7-bit text and would strip or reinterpret the eighth bit. The first widely used answer was uuencode, introduced by Mary Ann Horton around 1980 as part of the Unix-to-Unix Copy suite, which mapped 6-bit groups onto a contiguous run of ASCII beginning at the space character. That range included space and punctuation that intermediate gateways often altered. Restricting the alphabet to letters, digits and two symbols was the fix, and that alphabet was specified for Internet Privacy-Enhanced Mail in RFC 1113 in 1989 before it acquired its current name. RFC 1341 in 1992 and RFC 2045 in 1996 defined base64 as a MIME content transfer encoding, and the family was later separated into an encoding-only document, RFC 3548 in 2003, revised as RFC 4648 in 2006. That document is the reason the three related schemes are usually discussed together: it standardizes Base16, Base32 and Base64 in one place, along with the URL-safe alphabet. The sibling encodings found their own niches for reasons rooted in the same bit arithmetic. Base32, using an alphabet that omits the visually ambiguous 0, 1 and 8, became the format for shared secrets in time-based one-time password authenticators under RFC 6238. Ascii85 was developed for PostScript and carried into PDF, where its lower overhead mattered for embedded image data. Base58, devised for Bitcoin addresses in 2009, went further by removing every character pair a person might miscopy.