この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "Base64" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL（2023年12月）

Base64は、データを64種類の印字可能な英数字のみを用いて、それ以外の文字を扱うことの出来ない通信環境にてマルチバイト文字やバイナリデータを扱うためのエンコード方式である。MIMEによって規定されていて、7ビットのデータしか扱うことの出来ない電子メールにて広く利用されている。具体的には、A、…、Z、a、…、z、0、…、9 の62種類の文字[注釈 1]と、2種類の記号 (+、/)、さらにパディング（余った部分を詰める）のための記号として = が用いられる。この変換によって、データ量は4/3（約133%）となり[注釈 2]、増加する。また、MIMEの基準では76文字ごとに改行コードが入るため、この分の2バイトを計算に入れるとデータ量は約137%となる[注釈 3]。
変換形式

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文字
000000A
000001B
000010C
000011D
000100E
000101F
000110G
000111H
001000I
001001J
001010K
001011L
001100M
001101N
001110O
001111P

ビット列Base64文字
010000Q
010001R
010010S
010011T
010100U
010101V
010110W
010111X
011000Y
011001Z
011010a
011011b
011100c
011101d
011110e
011111f

ビット列Base64文字
100000g
100001h
100010i
100011j
100100k
100101l
100110m
100111n
101000o
101001p
101010q
101011r
101100s
101101t
101110u
101111v

ビット列Base64文字
110000w
110001x
110010y
110011z
1101000
1101011
1101102
1101113
1110004
1110015
1110106
1110117
1111008
1111019
111110+
111111/


主な利用例
電子メール

電子メールでは、SMTPなどの制約により、7ビット文字列以外をやり取りすることは出来ない。このため、添付ファイルなどのバイナリ形式のデータを送信する際に標準的に利用されている。
Basic認証

HTTPヘッダでは、特殊記号を使用することが出来ないため、ユーザー名とパスワードをコロン (:) で区切ってBase64エンコードした文字列がBasic認証に用いられている。
電子掲示板

インターネット上の電子掲示板では、文字列以外のバイナリデータの書き込みは基本的に不可能である。そこで、画像やテキスト文章を圧縮したファイルなどをやり取りするために、この形式が使用されることがある。
問題点

このエンコードを行うとデータ量が大きく増加するため、特に大きなファイルの送受信などをする場合は、電子メール以外の手段を利用したほうが格段に速い場合がある。また、英文の中に特殊文字が混じっているテキスト文章などは、特殊文字だけをエンコードした方がデータ効率が良く、デコードを行わなくても大体のデータが読めると言う利点がある。（Quoted-printable参照）
変形版

URLにBase64を含ませると、+ と / が問題を引き起こすことがある。これらの文字がURLで特別な意味を持つために %h1h0[注釈 4]の形にエスケープする必要が生じるためである。他にも、+ と / が特別な意味をもつ個所（正規表現など）やその使用が制限される個所（XMLなど）でBase64を用いるときには、この2文字のかわりに !、-、. などを用いることがある。

変形62番目の文字63番目の文字パディング1行が固定長か行の最大長改行文字指定された文字以外を使えるかどうか行のチェックサム
オリジナルの Privacy-Enhanced Mail (PEM) の Base64
(RFC 1421、deprecated)+/=
(必須)はい
(最終行を除く)64CR+LF禁止(なし)
MIME の Base64 転送エンコーディング
(RFC 2045)+/=
(必須)いいえ
(可変)76CR+LF許可
(破棄される)(なし)
RFC 3548 や RFC 4648 の標準の 'Base64' エンコーディング+/=