画像からBase64への変換

使い方

1. 画像をドロップまたは選択する。ブラウザはFileReader APIを使ってファイルをローカルで読み込む。どこにもアップロードされない。
2. エンコーダーがバイトを変換する。標準Base64アルファベットを使って、入力の3バイトごとにA-Z a-z 0-9 + /から取得した4つのASCII文字になる。入力長が3の倍数でない場合、最後に最大2つの=パディング文字が付く。
3. 必要なものをコピーする。「Base64をコピー」はエンコード済み文字列だけを返す（JSONペイロードやバックエンド処理に便利）。「Data URIをコピー」はdata:image/png;base64,…形式の完全な文字列を返し、<img src>属性やCSSのbackground-image: url(…)にそのまま使える。
4. 適切な場所に貼り付ける。出力はプレーンテキストで、HTML・CSS・JSON・JavaScript・Markdownなど文字列が使える場所ならどこでも動作する。

Base64が実際に行うこと

Base64はRFC 4648（2006年10月）で定義されている。エンコードは24ビット（3バイト）の入力を一度に取り、64文字のアルファベットへの4つの6ビットインデックスとして書き直す。計算はちょうど合う：3バイト（24ビット） → 4文字（それぞれ6ビット）。入力長が3の倍数でない場合、エンコーダーは出力長が4の倍数になるよう=パディング文字を追加する。

実際上の2つの影響：

• 出力は常に入力より約33%大きくなる。4/3の比率はアルゴリズムの根本だ。100KBの画像は約133KBのBase64になる。MIME形式の76文字改行があると、オーバーヘッドは約37%に近づく。
• 出力はあらゆる場所でテキスト安全だ。64文字のアルファベットは全ての一般的なASCIIテキストチャンネルの共通集合だ。HTML・JSON・XML・メール・URL（URLセーフ変種を使用）・ソースコード。これがBase64が存在する理由そのものだ：テキスト用に設計されたシステムを通じてバイナリデータを転送するためだ。

RFC 4648 §12はひとつの重要な非機能を明記する：「Base64エンコードは、パスワードのような容易に認識できる情報を視覚的に隠すが、計算上の機密性は一切提供しない」。どの言語でも2行のコードでBase64文字列をデコードできる。これはエンコードであり暗号化ではない。

data URI：インライン画像形式

「data URI」はBase64文字列が画像URLの代わりに使えるラッパー形式だ。RFC 2397（1998年）が構文を定義している：

data:[<mediatype>][;base64],<data>

画像の場合、data:image/png;base64,iVBORw0KGgo…を<img src>属性に書くか、CSSにbackground-image: url("data:image/svg+xml;utf8,<svg…>")を書く。;base64トークンはブラウザにデータ部分がエンコードされていることを示す。このトークンがなければデータはパーセントエンコードされたテキストとして扱われる。RFC 2397自体も「短い値にのみ有用だ」と記しており、これはやがてパフォーマンス上の鉄則となった。

画像をBase64でインライン化すべき場合

• 単一ファイル成果物。転送でも生き残る必要があるロゴが埋め込まれたメール署名。CodePen・JSFiddle・バグ再現用の自己完結型HTMLデモ。ファイルがオフラインで動作するために画像を埋め込む必要がある生成済みPDF。
• ごく小さなクリティカルパスアイコン。クリティカルCSSにインライン化した200バイトのシェブロンやローディングスピナーは、特に遅い接続では別途HTTPリクエストを発生させるより速く読み込める場合がある。
• インラインJSON / APIレスポンス。アバターアップロード・署名・OCRサンプル・生成済みQRコードなど、APIコンシューマーが別途フェッチするURLではなくバイトをインラインで期待する場合。
• サンドボックス化されたiframeや外部リソースの読み込みを禁止する他のコンテキスト。
• 設定ファイルで、JSON・TOML・YAMLの隣に兄弟画像ファイルを置きたくない場合。

画像をBase64でインライン化すべきでない場合

ほとんどの本番ウェブサイトでは、インライン化したBase64画像は通常の<img>参照より遅い。複合的な5つの理由：

1. 33%のサイズオーバーヘッドは常に発生する。エンコード後はすべてのバイトが4/3バイトになる。gzipを適用すると見かけのオーバーヘッドは縮小するが（Base64は反復的なため）、ブラウザがパースするバイトは元のサイズより33%大きい。
2. 画像を別々にキャッシュできない。外部のimage.pngは一度フェッチされ、それにリンクする全ページで再利用される。Base64画像はHTMLやCSSの中にあり、そのファイルへの変更のたびに再ダウンロードされる。
3. HTMLとCSSのパースが遅くなる。レンダーブロッキングCSSの中の長いインライン文字列はクリティカルパスをさらに押し延ばす。Harry Roberts（CSS Wizardry）は実際のクライアントスタイルシートでBase64画像ありで925KB・なしで708KBを測定した。gzip後はそれぞれ232KB対68KB。Base64を削除するとgzip済みCSSが70.68%削減された。
4. 遅延ロードできない。loading="lazy"属性はユーザーがスクロールして近づくまで画像のフェッチを延期する。Base64画像はすでにドキュメント内にあり、延期するものがない。
5. HTTP/2とHTTP/3はすでに「リクエスト過多」問題を解決している。多重化により単一の接続で数百のファイルを並列に配信できるため、インライン化の元々の理由はほぼなくなっている。

GoogleのPageSpeedや多くのパフォーマンス研究者からの実用的な目安：エンコード後に約1〜2KB未満で、クリティカルCSSのファーストビューに表示される場合のみインライン化する。それより大きいものは別ファイルの方がほぼ確実に高パフォーマンスだ。

SVG：Base64ではなくUTF-8エンコードを使う

SVGはすでにテキストなので、Base64にエンコードすると何のメリットもなく約33%バイト数が増える。より小さい形式はURLエンコードされたUTF-8だ：

/* Base64 SVG (longer) */
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");

/* URL-encoded SVG (shorter, also human-readable) */
background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' …>");

ほとんどの現代的なビルドツール（PostCSSのpostcss-inline-svg・Webpackのsvg-url-loader）はデフォルトでURLエンコード形式を出力する。インラインSVGには特定のコンシューマーが;base64を要求しない限り、Base64よりそちらの形式を優先する。

このツールが認識するMIMEタイプ

data URIのメディアタイププレフィックスが、コンシューマーにバイトの解釈方法を伝える。ブラウザが選択したファイルから検出する：

プライバシーとセキュリティの注意事項

ほとんどのオンライン「画像をBase64に変換」サイトはファイルをサーバーにアップロードしてそこでエンコードし、結果を返す。つまりリリース前UIのスクリーンショット・NDA対象のデザイン・子どもの写真・医療スキャン・署名済み契約書がサードパーティのインフラを通過することになる。このツールはローカルでエンコードする。ブラウザのFileReaderがファイルをメモリに読み込み、エンコーダーはデバイス上のJavaScriptで動作し、ページを離れるのはコピーした際のエンコード済み文字列だけだ。

本番でBase64画像を使う場合に知っておくべきContent Security Policyの2つの注意事項：

• インライン化したBase64画像は、明示的に許可しない限りimg-srcルールをバイパスする。img-src 'self'のような厳格なCSPはdata: URIをブロックする。これを許可するにはimg-src 'self' data:と書く。
• CSSインライン化された背景画像も同様だ。CSPがインライン化した背景をブロックしている場合は、まずimg-srcディレクティブを確認する。

よくある間違い

1. Base64を難読化として扱う。違う。誰でもどの言語の2行でもデコードできる。「隠すため」と言ってBase64文字列に認証情報・APIキー・機密データを入れてはいけない。
2. 200KBのヒーロー画像をインライン化する。画像はエンコード後266KBになり、HTMLの中に閉じ込められ、別々にキャッシュできず、遅延ロードもできず、ページのファーストペイントが目に見えて遅くなる。通常のファイルとして提供する。
3. data URIが必要なときに生のBase64をコピーする。<img src>属性の生のBase64文字列は壊れた表示になる。data:image/png;base64,プレフィックスが必要だ。「Data URIをコピー」ボタンを使う。
4. SVGをBase64エンコードする。SVGはすでにテキストだ。代わりにURLエンコードして33%のオーバーヘッドを省く。
5. CSPを忘れる。厳格なimg-src 'self'はdata URIをブロックする。Base64画像を使う場合はディレクティブにdata:を追加する。
6. 先頭のdata:プレフィックスを含んだBase64文字列をデコードしようとする。data:image/...;base64,部分はメタデータだ。Base64デコーダーに文字列を渡す前にそれを取り除く。
7. 機密画像をサーバーサイドエンコーダーに貼り付ける。URLに「エンコード」と書いてあってもネットワークタブにPOSTが表示されたら、あなたの画像はマシンを離れている。

よくある質問

「Base64」と「Data URI」の違いは何ですか？

Base64はエンコード（iVBORw0KGgo…のような文字列）だ。data URIはBase64文字列を画像URLの代わりに使えるものに変えるラッパー（data:image/png;base64,iVBORw0KGgo…）だ。ラッパーはブラウザにメディアタイプとエンコードを伝え、バイトの解釈方法を知らせる。このツールの2つのボタンでそれぞれの形式を別々に取得できる。

Base64は安全ですか？

いいえ。それがBase64の目的でもない。Base64はエンコードであり暗号化ではない。RFC 4648 §12は直接的に述べる：「計算上の機密性は一切提供しない」。誰でもBase64文字列を即座にデコードできる。プライバシーが必要なら、まずデータを暗号化し（AESなど）、その後暗号文をBase64で転送する。

画像はどのくらいの大きさまで対応しますか？

このツールが課す上限はない。エンコードはブラウザのメモリ内で行われるからだ。実用上の上限はデバイスが保持できる容量で、通常は現代のラップトップで数十MBが問題ない。より大きな制約はコンシューマー側のサポートだ：多くのメールクライアント・ブラウザ・APIには独自のdata URIサイズ制限があり、数KB以上をインライン化することはパフォーマンス上ほとんど意味がない。

Base64文字列がファイルより33%大きくなるのはなぜですか？

各Base64文字は6ビットを運ぶが、各入力バイトは8ビットを運ぶからだ。Base64が余りなく表現できる最小単位は3バイト（24ビット = 4つの6ビット文字）なので、出力比率はちょうど4/3 ≈ 1.33になる。これを回避するBase64の変種はない。数学的にエンコードに組み込まれているからだ。

エンコードされた画像はHTMLメールで動作しますか？

ほとんど動作するが、常にではない。Apple Mail・最新のGmail・ほとんどのウェブメールクライアントはdata:画像を問題なく表示する。Microsoft Outlookデスクトップは歴史的にサポートが一貫していなかった。data URIを問題なく表示するバージョンもあれば、完全に削除するバージョンもある。トランザクションメールでBase64画像に依存する前に、対象クライアントリストでテストする。広い互換性のためには、ホストされた画像URLの方が依然として安全な選択だ。

代わりに-や_を使うbase64urlを使うべきですか？

URLやファイル名にエンコードされたデータを置く場合で、+や/がそのままパーセントエンコードが必要になる場合のみ。HTMLの<img src>属性やCSSのbackground-image値には標準アルファベットが使える。RFC 4648 §5はそれらのURL/ファイル名のケース向けにURLセーフ変種を明示的に定義し、標準アルファベットとの混同を避けるため単に「base64」とだけ呼ぶべきではないと警告している。

関連ツール