Base64は、データを64種類の印字可能な英数字のみを用いて、それ以外の文字を扱うことの出来ない通信環境にてマルチバイト文字やバイナリデータを扱うためのエンコード方式である。当初PEM () がPrintable Encodingという名で規定した仕様を、MIMEがBase64と名付け、、 らが再度規定した。7ビットのデータしか扱うことの出来ない電子メールにて広く利用されている。具体的には、A、…、Z、a、…、z、0、…、9 の62種類の文字ISO基本ラテンアルファベット（いわゆるアルファベット）が大文字・小文字の各26文字とアラビア数字の10文字。と、2種類の記号 (+、/)、さらにパディング（埋め草）のための記号として = が用いられる。この変換によって、データ量は4/3（約133%）となり元データを6ビット区切りにし、6ビットのそれぞれを印字可能な64文字の内の1文字に置き換える。その1文字1文字は8ビットなので、元の6ビットを8ビットで表現するわけである。よって、データ量は8/6つまり4/3となる。、増加する。また、MIMEの基準では76文字ごとに改行コードが入るため、この分の2バイトを計算に入れるとデータ量は約137%となるBase64エンコード後の1文字は、元のデータの6ビットを表現しているので、Base64エンコード後が76文字ということは、元のデータは、76 × 6ビット = 456ビット = 57バイトである。57バイトを76 + 2 = 78バイトで表現しているので、データ量は78 ÷ 57 ≒ 1.37 = 137%となる。。
変換形式 Base64変換の手順を以下に挙げる。
元データを6ビットずつに分割する。（6ビットに満たない分は後ろに0を追加して6ビットにする） 各6ビットの値を変換表を使って4文字ずつ変換する。 4文字に足りない分は = 記号を後ろに追加する。 変換例 段階状態データ1元データ"ABCDEFG"（文字列）26ビットずつに分割{010000, 010100, 001001, 000011, 010001, 000100, 010101, 000110, 010001, 11}（ビット列の列）32ビット余るので、4ビット分0を追加して6ビットにする{010000, 010100, 001001, 000011, 010001, 000100, 010101, 000110, 010001, 110000}（ビット列の列）4変換表により、4文字ずつ変換する{"QUJD", "REVG"、"Rw"}（文字列の列）5最後の文字列が2文字足りないので、2文字分 = 記号を追加して4文字にする{"QUJD", "REVG", "Rw=="}（文字列の列）6連結してBase64文字列にする"QUJDREVGRw=="（文字列）
変換表 6ビットのビット列に対して一つの文字を対応づけているだけである。
ビット列 Base64文字000000A000001B000010C000011D000100E000101F000110G000111H001000I001001J001010K001011L001100M001101N001110O001111P ビット列 Base64文字010000Q010001R010010S010011T010100U010101V010110W010111X011000Y011001Z011010a011011b011100c011101d011110e011111f ビット列 Base64文字100000g100001h100010i100011j100100k100101l100110m100111n101000o101001p101010q101011r101100s101101t101110u101111v ビット列 Base64文字110000w110001x110010y110011z1101000110101111011021101113111000411100151110106111011711110081111019111110+111111/
主な利用例 電子メール 電子メールでは、SMTPなどの制約により、7ビット文字列以外をやり取りすることは出来ない。このため、添付ファイルなどのバイナリ形式のデータを送信する際に標準的に利用されている。
Basic認証 HTTPヘッダでは、特殊記号を使用することが出来ないため、ユーザー名とパスワードをコロン (:) で区切ってBase64エンコードした文字列がBasic認証に用いられている。
電子掲示板 インターネット上の電子掲示板では、文字列以外のバイナリデータの書き込みは基本的に不可能である。そこで、画像やテキスト文章を圧縮したファイルなどをやり取りするために、この形式が使用されることがある。
問題点 このエンコードを行うとデータ量が大きく増加するため、特に大きなファイルの送受信などをする場合は、電子メール以外の手段を利用したほうが格段に速い場合がある。また、英文の中に特殊文字が混じっているテキスト文章などは、特殊文字だけをエンコードした方がデータ効率が良く、デコードを行わなくても大体のデータが読めると言う利点がある。（Quoted-printable参照）
変形版 URLにBase64を含ませると、+ と / が問題を引き起こすことがある。これらの文字がURLで特別な意味を持つために %h1h0h1 と h0 にはそれぞれ16進数の数字の一文字が入る。の形にエスケープする必要が生じるためである。 他にも、+ と / が特別な意味をもつ個所（正規表現など）やその使用が制限される個所（XMLなど）でBase64を用いるときには、この2文字のかわりに !、-、. などを用いることがある。
変形 62番目の文字 63番目の文字 パディング 1行が固定長か 行の最大長 改行文字 指定された文字以外を使えるかどうか 行のチェックサム オリジナルの Privacy-Enhanced Mail (PEM) の Base64(RFC 1421、deprecated) + / =(必須) はい(最終行を除く) 64 CR+LF 禁止 (なし) MIME の Base64 転送エンコーディング(RFC 2045) + / =(必須) いいえ(可変) 76 CR+LF 許可(破棄される) (なし) RFC 3548 や RFC 4648 の標準の 'Base64' エンコーディング + / =(必須) はい(最終行を除く) 64 または 76(改行が必要な場合のみ) CR+LF(改行が必要な場合のみ) 禁止 (なし) OpenPGP用「Radix-64」(RFC 4880) + / =(必須) いいえ(可変) 76 CR+LF 禁止 24ビットCRC(Radix-64-encoded, including one pad character) UTF-7 のための変形 Base64(RFC 1642、obsoleted) + / (なし) いいえ(可変) (なし) (なし) 禁止 (なし) ファイル名のための変形 Base64(非標準) + - (なし) いいえ(可変) (ファイルシステムの限界、一般には255) (なし) 禁止 (なし) URLアプリケーションのための変形 Base64('base64url' encoding) - _ (なし) いいえ(可変) アプリケーション依存 (なし) 禁止 (なし) XML名前トークン向け修正Base64(Nmtoken) . - (なし) いいえ(可変) XML パーサー依存 (なし) 禁止 (なし) XML識別子向け修正Base64(Name) _ : (なし) いいえ(可変) XML パーサー依存 (なし) 禁止 (なし) プログラム識別子向け修正Base64（変種1，非標準） _ - (なし) いいえ(可変) 言語・システム依存 (なし) 禁止 (なし) プログラム識別子向け修正Base64（変種2，非標準） . _ (なし) いいえ(可変) 言語・システム依存 (なし) 禁止 (なし) 正規表現のための変形 Base64(非標準) ! - (なし) いいえ(可変) アプリケーション依存 (なし) 禁止 (なし)
注釈
脚注
関連項目 URLエンコード uuencode BinHex ish 二進法 四進法 八進法 十六進法 Base32 Base58
外部リンク - IETFによるBase16とBase32とBase64の規格書 RFC 4648の参考和訳 Online Base64 Encoding Online Base64 Decoding