View source for Base64

{{Short description|Group of binary-to-text encoding schemes}}
In [[computer programming]], '''Base64''' is a group of [[binary-to-text encoding]] schemes that transforms [[binary data]] into a sequence of [[Graphic character|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]]<ref>{{cite web |title= Base64 encoding and decoding – Web APIs |url= https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding |publisher= MDN Web Docs |archive-url= https://web.archive.org/web/20141111151440/https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding |archive-date= 2014-11-11 |url-status=live}}</ref> 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.<ref>{{cite web |title= When to base64 encode images (and when not to) |date= 28 August 2011 |url=https://www.davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/ |archive-url= https://web.archive.org/web/20230829143759/https://www.davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/ |archive-date=2023-08-29 |url-status=live}}</ref>

Base64 is also widely used for sending [[e-mail]] attachments, because [[Simple Mail Transfer Protocol|SMTP]]&nbsp;– in its original form&nbsp;– 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).

{{TOC limit|3}}

==Design==
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]].<ref name="autogenerated2006">{{cite IETF |title= The Base16, Base32, and Base64 Data Encodings |rfc= 4648 |date=October 2006 |publisher=[[Internet Engineering Task Force|IETF]] |access-date= March 18, 2010}}</ref> For example, [[MIME]]'s Base64 implementation uses <code>A</code>–<code>Z</code>, <code>a</code>–<code>z</code>, and <code>0</code>–<code>9</code> 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 [[operating system|OS]] – for example, [[uuencoding|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.<ref name="rfc 1421">{{cite IETF |title= Privacy Enhancement for InternetElectronic Mail: Part I: Message Encryption and Authentication Procedures |rfc= 1421 |date=February 1993 |publisher=[[Internet Engineering Task Force|IETF]] |access-date= March 18, 2010}}</ref><ref name="rfc 2045">{{cite IETF |title= Multipurpose Internet Mail Extensions: (MIME) Part One: Format of Internet Message Bodies |rfc= 2045 |date=November 1996 |publisher=[[Internet Engineering Task Force|IETF]] |access-date= March 18, 2010}}</ref><ref name="rfc 3548">{{cite IETF |title= The Base16, Base32, and Base64 Data Encodings |rfc= 3548 |date=July 2003 |publisher=[[Internet Engineering Task Force|IETF]] |access-date= March 18, 2010}}</ref><ref name="autogenerated2006"/>

==Base64 table from RFC 4648==
<span id="Base64table">This is the Base64 alphabet defined in [https://datatracker.ietf.org/doc/html/rfc4648#section-4 RFC 4648 §4] .</span> See also {{sectionlink||Variants summary table}}.

{|class="wikitable" style="text-align:center"
|+ Base64 alphabet defined in RFC 4648.
!scope="col"| Index !!scope="col"| Binary !!scope="col"| {{abbr|Char.|Character}}
|rowspan="17"|
!scope="col"| Index !!scope="col"| Binary !!scope="col"| {{abbr|Char.|Character}}
|rowspan="17"|
!scope="col"| Index !!scope="col"| Binary !!scope="col"| {{abbr|Char.|Character}}
|rowspan="17"|
!scope="col"| Index !!scope="col"| Binary !!scope="col"| {{abbr|Char.|Character}}
|-
|  0 || 000000 || <code>A</code> || 16 || 010000 || <code>Q</code> || 32 || 100000 || <code>g</code> || 48 || 110000 || <code>w</code>
|-
|  1 || 000001 || <code>B</code> || 17 || 010001 || <code>R</code> || 33 || 100001 || <code>h</code> || 49 || 110001 || <code>x</code>
|-
|  2 || 000010 || <code>C</code> || 18 || 010010 || <code>S</code> || 34 || 100010 || <code>i</code> || 50 || 110010 || <code>y</code>
|-
|  3 || 000011 || <code>D</code> || 19 || 010011 || <code>T</code> || 35 || 100011 || <code>j</code> || 51 || 110011 || <code>z</code>
|-
|  4 || 000100 || <code>E</code> || 20 || 010100 || <code>U</code> || 36 || 100100 || <code>k</code> || 52 || 110100 || <code>0</code>
|-
|  5 || 000101 || <code>F</code> || 21 || 010101 || <code>V</code> || 37 || 100101 || <code>l</code> || 53 || 110101 || <code>1</code>
|-
|  6 || 000110 || <code>G</code> || 22 || 010110 || <code>W</code> || 38 || 100110 || <code>m</code> || 54 || 110110 || <code>2</code>
|-
|  7 || 000111 || <code>H</code> || 23 || 010111 || <code>X</code> || 39 || 100111 || <code>n</code> || 55 || 110111 || <code>3</code>
|-
|  8 || 001000 || <code>I</code> || 24 || 011000 || <code>Y</code> || 40 || 101000 || <code>o</code> || 56 || 111000 || <code>4</code>
|-
|  9 || 001001 || <code>J</code> || 25 || 011001 || <code>Z</code> || 41 || 101001 || <code>p</code> || 57 || 111001 || <code>5</code>
|-
| 10 || 001010 || <code>K</code> || 26 || 011010 || <code>a</code> || 42 || 101010 || <code>q</code> || 58 || 111010 || <code>6</code>
|-
| 11 || 001011 || <code>L</code> || 27 || 011011 || <code>b</code> || 43 || 101011 || <code>r</code> || 59 || 111011 || <code>7</code>
|-
| 12 || 001100 || <code>M</code> || 28 || 011100 || <code>c</code> || 44 || 101100 || <code>s</code> || 60 || 111100 || <code>8</code>
|-
| 13 || 001101 || <code>N</code> || 29 || 011101 || <code>d</code> || 45 || 101101 || <code>t</code> || 61 || 111101 || <code>9</code>
|-
| 14 || 001110 || <code>O</code> || 30 || 011110 || <code>e</code> || 46 || 101110 || <code>u</code> || 62 || 111110 || <code>+</code>
|-
| 15 || 001111 || <code>P</code> || 31 || 011111 || <code>f</code> || 47 || 101111 || <code>v</code> || 63 || 111111 || <code>/</code>
|-
| colspan="12" | || colspan="2" {{n/a|Padding}} || =
|}

==Examples==
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 more typical use is to encode [[binary data]] (such as an image); the resulting Base64 data will only contain 64 different ASCII characters, all of which can reliably be transferred across systems that may corrupt the raw source bytes.

Here is a well-known [[idiom]] from [[distributed computing]]:

{{Quote box
 | align = none
 | style = margin:1em 0;
 | border = 2px
 | fontsize = 800
 | quote = Many hands make light work.
}}

When the quote (without trailing whitespace) is encoded into Base64, it is represented as a byte sequence of 8-bit-padded [[ASCII]] characters encoded in [[MIME]]'s Base64 scheme as follows (newlines and white spaces may be present anywhere but are to be ignored on decoding):

{{Quote box
 | align = none
 | style = margin:1em 0;
 | border = 2px
 | fontsize = 800
 | quote={{mono|1=TWFueSBoYW5kcyBtYWtlIGxpZ2h0IHdvcmsu}}
}}

In the above quote, the encoded value of ''Man'' is ''TWFu''. Encoded in ASCII, the characters ''M'', ''a'', and ''n'' are stored as the byte values <code>77</code>, <code>97</code>, and <code>110</code>, which are the 8-bit binary values <code>01001101</code>, <code>01100001</code>, and <code>01101110</code>. These three values are joined together into a 24-bit string, producing <code>010011010110000101101110</code>. Groups of 6 bits (6 bits have a maximum of 2<sup>6</sup>&nbsp;=&nbsp;64 different binary values) are [[Binary number#Counting in binary|converted into individual numbers]] from start to end (in this case, there are four numbers in a 24-bit string), which are then converted into their corresponding Base64 character values.

As this example illustrates, Base64 encoding converts three [[octet (computing)|octets]] into four encoded characters.

{| class="wikitable" style="text-align:center;"
|+ Encoding of the source string ⟨Man⟩ in Base64
|- style="font-weight:bold;"
! rowspan=2 scope="row" | Source <br/>ASCII text
! scope="row" | Character
| colspan="8" | M
| colspan="8" | a
| colspan="8" | n
|-
! scope="row" | Octets
| colspan="8" | 77 (0x4d)
| colspan="8" | 97 (0x61)
| colspan="8" | 110 (0x6e)
|-
! colspan=2 scope="row" | Bits
| 0 || 1 || 0 || 0 || 1 || 1 || 0 || 1
| 0 || 1 || 1 || 0 || 0 || 0 || 0 || 1
| 0 || 1 || 1 || 0 || 1 || 1 || 1 || 0
|-
! rowspan=3 scope="row" | Base64<br/>encoded
! scope="row" | Sextets
| colspan="6" | 19
| colspan="6" | 22
| colspan="6" | 5
| colspan="6" | 46
|- style="font-weight:bold;"
! scope="row" | Character
| colspan="6" | T
| colspan="6" | W
| colspan="6" | F
| colspan="6" | u
|-
! scope="row" | Octets
| colspan="6" | 84 (0x54)
| colspan="6" | 87 (0x57)
| colspan="6" | 70 (0x46)
| colspan="6" | 117 (0x75)
|}

<code>=</code> padding characters might be added to make the last encoded block contain four Base64 characters.

[[Hexadecimal]] to [[octal]] transformation is useful to convert between binary and Base64. Such conversion is available for both advanced calculators and programming languages. For example, the hexadecimal representation of the 24 bits above is 4D616E. The octal representation is 23260556. Those 8 octal digits can be split into pairs ({{nowrap|23 26 05 56}}), and each pair is converted to decimal to yield {{nowrap|19 22 05 46}}. Using those four decimal numbers as indices for the Base64 alphabet, the corresponding ASCII characters are ''TWFu''.

If there are only two significant input octets (e.g., 'Ma'), or when the last input group contains only two octets, all 16 bits will be captured in the first three Base64 digits (18 bits); the two [[least significant bit]]s of the last content-bearing 6-bit block will turn out to be zero, and discarded on decoding (along with the succeeding <code>=</code> padding character):

{|class="wikitable" style="text-align:center;"
|- style="font-weight:bold;"
! rowspan=2 scope="row"   | Source <br/>ASCII text
! scope="row"             | Character
| colspan="8"             | M
| colspan="8"             | a
| colspan="8" rowspan="2"   {{n/a|}}
|-
! scope="row" | Octets
| colspan="8" | 77 (0x4d)
| colspan="8" | 97 (0x61)
|-
! colspan=2 scope="row" | Bits
| 0 || 1 || 0 || 0 || 1 || 1
| 0 || 1 || 0 || 1 || 1 || 0
| 0 || 0 || 0 || 1
| style="background-color:lightblue;" | 0
| style="background-color:lightblue;" | 0
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
|-
! rowspan=3 scope="row" | Base64<br/>encoded
! scope="row" | Sextets
| colspan="6" | 19
| colspan="6" | 22
| colspan="6" | 4
| colspan="6"   {{n/a|Padding}}
|- style="font-weight:bold;"
! scope="row" | Character
| colspan="6" | T
| colspan="6" | W
| colspan="6" | E
| colspan="6" | =
|-
! scope="row" | Octets
| colspan="6" | 84 (0x54)
| colspan="6" | 87 (0x57)
| colspan="6" | 69 (0x45)
| colspan="6" | 61 (0x3D)
|}

If there is only one significant input octet (e.g., 'M'), or when the last input group contains only one octet, all 8 bits will be captured in the first two Base64 digits (12 bits); the four [[least significant bit]]s of the last content-bearing 6-bit block will turn out to be zero, and discarded on decoding (along with the succeeding two <code>=</code> padding characters):

{| class="wikitable" style="text-align:center;"
|- style="font-weight:bold;"
! rowspan=2 scope="row"    | Source <br/>ASCII text
! scope="row"              | Character
| colspan="8"              | M
| colspan="16" rowspan="2"   {{n/a|}}
|-
! scope="row" | Octets
| colspan="8" | 77 (0x4d)
|-
! colspan=2 scope="row" | Bits
| 0 || 1 || 0 || 0 || 1 || 1
| 0 || 1
| style="background-color:lightblue;" | 0
| style="background-color:lightblue;" | 0
| style="background-color:lightblue;" | 0
| style="background-color:lightblue;" | 0

| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}

| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
| {{n/a|{{fsp}}}}
|-
! rowspan=3 scope="row" | Base64 <br/>encoded
! scope="row" | Sextets
| colspan="6" | 19
| colspan="6" | 16
| colspan="6"   {{n/a|Padding}}
| colspan="6"   {{n/a|Padding}}
|- style="font-weight:bold;"
! scope="row" | Character
| colspan="6" | T
| colspan="6" | Q
| colspan="6" | =
| colspan="6" | =
|-
! scope="row" | Octets
| colspan="6" | 84 (0x54)
| colspan="6" | 81 (0x51)
| colspan="6" | 61 (0x3D)
| colspan="6" | 61 (0x3D)
|}

===Output padding===
Because Base64 is a six-bit encoding, and because the decoded values are divided into 8-bit octets, every four characters of Base64-encoded text (4 sextets = {{times|4|6}} = 24 bits) represents three octets of unencoded text or data (3 octets = {{times|3|8}} = 24 bits). This means that when the length of the unencoded input is not a multiple of three, the encoded output must have padding added so that its length is a multiple of four. The padding character is <code>=</code>, which indicates that no further bits are needed to fully encode the input. (This is different from <code>A</code>, which means that the remaining bits are all zeros.) The example below illustrates how truncating the input of the above quote changes the output padding:

<!-- This is the encoding of **THE WHOLE** of the above passage and the ending fits in with both the above encoding and the first line of the following example, verified using
http://www.motobit.com/util/base64-decoder-encoder.asp
In the previous version, the example started with a space, which was not visible and thus quite misleading. -->
{|class="wikitable"
! scope="col" colspan=2 | Input
! scope="col" colspan=2 | Output
! scope="col" rowspan=2 | Padding
|-
! scope="col" | Text
! scope="col" | Length
! scope="col" | Text
! scope="col" | Length
|-
| ''light {{bg|lightgrey|wor}}{{bg|#cef2e0|k.}}'' || 11
| {{mono|1=bGlnaHQg{{bg|lightgrey|d29y}}{{bg|#cef2e0|2=ay4=}}}} || 16
| 1
|-
| ''light {{bg|lightgrey|wor}}{{bg|#cef2e0|k}}'' || 10
| {{mono|1=bGlnaHQg{{bg|lightgrey|d29y}}{{bg|#cef2e0|2=aw==}}}} || 16
| 2
|-
| ''light {{bg|lightgrey|wor}}'' || 9
| {{mono|1=bGlnaHQg{{bg|lightgrey|d29y}}}} || 12
| 0
|- 
| ''light {{bg|lightgrey|wo}}'' || 8
| {{mono|1=bGlnaHQg{{bg|lightgrey|2=d28=}}}} || 12
| 1
|-
| ''light {{bg|lightgrey|w}}'' || 7
| {{mono|1=bGlnaHQg{{bg|lightgrey|2=dw==}}}} || 12
| 2
|}

The padding character is not essential for decoding, since the number of missing bytes can be inferred from the length of the encoded text. In some implementations, the padding character is mandatory, while for others it is not used. An exception in which padding characters are required is when multiple Base64 encoded files have been concatenated.

===Decoding Base64 with padding===
When decoding Base64 text, four characters are typically converted back to three bytes. The only exceptions are when padding characters exist. A single <code>=</code> indicates that the four characters will decode to only two bytes, while <code>==</code> indicates that the four characters will decode to only a single byte. For example:

{| class="wikitable"
! Encoded !! Padding !! Length !! Decoded
|-
| {{mono|1=bGlnaHQg{{bg|lightgrey|2=dw==}}}}
| <code>==</code> || 1
| ''light {{bg|lightgrey|w}}''
|-
| {{mono|1=bGlnaHQg{{bg|lightgrey|2=d28=}}}}
| <code>=</code> || 2
| ''light {{bg|lightgrey|wo}}''
|-
| {{mono|1=bGlnaHQg{{bg|lightgrey|d29y}}}}
| {{CNone|None}} || 3
| ''light {{bg|lightgrey|wor}}''
|}
Another way to interpret the padding character is to consider it as an instruction to discard 2 trailing bits from the bit string each time a <code>=</code> is encountered. For example, when `{{mono|1=bGlnaHQg{{bg|lightgrey|2=dw==}}}}` is decoded, we convert each character (except the trailing occurrences of <code>=</code>) into their corresponding 6-bit representation, and then discard 2 trailing bits for the first <code>=</code> and another 2 trailing bits for the other <code>=</code>. In this instance, we would get 6 bits from the <code>d</code>, and another 6 bits from the <code>w</code> for a bit string of length 12, but since we remove 2 bits for each <code>=</code> (for a total of 4 bits), the <code>dw==</code> ends up producing 8 bits (1 byte) when decoded.

===Decoding Base64 without padding===
Without padding, after normal decoding of four characters to three bytes over and over again, fewer than four encoded characters may remain. In this situation, only two or three characters can remain. A single remaining encoded character is not possible, because a single Base64 character only contains 6 bits, and 8 bits are required to create a byte, so a minimum of two Base64 characters are required: The first character contributes 6 bits, and the second character contributes its first 2 bits. For example:

{| class="wikitable"
! Length !! Encoded !! Length !! Decoded
|-
| 2 || {{mono|1=bGlnaHQg{{bg|lightgrey|dw}}}}
| 1 || ''light {{bg|lightgrey|w}}''
|-
| 3 || {{mono|1=bGlnaHQg{{bg|lightgrey|d28}}}}
| 2 || ''light {{bg|lightgrey|wo}}''
|-
| 4 || {{mono|1=bGlnaHQg{{bg|lightgrey|d29y}}}}
| 3 || ''light {{bg|lightgrey|wor}}''
|}

Decoding without padding is not performed consistently among decoders. In addition, allowing padless decoding by definition allows multiple strings to decode into the same set of bytes, which can be a security risk.<ref>{{cite conference |last1=Chalkias |first1=Konstantinos |last2=Chatzigiannis |first2=Panagiotis |title=Base64 Malleability in Practice |conference=ASIA CCS '22: 2022 ACM on Asia Conference on Computer and Communications Security |date=30 May 2022 |pages=1219–1221 |doi=10.1145/3488932.3527284 |url=https://eprint.iacr.org/2022/361.pdf}}</ref>

==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 alphabet at positions 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 provides links to the subsections below.
{|class="wikitable" style="text-align:center"
! rowspan=2 | Encoding
! colspan=3 | Encoding characters
! colspan=3 | Separate encoding of lines
! rowspan=2 | Decoding non-encoding characters
|-
! 62nd
! 63rd
! ''pad''
! Separators
! Length
! Checksum
|-
! {{rh}} | {{nowrap|[https://datatracker.ietf.org/doc/html/rfc1421 RFC 1421]}}: Base64 for [[#Privacy-enhanced mail|Privacy-Enhanced Mail]] (deprecated)
| <code>+</code> || <code>/</code> || {{yes|{{code|{{=}}}} mandatory}}
| {{yes|CR+LF}} || {{Yes|64, or lower for the last line}} || {{No}} || {{No}}
|-
! {{rh}} | {{nowrap|[https://datatracker.ietf.org/doc/html/rfc2045 RFC 2045]}}: Base64 transfer encoding for [[#MIME|MIME]]
| <code>+</code> || <code>/</code> || {{yes|{{code|{{=}}}} mandatory}}
| {{yes|CR+LF}} || {{Yes|At most 76}} || {{No}} || {{partial|Discarded}}
|-
! {{rh}} | {{nowrap|[https://datatracker.ietf.org/doc/html/rfc2152 RFC 2152]}}: Base64 for [[#UTF-7|UTF-7]]
| <code>+</code> || <code>/</code> || {{No}}
| colspan=3 {{No}} || {{No}}
|-
! {{rh}} | {{nowrap|[https://datatracker.ietf.org/doc/html/rfc3501#section-5.1.3 RFC 3501]}}: Base64 encoding for IMAP mailbox names
| <code>+</code> || <code>,</code> || {{No}}
| colspan=3 {{No}} || {{No}}
|-
! {{rh}} | {{nowrap|[https://datatracker.ietf.org/doc/html/rfc4648#section-4 RFC 4648 §4]}}: base64 (standard){{efn|name=common|This variant is intended to provide common features where they are not desired to be specialized by implementations, ensuring robust engineering. This is particularly in light of separate line encodings and restrictions, which have not been considered when previous standards have been co-opted for use elsewhere. Thus, the features indicated here may be overridden.}}
| <code>+</code> || <code>/</code> || {{Optional|{{code|{{=}}}} optional}} 
| colspan=3 {{No}} || {{No}} 
|-
! {{rh}} | {{nowrap|[https://datatracker.ietf.org/doc/html/rfc4648#section-5 RFC 4648 §5]}}: base64url (URL- and filename-safe standard){{efn|name=common}}
| <code>-</code> || <code>_</code> || {{Optional|{{code|{{=}}}} optional}}
| colspan=3 {{No}} || {{No}} 
|-
! {{rh}} | {{nowrap|[https://datatracker.ietf.org/doc/html/rfc4880 RFC 4880]}}: Radix-64 for [[#OpenPGP|OpenPGP]]
| <code>+</code> || <code>/</code> || {{yes|{{code|{{=}}}} mandatory}}
| {{yes|CR+LF}} || {{Yes|At most 76}} || {{Optional|Radix-64 encoded 24-bit [[cyclic redundancy check|CRC]]}} || {{No}}
|-
! {{rh}} | Other variations
| colspan="7" | See {{section link||Applications not compatible with RFC 4648 Base64}}
|}
{{notelist}}

===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 {{IETF RFC|989}} in 1987. PEM defines a "printable encoding" scheme that uses Base64 encoding to transform an arbitrary sequence of [[octet (computing)|octets]] to a format that can be expressed in short lines of 6-bit characters, as required by transfer protocols such as [[SMTP]].<ref>{{cite IETF |title=Privacy Enhancement for Internet Electronic Mail |rfc=989 |date=February 1987 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=March 18, 2010}}</ref>

The current version of PEM (specified in {{IETF RFC|1421}}) uses a 64-character alphabet consisting of upper- and lower-case [[Roman letters]] (<code>A</code>–<code>Z</code>, <code>a</code>–<code>z</code>), the numerals (<code>0</code>–<code>9</code>), and the <code>+</code> and <code>/</code> symbols. The <code>=</code> symbol is also used as a padding suffix.<ref name="rfc 1421"/> The original specification, {{IETF RFC|989}}, additionally used the <code>*</code> 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 bit|most significant]] eight bits of a 24-bit [[data buffer|buffer]], the next in the middle eight, and the third in the [[least significant bit|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: "<code>ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/</code>", 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 <code>=</code> characters are appended to the output; if one octet of the 24-bit buffer is filled with padded-zeros, one <code>=</code> 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|MIME}}

The [[MIME]] (Multipurpose Internet Mail Extensions) specification lists Base64 as one of two [[binary-to-text encoding]] schemes (the other being [[quoted-printable]]).<ref name="rfc 2045"/> MIME's Base64 encoding is based on that of the {{IETF RFC|1421}} version of PEM: it uses the same 64-character alphabet and encoding mechanism as PEM and uses the <code>=</code> symbol for output padding in the same way, as described at {{IETF RFC|2045}}.

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 character outside the standard set of 64 encoding characters (For example CRLF sequences), 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 ({{fract|4|3}}×{{fract|78|76}}), though for very short messages the overhead can be much higher due to 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). The size of the decoded data can be approximated with this formula:
 bytes = (string_length(encoded_string) − 814) / 1.37

===UTF-7===
{{Main|UTF-7}}
[[UTF-7]], described first in {{IETF RFC|1642}}, which was later superseded by {{IETF 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.<ref>{{cite IETF |title=UTF-7 A Mail-Safe Transformation Format of Unicode |rfc=1642 |date=July 1994 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=March 18, 2010}}</ref><ref>{{cite IETF |title=UTF-7 A Mail-Safe Transformation Format of Unicode |rfc=2152 |date=May 1997 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=March 18, 2010}}</ref>

The "Modified Base64" alphabet consists of the MIME Base64 alphabet, but does not use the "<code>=</code>" padding character. UTF-7 is intended for use in mail headers (defined in {{IETF RFC|2047}}), and the "<code>=</code>" 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===
{{further|Pretty Good Privacy#OpenPGP}}
[[OpenPGP]], described in {{IETF RFC|4880}}, 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 [[cyclic redundancy check|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 "<code>=</code>" symbol as the separator, appended to the encoded output data.<ref>{{cite IETF |title=OpenPGP Message Format |rfc=4880 |date=November 2007 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=March 18, 2010}}</ref>

===RFC 3548===
{{IETF RFC|3548}}, entitled ''The Base16, Base32, and Base64 Data Encodings'', is an informational (non-normative) memo that attempts to unify the {{IETF RFC|1421}} and {{IETF RFC|2045}} 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 {{IETF RFC|3548}} 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.<ref name="rfc 3548" />

===RFC 4648===
{{IETF RFC|4648}} obsoletes {{IETF 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, the use of padding in encoded data, the use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.''

===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 (programming language)|Java]] objects might use Base64 encoding to encode a relatively large unique id (generally 128-bit [[UUID]]s) into a string for use as an HTTP parameter in HTTP forms or HTTP GET [[URL]]s. 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 a compact way.

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

For this reason, '''modified Base64 for URL''' variants exist (such as  '''base64url''' in {{IETF RFC|4648}}), where the '<code>+</code>' and '<code>/</code>' characters of standard Base64 are respectively replaced by '<code>-</code>' and '<code>_</code>', so that using [[percent-encoding|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. A popular site to make use of such is [[YouTube#Uploading|YouTube]].<ref>{{cite web |title=Here's Why YouTube Will Practically Never Run Out of Unique Video IDs |url=https://www.mentalfloss.com/article/77598/heres-why-youtube-will-never-run-out-unique-video-ids |website=www.mentalfloss.com |access-date=27 December 2021 |language=en |date=23 March 2016}}</ref> Some variants allow or require omitting the padding '<code>=</code>' signs to avoid them being confused with field separators, or require that any such padding be percent-encoded. Some libraries {{which|date=December 2020}} will encode '<code>=</code>' to '<code>.</code>', potentially exposing applications to relative path attacks when a folder name is encoded from user data.{{Citation needed|date=June 2022}}

===Javascript (DOM Web API) ===
The <code>atob()</code> and <code>btoa()</code> JavaScript methods, defined in the HTML5 draft specification,<ref>{{cite web|title=7.3. Base64 utility methods|url=https://w3c.github.io/html/webappapis.html#atob|website=HTML 5.2 Editor's Draft|publisher=[[World Wide Web Consortium]]|access-date=2 January 2018}} Introduced by [http://html5.org/tools/web-apps-tracker?from=5813&to=5814 changeset 5814], 2021-02-01.</ref> provide Base64 encoding and decoding functionality to web pages. The <code>btoa()</code> method outputs padding characters, but these are optional in the input of the <code>atob()</code> method.

===Other applications===
[[File:35_mm_angle_of_view_vs_focal_length.svg|thumb|link={{filepath:35_mm_angle_of_view_vs_focal_length.svg}}|Example of an SVG file containing embedded JPEG images encoded in Base64<ref>&lt;image xlink:href="data:image/jpeg;base64,<code>JPEG contents encoded in Base64</code>" ... /&gt;</ref>]]
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 used to encode character strings in [[LDAP Data Interchange Format]] files
* Base64 is often used to embed binary data in an [[XML]] file, using a syntax similar to <code><nowiki><data encoding="base64">…</data></nowiki></code> e.g. [[favicon]]s in [[Firefox]]'s exported <code>bookmarks.html</code>.
* Base64 is used to encode binary files such as images within scripts, to avoid depending on external files.
* Base64 can be used to embed [[PDF]] files in HTML pages.<ref>{{Cite web |title=Encode PDF (Portable Document Format) File (.pdf) to Base64 Data |url=https://base64.online/encoders/encode-pdf-to-base64?utm_campaign=og |access-date=2024-03-21 |website=base64.online |language=en}}</ref>
* 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 <code>data:</code> URIs, instead of being supplied in separate files.
* Although not part of the official specification for the [[SVG]] format, some viewers can interpret Base64 when used for embedded elements, such as raster images inside SVG files.<ref>{{cite web|url=http://jsfiddle.net/MxHPq/|title=Edit fiddle |website=jsfiddle.net}}</ref>
* Base64 can be used to store/transmit relatively small amounts of binary data via a computer's text [[Clipboard (computing)|clipboard]] functionality, especially in cases where the information doesn't warrant being permanently saved or when information must be quickly sent between a wide variety of different, potentially incompatible programs. An example is the representation of the public keys of [[cryptocurrency]] recipients as Base64 encoded text strings, which can be easily copied and pasted into users' [[Cryptocurrency wallet|wallet software]]. 
* Binary data that must be quickly verified by humans as a safety mechanism, such as [[Checksum|file checksums]] or [[Public key fingerprint|key fingerprints]], is often represented in Base64 for easy checking, sometimes with additional formattings, such as separating each group of four characters in the representation of a [[Pretty Good Privacy|PGP]] key fingerprint with a space. 
* [[QR code]]s which contain binary data will sometimes store it encoded in Base64 rather than simply storing the raw binary data, as there is a stronger guarantee that all QR code readers will accurately decode text, as well as the fact that some devices will more readily save text from a QR code than potentially malicious binary data.

=== Applications not compatible with RFC 4648 Base64 ===
Some applications use a Base64 alphabet that is significantly different from the alphabets used in the most common Base64 variants (see [[Base64#Variants summary table|Variants summary table]] above).

* The '''[[Uuencoding]]''' alphabet includes no lowercase characters, instead using ASCII codes 32 ("<code>&nbsp;</code>" (space)) through 95 ("<code>_</code>"), consecutively. Uuencoding uses the alphabet <span class="nowrap">"<code>&nbsp;!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_</code>"</span>. Avoiding all lower-case letters was helpful, because many older printers only printed uppercase. Using consecutive ASCII characters saved computing power, because it was only necessary to add 32, without requiring a lookup table. Its use of most punctuation characters and the space character may limit its usefulness in some applications, such as those that use these characters as syntax.{{citation needed|date=April 2016}}
* [[BinHex|'''BinHex 4''']] (HQX), which was used within the [[classic Mac OS]], excludes some visually confusable characters like '<code>7</code>', '<code>O</code>', '<code>g</code>' and '<code>o</code>'. Its alphabet includes additional punctuation characters. It uses the alphabet <span class="nowrap">"<code><nowiki>!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr</nowiki></code>"</span>.
* A [[UTF-8]] environment can use non-synchronized continuation bytes as base64: <code>0b10<b>xxxxxx</b></code>. See [[UTF-8#Comparison with other encodings|UTF-8#Self-synchronization]].
* Several other applications use alphabets similar to the common variations, but in a different order:
** Unix stores password hashes computed with [[crypt (C)|'''crypt''']] in the [[passwd#Password file|<code>/etc/passwd</code> file]] using an encoding called <span id="B64">B64</span>. crypt's alphabet puts the punctuation <code>.</code> and <code>/</code> before the alphanumeric characters. crypt uses the alphabet "<code>./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz</code>" without padding. An advantage over RFC 4648 is that sorting encoded ASCII data results in the same order as sorting the plain ASCII data.
** The '''[[GEDCOM]]''' 5.5 standard for genealogical data interchange encodes multimedia files in its text-line hierarchical file format. GEDCOM uses the same alphabet as crypt, which is <span class="nowrap">"<code>./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz</code>"</span>.<ref>{{cite web|url=http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gctoc.htm |title=The GEDCOM Standard Release 5.5 |publisher=Homepages.rootsweb.ancestry.com |access-date=2012-06-21}}</ref>
** '''[[bcrypt]]''' hashes are designed to be used in the same way as traditional crypt(3) hashes, but bcrypt's alphabet is in a different order than crypt's. bcrypt uses the alphabet <span class="nowrap">"<code>./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789</code>"</span>.<ref>{{cite web|url=https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/bcrypt.c?rev=1.1&content-type=text/x-cvsweb-markup|title=src/lib/libc/crypt/bcrypt.c r1.1|author-link=Niels Provos|first=Niels|last=Provos|date=1997-02-13|access-date=2018-05-18}}</ref>
** '''[[Xxencoding]]''' uses a mostly-alphanumeric character set similar to crypt, but using <code>+</code> and <code>-</code> rather than <code>.</code> and <code>/</code>. Xxencoding uses the alphabet <span class="nowrap">"<code>+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz</code>"</span>.
** '''6PACK''', used with some [[terminal node controller]]s, uses an alphabet from 0x00 to 0x3f.<ref>{{cite web|url=http://private.freepage.de/cgi-bin/feets/freepage_ext/41030x030A/rewrite/alexs/xfr/flexnet/6pack_en/6pack.htm|title=6PACK a "real time" PC to TNC protocol|access-date=2013-05-19|archive-date=2012-02-24|archive-url=https://web.archive.org/web/20120224051938/http://private.freepage.de/cgi-bin/feets/freepage_ext/41030x030A/rewrite/alexs/xfr/flexnet/6pack_en/6pack.htm|url-status=dead}}</ref>
** [[Bash (Unix shell)|'''Bash''']] supports numeric literals in Base64. Bash uses the alphabet <span class="nowrap">"<code>0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_</code>"</span>.<ref>{{cite web |title=Shell Arithmetic |url=https://www.gnu.org/software/bash/manual/html_node/Shell-Arithmetic.html |website=Bash Reference Manual |access-date=8 April 2020 |quote=Otherwise, numbers take the form [base#]n, where the optional base is a decimal number between 2 and 64 representing the arithmetic base, and n is a number in that base.}}</ref>

==See also==
* [[8BITMIME]]
* [[Ascii85]] (also called Base85)
* [[Base16]]
* [[Base32]]
* [[Base36]]
* [[Base62]]
* [[Binary-to-text encoding]] for a comparison of various encoding algorithms
* [[Binary number]]
* [[URL]]

==References==
{{Reflist|2}}

{{Data Exchange}}

[[Category:Usenet]]
[[Category:Email]]
[[Category:Internet Standards]]
[[Category:Binary-to-text encoding formats]]
[[Category:Data serialization formats]]
[[Category:Power-of-two numeral systems]]