Base64

As with all binary-to-text encoding schemes, Base64 is designed to carry data stored in binary formats across channels that only reliably support text content.

[2] Base64 is also widely used for sending e-mail attachments, because SMTP – in its original form – was designed to transport 7-bit ASCII characters only.

This combination leaves the data unlikely to be modified in transit through information systems, such as email, that were traditionally not 8-bit clean.

The earliest instances of this type of encoding were created for dial-up communication between systems running the same OS – for example, uuencode for UNIX and BinHex for the TRS-80 (later adapted for the Macintosh) – and could therefore make more assumptions about what characters were safe to use.

For instance, uuencode uses uppercase letters, digits, and many punctuation characters, but no lowercase.

The example below uses ASCII text for simplicity, but this is not a typical use case, as it can already be safely transferred across all systems that can handle Base64.

The padding character is =, which indicates that no further bits are needed to fully encode the input.

An exception in which padding characters are required is when multiple Base64 encoded files have been concatenated.

The first known standardized use of the encoding now called MIME Base64 was in the Privacy-enhanced Electronic Mail (PEM) protocol, proposed by RFC 989 in 1987.

[8] The current version of PEM (specified in RFC 1421) uses a 64-character alphabet consisting of upper- and lower-case Roman letters (A–Z, a–z), the numerals (0–9), and the + and / symbols.

[4] The original specification, RFC 989, additionally used the * symbol to delimit encoded but unencrypted data within the output stream.

If there are fewer than three bytes left to encode (or in total), the remaining buffer bits will be zero.

This signals the decoder that the zero bits added due to padding should be excluded from the reconstructed data.

The MIME (Multipurpose Internet Mail Extensions) specification lists Base64 as one of two binary-to-text encoding schemes (the other being quoted-printable).

OpenPGP, described in RFC 9580, specifies "ASCII armor", which is identical to the "Base64" encoding described by MIME, with the addition of an optional 24-bit CRC.

Using standard Base64 in URL requires encoding of '+', '/' and '=' characters into special percent-encoded hexadecimal sequences ('+' becomes '%2B', '/' becomes '%2F' and '=' becomes '%3D'), which makes the string unnecessarily longer.

For this reason, modified Base64 for URL variants exist (such as base64url in RFC 4648), where the '+' and '/' characters of standard Base64 are respectively replaced by '-' and '_', so that using URL encoders/decoders is no longer necessary and has no effect on the length of the encoded value, leaving the same encoded form intact for use in relational databases, web forms, and object identifiers in general.

', potentially exposing applications to relative path attacks when a folder name is encoded from user data.

[citation needed] The atob() and btoa() JavaScript methods, defined in the HTML5 draft specification,[13] provide Base64 encoding and decoding functionality to web pages.