Anyone who has worked with email attachments, embedded images, or certificate files has probably run into base64 without thinking much about where it came from. Asking when was base64 invented turns out to have a specific, documented answer, one tied to a real problem engineers were trying to solve in the 1980s: how to move binary data through systems that only understood plain text.
Base64 was invented in 1987 as part of the Privacy-Enhanced Mail (PEM) standard, first specified in RFC 989. It was created by IETF contributors including John Linn and Steve Kent to let binary data travel safely through email systems built only for 7-bit ASCII text. Nobody owns it; it's an open, patent-free standard that later became universal through MIME.
Base64 didn't appear out of nowhere. It grew directly out of the constraints of early email infrastructure, systems built in an era when "text" meant a narrow slice of the ASCII table and nothing else. Engineers needed a way to take arbitrary binary data, anything from a scanned document to an encryption key, and represent it using only characters that email servers would treat as safe, ordinary text.
That need produced a specific encoding scheme with a specific publication date, specific authors, and a specific institutional home. The rest of this article walks through that history in order: the problem, the first specification, the people involved, and how the scheme spread from a niche secure-email project into one of the most widely used encoding formats in computing.
To understand why was base64 invented, it helps to look at what email protocols could actually handle in the 1980s. SMTP, the protocol still used to route email today, was designed around 7-bit ASCII. That gave it 128 possible character codes, enough for English letters, digits, and basic punctuation, but nothing more. Mail relays, gateways, and servers along the delivery path routinely stripped the eighth bit from every byte, assuming it was never meaningful.
That assumption was fine for plain text messages. It was disastrous for anything else. If someone tried to send a binary file, a compiled program, an image, or a cryptographic key, straight through SMTP, the extra bit stripping and character reinterpretation would silently corrupt the data. Line-ending conventions also varied between systems, and some mail transport agents treated certain byte sequences as control codes and altered or deleted them entirely. Binary data simply could not survive the trip intact.
The fix wasn't to change every mail server in existence. Instead, engineers looked for a way to repackage binary data as ordinary printable text, something that looked exactly like the plain messages SMTP already handled correctly, and then unpack it back into binary on the receiving end.
The answer to when was base64 created points to 1987, with the publication of RFC 989, part of the Privacy-Enhanced Mail (PEM) effort. PEM was an early attempt to bring encryption and digital signatures to internet email, and it faced the binary-data problem head-on: encrypted messages and cryptographic signatures are binary by nature, and PEM needed a way to transmit them through the ASCII-only mail system without loss.
RFC 989 introduced an encoding scheme that took binary input and mapped it onto a 64-character alphabet made up of uppercase letters, lowercase letters, digits, and two additional symbols, plus a padding character for output that didn't divide evenly. This wasn't yet called "Base64" as a named standard the way it's known today, but the mechanism it defined is the direct ancestor of the encoding used everywhere now. Readers who want the mechanics of how PEM-formatted files use this encoding in practice can see it laid out concretely in this breakdown of PEM files and base64 encoding.
So who invented base64, specifically? RFC 989 lists John Linn as the primary author, working within the IETF's Privacy and Security Research Group. Steve Kent, a longtime figure in internet security standards work, was closely involved in the broader PEM effort alongside Linn. The project also had ties to RSA Laboratories and RSA Data Security, which contributed cryptographic expertise since PEM's whole purpose was securing email with encryption and digital signatures.
It's worth being precise here: PEM as a whole was a group effort with several contributors and revised RFCs over the following years (RFC 1113, 1114, and 1115 followed in 1989, refining the original work). But the encoding scheme itself, the specific algorithm for turning binary bytes into printable text, traces back to that 1987 document and the small group of engineers working on secure email at the time.
A common question once people learn the history is who owns base64. The answer is straightforward: nobody does. Base64 was published as part of an open IETF specification, and IETF standards are explicitly meant to be free for anyone to implement without licensing fees or patent restrictions. There's no company holding a trademark on the encoding scheme itself, and no royalty attached to using it.
This is a big part of why base64 spread so widely. Because it was defined in an open RFC rather than locked behind a proprietary license, any programming language, library, or protocol designer could implement it without negotiating rights. That openness is why base64 shows up today in email clients, web browsers, certificate tools, and programming language standard libraries, all built independently but all compatible because they follow the same open specification.
Digging a bit further into who made base64 means looking at how IETF working groups operated at the time. The Privacy and Security Research Group wasn't a single company's product team; it was a loose, collaborative body of engineers and researchers from universities, government-adjacent research labs, and private companies like RSA, all contributing drafts, feedback, and revisions through the RFC process.
John Linn's authorship of RFC 989 reflects that collaborative model. He drafted the specification, but the ideas built on prior work in the broader field of secure communications, and the document went through community review before and after publication. Steve Kent's involvement added weight from the security side of the project, since PEM needed an encoding that would work reliably as part of a larger cryptographic message format, not just as a standalone trick for moving bytes through email.
PEM itself never became the dominant way people encrypted email; other approaches like PGP took that role instead. But the base64 encoding scheme it introduced didn't disappear. In 1996, RFC 2045 defined MIME (Multipurpose Internet Mail Extensions), the standard that finally gave email a general way to carry attachments, non-English text, and binary content of any kind. MIME adopted base64 as one of its standard content transfer encodings.
This is the point where base64 went from a niche part of a security protocol to a universal building block of internet infrastructure. MIME wasn't limited to secure messages; it applied to every email with an attachment, every image embedded in a message, every non-ASCII character set. Once base64 was baked into MIME, it became a default tool across mail clients, and later web browsers picked up the same scheme for data URLs, embedding images and files directly inside HTML and CSS. The formal character set and encoding rules were later consolidated in RFC 4648, a topic covered in detail in this look at base64 and RFC 4648.
Coming back to why was base64 invented in more technical terms: the core challenge was converting arbitrary binary data, sequences of bytes with no inherent text meaning, into a string built only from characters guaranteed to survive 7-bit, ASCII-only transport. Base64 does this by grouping input bytes into blocks of three (24 bits) and re-slicing them into four 6-bit chunks. Each 6-bit chunk maps to one of 64 possible characters: A, Z, a, z, 0, 9, plus two more symbols (traditionally + and /), with = used to pad output when the input length isn't a clean multiple of three.
Because every character in that 64-character alphabet is a plain, printable ASCII character, the encoded output looks like ordinary text to any mail transport agent or protocol that only understands 7-bit ASCII. Nothing gets stripped, reinterpreted, or corrupted along the way. The tradeoff is size: base64 output runs about 33% larger than the original binary data, since three bytes of input become four bytes of output. That expansion was an acceptable cost for guaranteed delivery.
It's worth being clear on what base64 isn't: it provides no confidentiality or security on its own. It's purely a format conversion, not encryption, a distinction covered more fully in this explanation of encoding versus encryption. Anyone can reverse a base64 string back to its original bytes with no key required, a process detailed in this technical reference on decoding base64.
Rely on base64 as defined in MIME to attach images, documents, and other binary files to messages without corruption across mail servers.
Use base64-encoded data URLs to embed small images or fonts directly inside HTML and CSS files, avoiding extra network requests.
Work with base64-encoded PEM certificate files daily when configuring TLS, SSH keys, and other cryptographic infrastructure.
Encode binary payloads like images or file uploads into base64 strings so they can travel safely inside JSON request bodies.
Study base64's origin in RFC 989 as a case study in how internet standards evolve from niche security work into universal infrastructure.
Base64's history follows a clear timeline: invented in 1987 within RFC 989 as part of the PEM secure email standard, then carried forward and made universal through MIME's RFC 2045 in 1996. What started as a narrow fix for one security protocol became the default way to move binary data through text-only systems everywhere, from email to web pages to certificate files, a legacy still visible any time a developer opens a base64-encoded certificate or a browser renders an embedded image.
No. Base64 is an encoding scheme, not encryption. It provides no secrecy since any base64 string can be decoded back to its original form without a key.
Because it converts groups of three bytes into four printable characters, encoded output is roughly 33% larger than the original binary input.
Similar binary-to-text ideas existed in other contexts, but the specific base64 scheme as it's known today was formalized in 1987 specifically to solve the email transport problem.
Yes. Even though modern protocols can handle binary data directly in many cases, base64 remains standard in email (MIME), certificate files, data URLs, and many APIs that require text-safe payloads.
The IETF maintains the current formal specification, RFC 4648, which consolidated and clarified the base64 and base64url variants used across modern applications.
What began as a narrow solution to a 1980s email limitation is now embedded so deeply in everyday computing that most people never notice it working in the background, quietly turning binary bytes into text and back again, exactly as RFC 989 laid out nearly four decades ago.
Stay up to date with new tools, blogs, and improvements.
We respect your privacy. No spam, unsubscribe anytime.