🖼️ 画像 → Base64・Data URL 変換
画像をドラッグ＆ドロップで Base64 / Data URL に変換します。CSS の background-image や HTML img タグにそのまま埋め込めます。
画像をドラッグ＆ドロップ、またはクリックして選択
PNG / JPG / WebP / SVG / GIF / AVIF / BMP / ICO
プレビュー
- ファイル名
- MIME
- サイズ
- Base64 size
- 解像度
💡 Data URL の使い方
• 小さなアイコンや 1〜2 KB 程度の画像なら HTTP リクエスト数を減らせます。
• Base64 エンコードはサイズが約 33% 増加します。大きな画像の埋め込みは逆効果になることも。
• SVG はそのままインライン化することも検討してください（さらに小さくなることがあります）。
📖 つまずきやすいポイント
画像を Base64 に変換し、Data URL・CSS の background-image・HTML の img・Markdown の形式で書き出します。処理はブラウザ内で完結し、ファイルは送信されません。Data URL にすると HTTP リクエストは 1 つ減りますが、それが速さにつながるとは限りません — データ量は約 33% 増え、ブラウザのキャッシュも効かなくなるためです。この 2 つを天秤にかけるのが、このツールを使うときの唯一の判断です。
| ケース | 何が起きるか | どうする |
|---|---|---|
| 埋め込んだ結果、かえって遅くなる | data URL にした画像はその画像だけを個別にキャッシュすることができません — 埋め込み先の CSS や HTML と一体になるためです。CSS に埋め込んだ場合はとくに影響が大きく、CSS はレンダリングをブロックするので、画像のバイト数がそのまま初回表示の遅延になります。10KB の画像を 20 個埋め込めば、本来は並列に読み込めた 20 個が、266KB の 1 つの描画ブロック資源に変わります。さらに、画像を 1 つ差し替えただけで CSS 全体のキャッシュが無効になるので、更新のたびに全ユーザーが再ダウンロードします。 | data URL が有利なのは、数 KB までの小さなアイコンだけです。目安として、1〜2KB 程度で、かつ滅多に変わらないもの — チェックマーク、矢印、ローディングのスピナーといった UI の部品が該当します。それ以上のサイズなら、通常の <img> で読み込んでください — キャッシュとレスポンシブ画像 (srcset) の恩恵のほうが、リクエスト 1 つ分より確実に大きくなります。そして前提として、HTTP/2 以降はリクエスト数のコストが大きく下がっています — 「リクエストを減らせば速くなる」という経験則は HTTP/1.1 時代のもので、現在は必ずしも成り立ちません。判断の基準は「その画像を差し替える頻度」と「その CSS を配る回数」を比べることです。 |
| SVG まで Base64 にしてしまう | SVG はテキストなので、Base64 にするのは損です。Base64 は 3 バイトを 4 文字にする符号化なので必ず約 33% 増え、さらに結果がランダムに近い文字列になるため gzip や Brotli がほとんど効きません。元の SVG はマークアップの繰り返しが多く、そのままなら圧縮で 70% 前後小さくなるのに、Base64 にするとその性質が完全に失われます。「最適化してから Base64 にする」という手順を踏むと、削った分がそのまま打ち消されることも珍しくありません。 | SVG を埋め込むなら、Base64 ではなく URL エンコードを使ってください — data:image/svg+xml,%3Csvg... の形式です。エスケープが必須なのは #・%・" の 3 つだけで、残りはほぼそのまま置けるため、Base64 より小さく、しかも圧縮が効いたままになります。さらに良い選択肢として、SVG は data URL にせずインラインで書く方法があります — <svg> を HTML に直接置けば、CSS で色を変えられ、アニメーションもでき、data URL より短くなります。アイコンを複数使うなら、1 つずつ埋め込むより SVG スプライトにまとめてください — リクエスト数と総容量の両方で有利になります。 |
| CSP や配信先で data URL がブロックされる | Content Security Policy で img-src 'self' のように指定していると、data: スキームの画像は拒否され、何も表示されません — コンソールにエラーは出ますが、見た目には「画像が抜けている」だけなので原因に気付きにくいです。同じことが配信先でも起こり、HTML メールでは Gmail が data URL の画像を表示しません — ローカルでプレビューしたときは正しく見えるのに、受信箱では抜けるという形で表面化します。「埋め込んだから確実に表示される」という期待が、いちばん裏切られやすい部分です。 |
CSP を使っているなら img-src 'self' data: のように data: を明示的に許可してください — ただしdefault-src にまとめて入れないことです。data: をスクリプトやスタイルにまで許すと、XSS の攻撃面が広がります — 画像だけに限定して許可するのが正しい粒度です。HTML メールについては、data URL は使わず、絶対 URL で外部の画像を参照してください — どのみち多くのクライアントが既定で外部画像をブロックするので、画像が出ない前提で読める本文を作るほうが重要です。そして、どの経路でも「実際に配信して、実際の環境で開いて確認する」以外に確かめる方法はありません — ローカルのプレビューは、この種の問題を一切教えてくれません。 |
Base64 は難読化ですらありません。CSS の中に埋め込まれた data:image/png;base64,... は、ブラウザの開発者ツールでその場でデコードして表示できます — 社外秘のスクリーンショットや、まだ公開していない図版を「CSS の中だから見えない」と考えて埋め込むのは、単に誤りです。もう 1 点、このツール特有の注意があります — ここではファイルのバイト列をそのまま Base64 にしているので、EXIF がそのまま残ります。Canvas を経由する画像変換ツールとは違い、GPS 座標・撮影日時・カメラの機種が、生成した data URL の中にそっくり含まれます。スマートフォンで撮った写真を data URL にして公開するときは、先に EXIF を落としてください — 画像フォーマット変換 や 画像リサイズ は Canvas を通すので、その過程で EXIF が消えます。「埋め込んだから中身は見えない」という直感は、この 2 点のどちらについても成り立ちません。
📖 使い方
-
1
画像をドロップまたはクリックして選択ドラッグ＆ドロップエリアに画像をドロップするか、クリックしてファイルを選択します。PNG・JPG・WebP・SVG など主要形式に対応しています。
-
2
出力形式を選択Data URL・Base64 のみ・CSS background-image・HTML img タグ・Markdown の中から使用する形式を選択します。
-
3
コピーして使用「コピー」ボタンでエンコード済みテキストをクリップボードに保存し、コードに貼り付けます。
❓ よくある質問
クリップボードからの貼り付けにも対応していますか？
Base64 に変換するとファイルサイズはどうなりますか？
どのような場面で Data URL を使うのが適切ですか？
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。