Base64は、画像や圧縮ファイルといったバイナリデータを、英数字を中心とした64種類の印字可能な文字だけで表すための「エンコード（符号化）」方式です。メール・Data URL・JSON など、テキストしか安全に運べない場面でバイナリを載せるために広く使われています。本記事では、その仕組み・用途・UTF-8の注意点・URLセーフBase64までを、実際の変換例とともに整理します。
1. Base64とは何か
Base64は、任意のバイナリ（0〜255の値を取るバイト列）を、A–Z・a–z・0–9・+・/ の64文字だけで表現する変換です。これらはほぼすべてのシステムで安全に扱える「印字可能なASCII文字」なので、テキストを前提とした経路でもバイナリを壊さずに運べます。
名前の「64」は、表現に使う文字が64種類であることに由来します。前述のとおり、これは可逆な符号化であって暗号化でも圧縮でもありません。むしろ後述のとおりサイズは増えます。
2. 仕組み — 3バイトを4文字に
Base64の基本単位は3バイト（=24ビット）です。この24ビットを6ビットずつ4つに区切り、それぞれの6ビット値（0〜63）を64文字の表に対応させて4文字に変換します。
- 1バイトは8ビット。8 × 3 = 24ビットをまとめて扱う。
- 24ビットを6ビット × 4に分割する（6ビットで0〜63の64通り）。
- 各6ビット値を、A=0, B=1, …, Z=25, a=26, …, z=51, 0=52, …, 9=61,
+=62,/=63 の表で文字化する。
パディング（=）の役割
元データが3の倍数バイトでないとき、6ビット単位にきれいに割り切れません。残りが1バイトなら出力末尾に ==、2バイトなら = を付け、出力が常に4文字単位になるようパディングします。= はデータではなく「長さ合わせの詰め物」です。
3. かんたんな変換例（Man → TWFu）
古典的な例として、文字列 Man を変換してみます。Man はちょうど3バイトなのでパディングは不要です。
- 各文字をASCIIコードに：
M=77,a=97,n=110。 - 8ビット2進数に：
01001101 01100001 01101110（連結して24ビット）。 - 6ビットずつ区切る：
010011 010110 000101 101110。 - 10進に：
19 22 5 46。 - 表で文字化：
19=T,22=W,5=F,46=u。
結果、Man は TWFu になります。3バイトが4文字になっている点に注目してください。
4. なぜ使うのか（用途）
Base64は「テキストしか安全に通せない経路でバイナリを運ぶ」ために使われます。代表的な場面は次のとおりです。
- メール（MIME）：添付ファイルや画像を、テキストベースのメール本文に載せるための標準的な符号化方式。
- Data URL：
data:image/png;base64,iVBORw0K...のように、画像などをHTML/CSSへ直接埋め込み、別ファイルの読み込みを省く。 - JSON / HTTPヘッダ：バイナリやUTF-8外のデータを、テキスト前提のフィールドに安全に格納する。
- Basic認証・JWT：資格情報やトークンをテキストとして受け渡す（※可読なので秘匿目的ではない）。
5. UTF-8の注意点（日本語・絵文字）
ブラウザの btoa() はLatin-1（0〜255）の範囲のバイト列しか受け取れません。そのため、日本語や絵文字を含む文字列をそのまま btoa('こんにちは') のように渡すと例外（エラー）になります。
正しくは、文字列を先にUTF-8のバイト列へ変換してからBase64化します。古くからある書き方は次のとおりです。
- 符号化：
btoa(unescape(encodeURIComponent(s)))—encodeURIComponentでUTF-8の%エスケープにし、unescapeで各バイトをLatin-1文字へ戻してからbtoaに渡します。 - 復号：
decodeURIComponent(escape(atob(b)))— 逆の手順で元の文字列に戻します。
TextEncoder / TextDecoder を使い、文字列を Uint8Array のUTF-8バイト列にしてから符号化する方法が推奨されます。いずれにせよ、ポイントは「先にUTF-8バイトへ」という点です。当サイトのツールはこの変換を内部で行うため、日本語や絵文字もそのまま扱えます。
6. URLセーフBase64とサイズの話
標準Base64で使う + と / は、URLやファイル名では特別な意味を持つ（/ はパス区切り、+ は空白として解釈されうる）ため、そのままでは扱いにくいことがあります。そこで RFC 4648 §5 では、これらを置き換えたURLセーフな変種が定義されています。
| 項目 | 標準Base64 | URLセーフBase64 |
|---|---|---|
| 62番目の文字 | + | -（ハイフン） |
| 63番目の文字 | / | _（アンダースコア） |
| パディング | = を付与 | 省略されることが多い |
| 主な用途 | MIME・Data URLなど | URL・ファイル名・JWTなど |
もう一点、実用上の注意はサイズです。3バイトが4文字になるため、出力は元データより約33%（4/3倍）大きくなります（改行を含めるとさらに増えます）。小さな画像の埋め込みには便利ですが、大きなファイルでは増加分に注意してください。
Free Tool Base64 エンコード / デコードを試す テキストやデータをBase64へ符号化・復号できます。日本語・絵文字もUTF-8変換を内部で行うので、そのまま入力するだけで利用できます。よくある質問（FAQ）
Base64は暗号化ですか？
いいえ。Base64は暗号化ではなく、バイナリデータを印字可能な64種類の文字へ変換する「エンコード（符号化）」です。鍵を必要とせず、誰でも元のデータに戻せるため、機密情報の保護には使えません。秘匿が必要な場合は別途、暗号化を行ってください。
日本語が文字化けするのはなぜですか？
ブラウザのbtoa()はLatin-1（0〜255）の範囲しか扱えず、日本語や絵文字のような範囲外の文字をそのまま渡すとエラーや文字化けになります。先に文字列をUTF-8のバイト列へ変換してからBase64化する必要があります。古い書き方ではbtoa(unescape(encodeURIComponent(s)))が使われ、現在はTextEncoderを使う方法が推奨されます。
URLセーフBase64とは何ですか？
標準のBase64で使う「+」と「/」はURLやファイル名で特別な意味を持つため、RFC 4648 §5ではこれらを「-」と「_」に置き換えた変種が定義されています。これがURLセーフBase64で、JWTなどで広く使われます。パディングの「=」は省略されることが多いです。