Base64: схемы кодирования двоичных данных в текст.

Group of binary to text encoding schemes using 64 symbols (plus padding)
In computer programming, Base64 is a group of binary to text encoding schemes that transforms binary data into a sequence of printable characters, limited to a set of 64 unique characters. More specifically, the source binary data is taken 6 bits at a time, then this group of 6 bits is mapped to one of 64 unique characters. 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. Base64 is particularly prevalent on the World Wide Web where one of its uses is the ability to embed image files or other binary assets inside textual assets such as HTML and CSS files. 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. Encoding an attachment as Base64 before sending, and then decoding when received, assures older SMTP servers will not interfere with the attachment. Base64 encoding causes an overhead of 33–37% relative to the size of the original binary data (33% by the encoding itself; up to 4% more by the inserted line breaks).

The particular set of 64 characters chosen to represent the 64 digit values for the base varies between implementations. The general strategy is to choose 64 characters that are common to most encodings and that are also printable. This combination leaves the data unlikely to be modified in transit through information systems, such as email, that were traditionally not 8 bit clean. For example, MIME's Base64 implementation uses A–Z, a–z, and 0–9 for the first 62 values. Other variations share this property but differ in the symbols chosen for the last two values; an example is UTF 7. 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 first known standardized use of the encoding now called MIME Base64 was in the Privacy enhanced Electronic Mail (PEM) protocol, proposed by in 1987. PEM defines a "printable encoding" scheme that uses Base64 encoding to transform an arbitrary sequence of octets to a format that can be expressed in short lines of 6 bit characters, as required by transfer protocols such as SMTP. The current version of PEM (specified in ) 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. The = symbol is also used as a padding suffix. The "Modified Base64" alphabet consists of the MIME Base64 alphabet, but does not use the "=" padding character. UTF 7 is intended for use in mail headers (defined in ), and the "=" character is reserved in that context as the escape character for "quoted printable" encoding. Modified Base64 simply omits the padding and ends immediately after the last Base64 digit containing useful bits leaving up to three unused bits in the last Base64 digit.

OpenPGP, described in , describes Radix 64 encoding, also known as "ASCII armor". Radix 64 is identical to the "Base64" encoding described by MIME, with the addition of an optional 24 bit CRC. The checksum is calculated on the input data before encoding; the checksum is then encoded with the same Base64 algorithm and, prefixed by the "=" symbol as the separator, appended to the encoded output data.

, entitled The Base16, Base32, and Base64 Data Encodings, is an informational (non normative) memo that attempts to unify the and specifications of Base64 encodings, alternative alphabet encodings, and the Base32 (which is seldom used) and Base16 encodings. Unless implementations are written to a specification that refers to and specifically requires otherwise, RFC 3548 forbids implementations from generating messages containing characters outside the encoding alphabet or without padding, and it also declares that decoder implementations must reject data that contain characters outside the encoding alphabet. Some variants allow or require omitting the padding '=' signs to avoid them being confused with field separators, or require that any such padding be percent encoded. Some libraries will encode '=' to '. ', potentially exposing applications to relative path attacks when a folder name is encoded from user data.

The atob and btoa JavaScript methods, defined in the HTML5 draft specification, provide Base64 encoding and decoding functionality to web pages. The btoa method outputs padding characters, but these are optional in the input of the atob method.