The History of Base64: From Email Attachments to the Modern Web

Born for email

In the 1980s, email systems could only carry ASCII text. Binary attachments (images, archives) would be mangled or corrupted in transit. In the early 1990s, PEM (Privacy Enhanced Mail, RFC 989/1421) proposed a fix: re-encode arbitrary binary data into 64 safe characters so it became plain text — the prototype of Base64.

In 1996, RFC 2045 (MIME) formalized the Base64 encoding we use today, for transmitting email attachments. Since then its use has far outgrown email.

How it works: 3 bytes become 4 characters

The core idea is simple:

• Take 3 bytes (24 bits) and split them into 4 groups of 6 bits;
• Each 6-bit value (0–63) maps to one of 64 characters: A-Z, a-z, 0-9, +, /;
• Pad with = when the input isn't a multiple of 3 bytes.

So Base64 output is about 4/3 the size of the original (~33% larger).

Modern applications

• Email attachments: MIME encoding (the classic use);
• Inline images: data:image/png;base64,... in HTML/CSS reduces requests;
• Tokens and protocols: JWT Header/Payload use Base64URL (- and _ instead of + and /, no =);
• Textualizing binaries: embedding binary into JSON, XML, API params or QR codes.

Common misconceptions

• Base64 is not encryption: it is reversible encoding — anyone can decode it, so never use it to protect secrets;
• Base64 adds ~33% size, unsuitable for storing large binaries;
• Base64 is one of several base encodings (Base32, Base16/Hex, etc.).

In summary

An encoding designed for 1987 email still works at the front line of the modern web. Base64's story shows that general solutions to small problems often turn out to be big wins.