Base64

Numeral systems by culture
Hindu-Arabic numerals
Western Arabic (Hindu numerals) Eastern Arabic Indian family Tamil	Burmese Khmer Lao Mongolian Thai
East Asian numerals
Chinese Japanese Suzhou	Korean Vietnamese Counting rods
Alphabetic numerals
Abjad Armenian Āryabhaṭa Cyrillic	Ge'ez Greek (Ionian) Hebrew
Other systems
Aegean Attic Babylonian Brahmi Egyptian Etruscan Inuit	Kharosthi Mayan Quipu Roman Sumerian Urnfield
List of numeral system topics
Positional systems by base
Decimal (10)
2, 3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 20, 24, 30, 36, 60, 64
List of numeral systems
v · d · e

Base64 is a group of similar encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation. The Base64 term originates from a specific MIME content transfer encoding.

Base64 encoding schemes are commonly used when there is a need to encode binary data that needs be stored and transferred over media that are designed to deal with textual data. This is to ensure that the data remains intact without modification during transport. Base64 is commonly used in a number of applications including email via MIME, and storing complex data in XML.

Design

The particular choice of character set selected for the 64 characters required for the base varies between implementations. The general rule is to choose a set of 64 characters that is both part of a subset common to most encodings, and 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.^[1] For example, MIME's Base64 implementation uses A–Z, a–z, and 0–9 for the first 62 values. Other variations, usually derived from Base64, 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 dialup communication between systems running the same OS — e.g. uuencode for UNIX, 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, since UNIX was sometimes used with terminals that did not support distinct letter case.^[2][3][4][5]

Examples

A quote from Thomas Hobbes' Leviathan:

Man is distinguished, not only by his reason, but by this singular passion from other animals, which is a lust of the mind, that by a perseverance of delight in the continued and indefatigable generation of knowledge, exceeds the short vehemence of any carnal pleasure.

represented as a byte sequence of 8-bit-padded ASCII characters is encoded in MIME's Base64 scheme as follows:

TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz

IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg

dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu

dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo

ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=

In the above quote the encoded value of Man is TWFu. Encoded in ASCII, M, a, n are stored as the bytes 77, 97, 110, which are, in 8-bit quantities, 01001101, 01100001, 01101110 in base 2. These three bytes are joined together into a 24 bit buffer producing 010011010110000101101110. Packs of 6 bits (6 bits have a maximum of 64 different binary values) are converted into numbers (in this case, there are 4 numbers in this 24-bit string), which are then converted to their corresponding values in Base64.

Text content	M								a								n
ASCII	77								97								110
Bit pattern	0	1	0	0	1	1	0	1	0	1	1	0	0	0	0	1	0	1	1	0	1	1	1	0
Index	19						22						5						46
Base64-encoded	T						W						F						u

As this example illustrates, Base64 encoding converts 3 octets into 4 encoded characters.

The Base64 index table:

Value	Char		Value	Char		Value	Char		Value	Char
0	A		16	Q		32	g		48	w
1	B		17	R		33	h		49	x
2	C		18	S		34	i		50	y
3	D		19	T		35	j		51	z
4	E		20	U		36	k		52	0
5	F		21	V		37	l		53	1
6	G		22	W		38	m		54	2
7	H		23	X		39	n		55	3
8	I		24	Y		40	o		56	4
9	J		25	Z		41	p		57	5
10	K		26	a		42	q		58	6
11	L		27	b		43	r		59	7
12	M		28	c		44	s		60	8
13	N		29	d		45	t		61	9
14	O		30	e		46	u		62	+
15	P		31	f		47	v		63	/

When the number of bytes to encode is not dividable by 3, that is there are only one or two bytes of input for the last block, then the following action is performed: Add extra bytes with value zero so there are three bytes, and perform the conversion to base64. If there was only one significant input byte, only the first two base64 digits are picked, and if there was two significant input bytes, the first three base64 digits are picked. '=' characters might be added to make the last block contain four base64 characters.

As a result: When the last group contains one octet the four least significant bits of the final 6-bit block are set to zero, and when the last group contains two octets the two least significant bits of the final 6-bit block are set to zero.

Padding

The '==' sequence indicates that the last group contained only 1 byte, and '=' indicates that it contained 2 bytes. The example below illustrates how truncating the input of the whole of the above quote changes the output padding:

Input ends with: any carnal pleasure.  Output ends with: YW55IGNhcm5hbCBwbGVhc3VyZS4=
Input ends with: any carnal pleasure   Output ends with: YW55IGNhcm5hbCBwbGVhc3VyZQ==
Input ends with: any carnal pleasur    Output ends with: YW55IGNhcm5hbCBwbGVhc3Vy
Input ends with: any carnal pleasu     Output ends with: YW55IGNhcm5hbCBwbGVhc3U=
Input ends with: any carnal pleas      Output ends with: YW55IGNhcm5hbCBwbGVhcw==

The same characters will be encoded differently depending on their position within the three-octet group which is encoded to produce the four characters. For example

The Input: pleasure.   Encodes to cGxlYXN1cmUu
The Input:  leasure.   Encodes to bGVhc3VyZS4=
The Input:   easure.   Encodes to ZWFzdXJlLg==
The Input:    asure.   Encodes to     YXN1cmUu
The Input:     sure.   Encodes to     c3VyZS4=

The number of output bytes per input byte is approximately 4 / 3 (33% overhead) and converges to that value for large number of bytes. More specifically, given an input of n bytes, the output will be $4 \lceil n/3 \rceil$ bytes long, including padding characters.

From a theoretical point of view the padding character is not needed, since the number of missing bytes can be calculated from the number of Base64 digits. In some implementations the padding character is mandatory to use, for others it is not used. One case where padding characters are required is when multiple Base64 encoded files are concatenated. The 2011 DEF-CON Capture the Flag (CTF) qualifiers^[6] contained a puzzle with a file of concatenated Base64 encoded files.

Decoding Base64 with padding

When decoding Base64 text 4 characters are typically converted back to 3 characters. The only exceptions are when padding characters exist. A single '=' indicates the 4 characters will decode to only 2 bytes, while 2 '='s indicates the 4 characters will decode to a single byte. This example illustrates:

Encoded text ends with: YW55IGNhcm5hbCBwbGVhcw==   2 '='s decodes to 1 character:  any carnal pleas
Encoded text ends with: YW55IGNhcm5hbCBwbGVhc3U=   1 '=' decodes to 2 characters:  any carnal pleasu
Encoded text ends with: YW55IGNhcm5hbCBwbGVhc3Vy   0 '='s decodes to 3 characters: any carnal pleasur

Implementations and history

Variants summary table

Implementations may have some constraints on the alphabet used for representing some bit patterns. This notably concerns the last two characters used in the index table for index 62 and 63, and the character used for padding (which may be mandatory in some protocols, or removed in others). The table below summarizes these known variants, and link to the subsections below.

Variant	Char for index 62	Char for index 63	pad char	Fixed encoded line-length	Maximum encoded line length	Line separators	Characters outside alphabet	Line checksum
Original Base64 for Privacy-Enhanced Mail (PEM) (RFC 1421, deprecated)	+	/	= (mandatory)	Yes (except last line)	64	CR+LF	Forbidden	(none)
Base64 transfer encoding for MIME (RFC 2045)	+	/	= (mandatory)	No (variable)	76	CR+LF	Accepted (discarded)	(none)
Standard 'Base64' encoding for RFC 3548 or RFC 4648	+	/	= (mandatory)	Yes (except last line)	64 or 76 (only if line separators are specified and needed)	CR+LF (only if specified and needed)	Forbidden	(none)
'Radix-64' encoding for OpenPGP (RFC 4880)	+	/	= (mandatory)	No (variable)	76	CR+LF	Forbidden	24-bit CRC (Radix-64-encoded, including one pad character)
Modified Base64 encoding for UTF-7 (RFC 1642, obsoleted)	+	/	(none)	No (variable)	(none)	(none)	Forbidden	(none)
Modified Base64 for filenames (non standard)	+	-	(none)	No (variable)	(filesystem limit, generally 255)	(none)	Forbidden	(none)
Base64 with URL and Filename Safe Alphabet (RFC 4648 'base64url' encoding)	-	_	(optional, not recommended, if present must be URL encoded as %3D)	No (variable)	(application-dependent)	(none)	Forbidden	(none)
Modified Base64 for XML name tokens (Nmtoken)	.	-	(none)	No (variable)	(XML parser-dependent)	(none)	Forbidden	(none)
Modified Base64 for XML identifiers (Name)	_	:	(none)	No (variable)	(XML parser-dependent)	(none)	Forbidden	(none)
Modified Base64 for Program identifiers (variant 1, non standard)	_	-	(none)	No (variable)	(language/system-dependent)	(none)	Forbidden	(none)
Modified Base64 for Program identifiers (variant 2, non standard)	.	_	(none)	No (variable)	(language/system-dependent)	(none)	Forbidden	(none)
Modified Base64 for Regular expressions (non standard)	!	-	(none)	No (variable)	(application-dependent)	(none)	Forbidden	(none)

Privacy-enhanced mail

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. 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.^[7]

The current version of PEM (specified in RFC 1421) uses a 64-character alphabet consisting of upper- and lower-case Roman alphabet characters (A–Z, a–z), the numerals (0–9), and the "+" and "/" symbols. The "=" symbol is also used as a special suffix code.^[8] The original specification, RFC 989, additionally used the "*" symbol to delimit encoded but unencrypted data within the output stream.

To convert data to PEM printable encoding, the first byte is placed in the most significant eight bits of a 24-bit buffer, the next in the middle eight, and the third in the least significant eight bits. If there are fewer than three bytes left to encode (or in total), the remaining buffer bits will be zero. The buffer is then used, six bits at a time, most significant first, as indices into the string: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/", and the indicated character is output.

The process is repeated on the remaining data until fewer than four octets remain. If three octets remain, they are processed normally. If fewer than three octets (24 bits) are remaining to encode, the input data is right-padded with zero bits to form an integral multiple of six bits.

After encoding the non-padded data, if two octets of the 24-bit buffer are padded-zeros, two "=" characters are appended to the output; if one octet of the 24-bit buffer is filled with padded-zeros, one "=" character is appended. This signals the decoder that the zero bits added due to padding should be excluded from the reconstructed data. This also guarantees that the encoded output length is a multiple of 4 bytes.

PEM requires that all encoded lines consist of exactly 64 printable characters, with the exception of the last line, which may contain fewer printable characters. Lines are delimited by whitespace characters according to local (platform-specific) conventions.

MIME

Main article: MIME

The MIME (Multipurpose Internet Mail Extensions) specification lists Base64 as one of two binary-to-text encoding schemes (the other being quoted-printable).^[9] MIME's Base64 encoding is based on that of the RFC 1421 version of PEM: it uses the same 64-character alphabet and encoding mechanism as PEM, and uses the "=" symbol for output padding in the same way, as described at RFC 1521.

MIME does not specify a fixed length for Base64-encoded lines, but it does specify a maximum line length of 76 characters. Additionally it specifies that any extra-alphabetic characters must be ignored by a compliant decoder, although most implementations use a CR/LF newline pair to delimit encoded lines.

Thus, the actual length of MIME-compliant Base64-encoded binary data is usually about 137% of the original data length, though for very short messages the overhead can be a lot higher because of the overhead of the headers. Very roughly, the final size of Base64-encoded binary data is equal to 1.37 times the original data size + 814 bytes (for headers). In other words, you can approximate the size of the decoded data with this formula: bytes = (string_length(encoded_string) - 814) / 1.37

UTF-7

Main article: UTF-7

UTF-7, described first in RFC 1642, which was later superseded by RFC 2152, introduced a system called modified Base64. This data encoding scheme is used to encode UTF-16 as ASCII characters for use in 7-bit transports such as SMTP. It is a variant of the Base64 encoding used in MIME.^[10][11]

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 RFC 2047), 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

Main article: OpenPGP

OpenPGP, described in RFC 4880, describes Radix-64 encoding, also known as "ASCII Armor". Radix-64 is identical to the "Base64" encoding described from MIME, with the addition of an optional 24-bit CRC checksum. The checksum is calculated on the input data before encoding; the checksum is then encoded with the same Base64 algorithm and, using an additional "=" symbol as separator, appended to the encoded output data.^[12]

RFC 3548

RFC 3548, entitled The Base16, Base32, and Base64 Data Encodings, is an informational (non-normative) memo that attempts to unify the RFC 1421 and RFC 2045 specifications of Base64 encodings, alternative-alphabet encodings, and the seldom-used Base32 and Base16 encodings.

RFC 3548 forbids implementations from generating messages containing characters outside the encoding alphabet or without padding, unless they are written to a specification that refers to RFC 3548 and specifically requires otherwise; it also declares that decoder implementations must reject data that contains characters outside the encoding alphabet, unless they are written to a specification that refers to RFC 3548 and specifically requires otherwise.^[13]

RFC 4648

This RFC obsoletes RFC 3548 and focuses on Base64/32/16:

This document describes the commonly used Base64, Base32, and Base16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.

Filenames

Another variant called modified Base64 for filename uses '-' instead of '/', because Unix and Windows filenames cannot contain '/'.

URL applications

Base64 encoding can be helpful when fairly lengthy identifying information is used in an HTTP environment. For example, a database persistence framework for Java objects might use Base64 encoding to encode a relatively large unique id (generally 128-bit UUIDs) into a string for use as an HTTP parameter in HTTP forms or HTTP GET URLs. Also, many applications need to encode binary data in a way that is convenient for inclusion in URLs, including in hidden web form fields, and Base64 is a convenient encoding to render them in not only a compact way, but in a relatively unreadable one when trying to obscure the nature of data from a casual human observer.

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

For this reason, a modified Base64 for URL variant exists, where no padding '=' will be used, and the '+' and '/' characters of standard Base64 are respectively replaced by '-' and '_', so that using URL encoders/decoders are no longer necessary and have no impact 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.

Program identifiers

There are other variants that use '_-' or '._' when the Base64 variant string must be used within valid identifiers for programs.

XML

XML identifiers and name tokens are encoded using two variants:

• '.-' for use in XML name tokens (Nmtoken), or even
• '_:' for use in more restricted XML identifiers (Name).

Regular expressions

Another variant called modified Base64 for regexps uses '!-' instead of '*-' to replace the standard Base64 '+/', because both '+' and '*' may be reserved for regular expressions (note that '[]' used in the IRCu variant above would not work in that context).

HTML

The atob() and btoa() JavaScript methods, defined in the HTML5 draft specification,^[14] provide Base64 encoding and decoding functionality to web pages. The atob method is unusual in that it does not ignore whitespace or new lines, throwing an INVALID_CHARACTER_ERR instead. The btoa method outputs padding characters, but these are optional in the input of the atob method.

Other applications

Base64 can be used in a variety of contexts:

• Base64 can be used to transmit and store text that might otherwise cause delimiter collision
• Base64 is often used as a quick but insecure shortcut to obscure secrets without incurring the overhead of cryptographic key management. For example, Evolution^[15] and Thunderbird^[16] use Base64 to obfuscate e-mail passwords.
• Base64 is used to store a password hash computed with crypt in the /etc/passwd
• Spammers use Base64 to evade basic anti-spamming tools, which often do not decode Base64 and therefore cannot detect keywords in encoded messages.
• Base64 is heavily used for PHP obfuscation.
• Base64 is used to encode character strings in LDIF files
• Base64 is often used to embed binary data in an XML file, using a syntax similar to <data encoding="base64">…</data> e.g. favicons in Firefox's bookmarks.html.
• Base64 is used to encode binary files such as images within scripts, to avoid depending on external files.
• The data URI scheme can use Base64 to represent file contents. For instance, background images and fonts can be specified in a CSS stylesheet file as data: URIs, instead of being supplied in separate files.

Radix 64 applications not compatible with Base64

• The GEDCOM 5.5 standard for Genealogical data interchange uses a concept similar to Base64 to encode multimedia files in its text-line hierarchical file format. The choice of extra characters are '.' and '/' with a different assignment of characters to the 64 6-bit values, that is .,/,0-9,A-Z,a-z for values 0-63.^[17]
• Uuencoding uses a system with base 64 for binary data, but with much different set of characters in the encoding. It uses many punctation characters, but no lower-case letter.
• BinHex, which was used for the Mac OS has an encoding system with 64 as base, but with different characters compared to Base64. It uses punctuation characters, digits, upper and lower case letters, but does not use some visually confusable characters like '7', 'O', g' and 'o'.

See also

• Base32
• Base16
• Ascii85
• Quoted-printable
• uuencode
• yEnc
• 8BITMIME
• URL

References

1. ^ The Base16, Base32, and Base64 Data Encodings. IETF. October 2006. RFC 4648. http://tools.ietf.org/html/rfc4648. Retrieved March 18, 2010. 
2. ^ Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures. IETF. February 1993. RFC 1421. http://tools.ietf.org/html/rfc1421. Retrieved March 18, 2010. 
3. ^ Multipurpose Internet Mail Extensions: (MIME) Part One: Format of Internet Message Bodies. IETF. November 1996. RFC 2045. http://tools.ietf.org/html/rfc2045. Retrieved March 18, 2010. 
4. ^ The Base16, Base32, and Base64 Data Encodings. IETF. July 2003. RFC 3548. http://tools.ietf.org/html/rfc3548. Retrieved March 18, 2010. 
5. ^ The Base16, Base32, and Base64 Data Encodings. IETF. October 2006. RFC 4648. http://tools.ietf.org/html/rfc4648. Retrieved March 18, 2010. 
6. ^ Binary L33tness 100
7. ^ Privacy Enhancement for Internet Electronic Mail. IETF. February 1987. RFC 989. http://tools.ietf.org/html/rfc989. Retrieved March 18, 2010. 
8. ^ Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures. IETF. February 1993. RFC 1421. http://tools.ietf.org/html/rfc1421. Retrieved March 18, 2010. 
9. ^ Multipurpose Internet Mail Extensions: (MIME) Part One: Format of Internet Message Bodies. IETF. November 1996. RFC 2045. http://tools.ietf.org/html/rfc2045. Retrieved March 18, 2010. 
10. ^ UTF-7 A Mail-Safe Transformation Format of Unicode. IETF. July 1994. RFC 1642. http://tools.ietf.org/html/rfc1642. Retrieved March 18, 2010. 
11. ^ UTF-7 A Mail-Safe Transformation Format of Unicode. IETF. May 1997. RFC 2152. http://tools.ietf.org/html/rfc2152. Retrieved March 18, 2010. 
12. ^ OpenPGP Message Format. IETF. November 2007. RFC 4880. http://tools.ietf.org/html/rfc4880. Retrieved March 18, 2010. 
13. ^ The Base16, Base32, and Base64 Data Encodings. IETF. July 2003. RFC 3548. http://tools.ietf.org/html/rfc3548. Retrieved March 18, 2010. 
14. ^ Base64 utility methods, HTML5 Editor's Draft, section 6.2, introduced by changeset 5814, 2011-02-01
15. ^ Recovering stored email account passwords in Evolution (2.0.4)
16. ^ Vowe dot net
17. ^ The GEDCOM Standard Release 5.5

External links

• RFC 989 and RFC 1421 (Privacy Enhancement for Electronic Internet Mail)
• RFC 2045 (Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies)
• RFC 3548 and RFC 4648 (The Base16, Base32, and Base64 Data Encodings)
• Implementations available for ANSI C, C++, C#, Java, Perl, Python, Ruby