Base64とは｜仕組みとData URIの使いどころ、暗号化との決定的な違い
APIのレスポンスやHTMLの中に iVBORw0KGgoAAAANSUhEUg... のような長い文字列が出てくることがあります。Base64です。仕組みは単純ですが、使いどころを誤るとページが重くなり、扱いを誤ると重大なセキュリティ上の誤解につながります。
最重要：Base64は暗号化ではありません
先に、最も重要な点から書きます。
Base64は「変換」であって「暗号化」ではありません。 鍵は不要で、誰でも1秒で元に戻せます。
アプリのパスワード:secret123
↓ Base64
44Ki44OX44Oq44Gu44OR44K544Ov44O844OJOnNlY3JldDEyMw==一見読めないため「隠せている」と錯覚しますが、デコードするだけで完全に元に戻ります。 次の用途は、すべて誤りです。
- パスワードをBase64にして設定ファイルに保存する
- 個人情報をBase64にして「暗号化した」と扱う
- APIキーをBase64にしてフロントエンドに埋め込む
秘匿が目的なら、鍵を使う暗号化が必要です。テキスト暗号化ツールはAES-256-GCMによる暗号化に対応しており、パスワードを知らなければ復号できません。Base64と暗号化はまったく別のものです。
| 目的 | 鍵 | 元に戻せるか | |
|---|---|---|---|
| Base64 | データを安全に運ぶため | 不要 | 誰でも戻せる |
| 暗号化 | データを秘匿するため | 必要 | 鍵があれば戻せる |
| ハッシュ化 | データの同一性を確認するため | 不要 | 戻せない |
Base64は何のためにあるのか
目的は「バイナリデータを、テキストしか通せない経路で運ぶこと」です。
メール（SMTP）やHTTPヘッダー、JSON、XMLといった仕組みは、もともとテキストを前提に作られています。画像や実行ファイルのようなバイナリをそのまま流すと、制御文字が誤って解釈されたり、途中の機器がデータを壊したりします。
そこで、バイナリを「安全な64種類の文字」だけで表現し直すのがBase64です。使われる文字は次のとおりです。
A-Z（26） + a-z（26） + 0-9（10） + "+" + "/" = 64種類
末尾の桁合わせに "=" を使う仕組みと、33%増える理由
Base64は、3バイトのデータを4文字に変換します。
3バイト = 24ビット
24ビット ÷ 6ビット = 4つの塊
6ビット = 64通り = 1文字1文字あたり6ビットしか表現できないため、8ビットのデータを詰め込むと必ず膨らみます。
4 ÷ 3 = 約1.33 → データ量が約33%増えるこれがBase64の唯一にして最大のデメリットです。 100KBの画像をBase64にすると約133KBになります。
= の意味
元のデータが3バイトの倍数でない場合、末尾を = で埋めて4文字単位に揃えます。
- 余り1バイト →
==が付く - 余り2バイト →
=が付く - 割り切れる → 付かない
= はデータの一部ではなく、桁合わせの印です。Base64文字列の末尾に = があるのはこのためです。
URLセーフBase64
+ と / は、URLの中では特別な意味を持ちます。そのままURLに含めると壊れるため、これらを - と _ に置き換えたURLセーフBase64という変種があります。
JWT（JSON Web Token）はこの形式を使っています。JWTの xxxxx.yyyyy.zzzzz という3つの部分は、それぞれURLセーフBase64です。つまりJWTのペイロードは誰でもデコードして読めます。 ここに秘密情報を入れてはいけません。
Data URI：画像をHTMLに埋め込む
Base64の代表的な用途が Data URI です。画像ファイルを外部ファイルとしてではなく、HTMLやCSSの中に文字列として直接埋め込みます。
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..." />.icon {
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0...");
}Base64 エンコード / デコードツールでは、画像ファイルを読み込んでData URI形式の文字列をそのまま生成できます。テキストのエンコード・デコードにも対応しています。
使うべきケース
Data URIが有効なのは、「小さい」かつ「必ず使う」画像に限られます。
- 1〜2KB程度の小さなアイコン
- CSSの背景に使う数十バイトのSVG
- メール本文（HTMLメール）に埋め込む画像
- 単一のHTMLファイルで完結させたい資料
利点は、HTTPリクエストが1回減ることです。小さな画像を10個読み込むより、埋め込んだほうが速い場合があります。
使うべきでないケース
大きな画像には向きません。 理由は3つあります。
- データ量が33%増える
- ブラウザにキャッシュされない — HTMLに埋め込まれるため、ページを読み込むたびに転送される
- HTMLが肥大化する — 初期表示（LCP）が遅くなる
数十KB以上の画像をData URI化するのは、ほぼ確実に逆効果です。通常の画像ファイルとして配信し、圧縮とキャッシュを効かせるほうが速くなります。 画像の軽量化については画像を軽くする方法で解説しています。
目安として、2KBを超えるならData URIにしない。この基準で判断すれば大きく外しません。
その他の使いどころ
Basic認証
HTTPのBasic認証は、ユーザー名:パスワード をBase64にしてヘッダーに載せます。
Authorization: Basic dXNlcjpwYXNzd29yZA==これは暗号化ではありません。 傍受されれば即座に復号されます。Basic認証がHTTPS必須とされるのはこのためです。HTTP（暗号化なし）でBasic認証を使うのは、パスワードを平文で送っているのとほぼ同じです。
メールの添付ファイル
メールの添付ファイルは、MIMEという仕組みでBase64にエンコードされて送られます。メールの添付が実際のファイルサイズより大きくなるのはこのためです。「10MBまで」という制限に対し、実ファイルが8MBでも超えることがあります。
設定ファイルへの埋め込み
証明書や鍵ファイルを1行の文字列として環境変数に入れる際に使われます。改行を含むファイルを、改行のない形式で扱えるためです。
デコードして中身を確認する
Base64文字列を見かけたら、デコードして中身を確認できます。障害調査では次のような使い方をします。
- APIのレスポンスに含まれるBase64が何のデータか確認する
- JWTのペイロードをデコードして、権限や有効期限を確認する
- 設定ファイルに埋め込まれた値の中身を確認する
Base64ツールはブラウザ内で処理するため、本番の認証情報を含む文字列を貼り付けてもサーバーに送信されません。 オンラインのデコードサービスにトークンを貼り付けるのは、そのトークンを第三者に渡すのと同じです。これは実際に起きている事故です。
まとめ
- Base64は暗号化ではない。 誰でも1秒で元に戻せる
- 目的は「バイナリをテキスト経路で運ぶこと」
- データ量は約33%増える
- Data URIは2KB以下の小さな画像に限る。大きい画像は逆効果
- JWTのペイロードは誰でも読める
- Basic認証はHTTPS必須
- トークンをオンラインのデコードサービスに貼らない
「読めない文字列＝安全」という思い込みが、Base64にまつわる事故の大半の原因です。