これが「Base64データURI（Data URI scheme / Data URL）」と呼ばれる仕組みです。
通常、Webページに画像を表示させるには外部画像ファイルのURL（https://example.com/image.png）を指定しますが、データURIを使うと画像データそのものをHTMLやCSSの中に直接文字列として埋め込むことができます。
この記事では、Base64データURIの基礎知識から構文ルール、バイナリをBase64化する理由、HTTPリクエスト削減のメリット、ファイル容量が約1.33倍に膨らむデメリット、そしてHTMLメール配信での注意点まで、分かりやすく整理して解説します。
図：Base64データURIの構文解剖と外部参照URLとの比較
Base64データURI（Data URL）の基本概要
通常、WebブラウザがWebページを表示する際、まずHTMLファイルをサーバーから取得し、その中に書かれている画像タグ（<img src="logo.png">）を見つけると、改めてサーバーに対して「logo.png をください」という別の通信（HTTPリクエスト）を送って画像を受け取ります。
これに対して、「データURIスキーム（Data URI Scheme / RFC 2397）」は、サーバーへ別個の通信を行わず、URLを記述する場所にデータ本体を直接インラインで記述してしまおうという規格です。
画像や音声、フォントなどのバイナリファイルはそのままではテキストファイル（HTMLやCSS）に記述できないため、「Base64（ベース64）」という変換方式を用いてASCII文字列に変換した上で埋め込みます。この形式が一般に「Base64データURI（Base64 Data URL）」と呼ばれています。
データURIスキームの基本構文と解剖
データURIは、RFC 2397によって以下のような構文ルールが定められています。
data:[<mediatype>][;base64],<data>この構文は、主に4つの要素から構成されています。
| 構成要素 | 記述例 | 役割と説明 |
|---|---|---|
| スキーム名 | data: |
ブラウザに対して「これは外部サーバーのURLではなく、データそのものである」ことを宣言する接頭辞です。 |
| MIMEタイプ (mediatype) | image/pngimage/jpegimage/svg+xml |
埋め込まれているデータの形式を指定します。省略した場合は「text/plain;charset=US-ASCII」とみなされます。 |
| 符号化方式 (base64) | ;base64 |
データがBase64方式でエンコードされていることを示します。テキストデータ等でURLエンコード（パーセントエンコーディング）を用いる場合は省略されます。 |
| データ本体 | iVBORw0KGgo... |
カンマ（,）の後に続く、エンコードされた実際のデータ文字列です。 |
HTMLとCSSでの具体的な記述例
HTMLのimgタグで使用する場合：
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="赤色の点">CSSの背景画像（background-image）で使用する場合：
.custom-icon {
width: 16px;
height: 16px;
background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path fill='%230284c7' d='M12 2L2 22h20L12 2z'/></svg>");
background-repeat: no-repeat;
}なぜバイナリデータをBase64に変換するのか
コンピュータ上のファイルは、大きく分けて「テキストファイル」と「バイナリファイル」の2種類に分かれます。
画像（PNG、JPEG、GIF）や音声、PDFなどはバイナリファイルであり、0から255までのバイト値（あらゆるビット列）を含んでいます。
しかし、HTML、CSS、JSON、XMLなどのWeb標準フォーマットは、人間が読める文字列（ASCIIやUTF-8などのテキスト文字）を前提として設計されています。
もしバイナリデータをそのままHTMLの中に貼り付けてしまうと、改行文字（CRLF）、NULL文字（ ）、HTMLタグの開始記号（< や >）、クォーテーション（” や ‘）などと誤認識され、ファイル全体が破損して構文エラーになってしまいます。
そこで考案されたのが「Base64」です。
Base64は、任意のバイナリデータを英大文字（A-Z: 26文字）、英小文字（a-z: 26文字）、数字（0-9: 10文字）、記号「+」「/」（2文字）の合計64種類の安全な印字可能文字だけで表現し直すエンコードアルゴリズムです。末尾のパディング（余り調整）には「=」が使われます。
これにより、どのようなバイナリデータであっても、HTMLやCSSの文法を壊すことなく安全にテキストとして埋め込むことが可能になります。
Base64データURIを活用する主なメリット
| メリット | 詳細 |
|---|---|
| HTTPリクエストの削減 | 画像を読み込むためのサーバー往復通信（TCPハンドシェイク、TLSネゴシエーション、HTTPリクエスト/レスポンス）が不要になり、ページ全体の通信回数を抑えられます。 |
| 単一ファイルでの自己完結（ポータビリティ） | HTMLファイル1枚の中に画像データが内包されているため、「画像ファイルのリンク切れ」が起きません。オフライン環境での閲覧や、単体HTMLファイルをメール添付・配布する際に非常に便利です。 |
| 画像の即時レンダリング | HTMLが解析（パース）された瞬間に画像データが手元にあるため、外部画像の読み込み完了を待つ間に発生する「画面のガタつき（レイアウトシフト / CLS）」を防ぐことができます。 |
実務で直面するデメリットと注意点
一見すると「すべての画像をデータURIにすれば高速化するのでは？」と思われがちですが、データURIには無視できない明確なデメリットが存在します。
データ容量が約1.33倍（33%増）に肥大化する
Base64は、バイナリデータの「3バイト（24ビット）」を、6ビットずつ4つの文字に分割して表現します。
そのため、エンコード後のデータ容量は元のバイナリサイズに対して「4/3（約1.33倍）」、つまり約33%増加します。
容量肥大化の具体例：
- 元の画像サイズ：300 KB
- Base64エンコード後：約 400 KB（約100 KB増加）
- 元の画像サイズ：3 MB（一眼レフ等の写真）
- Base64エンコード後：約 4 MB（約1 MB増加）
ブラウザキャッシュが効かない
外部URL形式（<img src="logo.png">）の場合、ブラウザは一度ダウンロードした画像をローカルキャッシュに保存します。ユーザーがサイト内の別ページに移動しても、画像は通信なしで一瞬で表示されます。
しかし、HTMLやCSSの中にBase64データURIとして埋め込まれた画像は、HTMLのテキストそのものです。
ページを遷移したりHTMLを再取得するたびに、巨大な画像文字列も毎回ダウンロードし直すことになり、転送量と通信時間が無駄に浪費されてしまいます。
HTMLのパース遅延とソースコードの視認性悪化
HTMLファイル内に数万〜数十万文字のBase64文字列が存在すると、ブラウザがHTML構造を解析（DOM構築）する際にCPU負荷が高まり、最初の画面描画（First Contentful Paint）が遅延する原因になります。
また、開発ツールのソースコード表示やデバッグが極端に見づらくなるという運用上の問題もあります。
メール配信（HTMLメール）でBase64画像が非推奨とされる理由
Webブラウザでは問題なく表示できるBase64データURIですが、メルマガなどのHTMLメール配信においては「原則使用禁止」に近い扱いになっています。
| メールソフト / サービス | Base64画像の対応状況 | 理由と挙動 |
|---|---|---|
| Gmail（Web / アプリ） | × 非表示 / ブロック | Googleの画像プロキシサーバーがデータURIを安全でないと判断し、画像が消えるか壊滅的な崩れが発生します。 |
| Outlook（デスクトップ） | × 完全非対応 | Wordレンダリングエンジンを使用しているため、データURIの解釈自体をサポートしていません。 |
| Apple Mail / iOS Mail | ○ 表示可能 | WebKitベースのため表示は可能ですが、受信者のメーラー環境を選んでしまいます。 |
たとえば、GoogleドキュメントからエクスポートしたHTMLには画像がBase64形式で出力されますが、これをそのままGmailApp等で一括送信すると、多くの受信者の手元で画像が「真っ白」になってしまいます。
そのため、HTMLメールで画像を確実に表示させたい場合は、Base64画像をそのまま送るのではなく、「CID（Content-ID）参照形式のインライン画像（MIME添付）」に変換して送信するのが標準的な設計です。
※GoogleドキュメントのBase64画像をCID形式に自動変換して送信する具体的なGAS実装については、当ブログの連載記事 第2回：GoogleドキュメントのHTMLメール変換とインライン画像埋め込み で詳しく解説しています。
Web開発での代表的な活用事例と使い分けの基準
メリットとデメリットを踏まえると、Base64データURIを実務で使うべきケースと、避けるべきケースが明確に見えてきます。
○ データURIの利用が適しているシーン
- 数KB未満の極小アイコン：矢印や閉じるボタンなど、1KB〜3KB未満の軽量アイコン。別ファイルとしてHTTPリクエストを飛ばすよりもインライン化した方が高速。
- JavaScriptのFileReader APIによるプレビュー：ユーザーがファイル選択（<input type=”file”>）した画像を、サーバーにアップロードする前にブラウザ上で即座にプレビュー表示する場合（
readAsDataURL）。 - Canvas要素の画像化：ブラウザのHTML5 Canvasで描画したグラフやイラストをPNG画像として取得・保存する場合（
canvas.toDataURL()）。 - CSSスプライトの代替やローディングスピナー：初期表示時に絶対に必要な極小GIF/SVG画像。
× データURIの利用を避けるべきシーン
- 数十KB以上の写真やバナー画像：容量が33%膨らみ、HTMLのパースをブロックするため、WebPやJPEGとして通常配信すべきです。
- サイト全体で共通して使われるロゴや共通パーツ：外部ファイル化してブラウザキャッシュを効かせるべきです。
- HTMLメールの本文画像：主要なメールクライアントでブロックされるため、CID形式または外部ホスティングURLを使用すべきです。
まとめ：適切なシーンを見極めたデータURIの活用
記事の要点まとめ
- Base64データURIは、画像などのバイナリデータを英数字文字列に変換し、HTML/CSS内に直接埋め込む技術規格。
- HTTPリクエストを削減でき、単一ファイルで自己完結する強力なメリットがある。
- 一方で、データ容量が約1.33倍（33%増）に肥大化し、ブラウザキャッシュが効かないという明確なトレードオフがある。
- HTMLメールではGmailやOutlookで表示ブロックされるリスクが高いため、CIDインライン画像（MIME添付）を採用する。
- 数KB未満の極小アイコンや、JavaScriptでのローカルプレビュー（FileReader / Canvas）など、特性に合った限定的な用途で活用するのがベストプラクティス。
データURIは、Webの通信オーバーヘッドを削減するための便利な道具ですが、何でも埋め込めば良いというわけではありません。
「ファイルサイズ」「キャッシュの重要性」「対象となる表示環境（ブラウザかメールか）」を総合的に見極め、通常の外部URL参照と適切に使い分けることが、軽快で安定したWebシステムを構築するためのポイントです。
