Base64画像デコーダー
Base64文字列を貼り付けて画像をプレビューしてダウンロードします。
使い方
- 入力エリアにBase64エンコードされた画像文字列を貼り付けます。
data:image/…プレフィックスを含めるか、生のBase64データのみを含めることができます。 - 画像をデコードをクリックしてプレビューします。
- 画像をダウンロードをクリックしてPNGファイルとして保存します。
よくある質問
どのBase64形式がサポートされていますか?
生のBase64文字列(ツールが形式を自動検出)またはdata:image/png;base64,iVBOR…のような完全なデータURIを貼り付けることができます。サポートされている画像タイプ: PNG、JPEG、WebP、GIF、BMP、SVG。
サイズ制限はありますか?
厳密な制限はありませんが、非常に大きなBase64文字列(5〜10 MB以上)はデバイスによって処理に時間がかかる場合があります。
画像をBase64にエンコードするには?
画像からBase64への変換ツールを使用してください · 画像をドラッグ&ドロップするだけでBase64文字列が得られます。
Base64とは実際には何か
Base64はRFC 4648（2006年10月）で定義されたバイナリからテキストへのエンコーディング方式だ。64文字のアルファベット（A-Z、a-z、0-9、さらに+と/）を使って任意のバイトをプリンタブルなASCII文字として表現する。1つのBase64文字が6ビット、1バイトが8ビット、最小公倍数は24なので、バイナリ入力の3バイトはちょうど4文字の出力になる。この4対3の比率が、Base64エンコードされたファイルが元のバイナリより約33%大きくなる理由でもある。
入力長が3の倍数でない場合、Base64は出力が常に4文字の倍数になるよう=でパディングする：末尾バイト1つなら2文字と==、末尾バイト2つなら3文字と=になる。一部のエンコーダーはパディングを削除するため、堅牢なデコーダーはatob()に文字列を渡す前に再パディングする必要がある。
RFC 4648はURL安全なバリアント（base64urlと呼ばれることがある）も定義しており、+を-に、/を_に交換する。JWTはこれを使用する。このデコーダーはどちらのアルファベットも正規化するため、どちらを渡されたか考える必要がない。
データURIスキーム
RFC 2397（1998年8月）はdata: URLスキームを定義している。完全な文法：
data:[<mediatype>][;base64],<data>典型的なインラインPNGはdata:image/png;base64,iVBORw0KGgo…のように見える。;base64トークンはマーカーで（=記号がないことに注意）、ブラウザにペイロードをパーセントエンコードされたテキストとして扱う代わりにBase64からデコードするよう伝える。;base64を省略すると、データはURLエンコードされたテキストとして解釈される。メディアタイプを完全に省略すると、仕様のデフォルトはtext/plain;charset=US-ASCIIになる。
このデコーダーはどちらの形式も受け付ける：完全なデータURIを貼り付けるか、Base64ペイロードだけを貼り付けるかのどちらかだ。ペイロードだけが提供された場合、フォーマットはデコードされた最初のバイトから検出される（後述）。
フォーマットの検出方法
data:image/…プレフィックスのない生のBase64文字列を貼り付けた場合、それがどの種類の画像かを知る唯一の方法は最初の数デコードバイトを見ることだ。すべての一般的な画像フォーマットは認識可能なシグネチャ（正式には「マジックナンバー」と呼ばれる）で始まる。ブラウザはMIMEタイプのスニッフィング時にまったく同じチェックを行う（手順はWHATWGのMIMEスニッフィング標準にある）。便利なことに、これらのシグネチャは予測可能なBase64プレフィックスに変換される：
| フォーマット | 先頭バイト（16進数） | Base64プレフィックス |
|---|---|---|
| PNG | 89 50 4E 47 0D 0A 1A 0A | iVBORw0KGgo |
| JPEG | FF D8 FF | /9j/ |
| GIF89a | 47 49 46 38 39 61 | R0lGODlh |
| WebP | 52 49 46 46 … 57 45 42 50 | UklGR |
| BMP | 42 4D ("BM") | Qk |
| SVG（XMLテキスト） | <?xmlまたは<svgで始まる | PD94bWwg または PHN2Zw |
PNGのシグネチャはフォーマット動物園の中でも巧みなものの1つだ。89バイトは最上位ビットが立っているため7ビットのみのメールリレーが通ると目に見えて破損する。次の3バイトはASCIIでPNGと綴られており、ファイルにheadを実行した人間が認識できる。次にDOS改行コード（0D 0A）、レガシーのTYPEコマンドの出力を止めるMS-DOS Ctrl-Z、そしてUNIX改行（0A）が続く。これらが組み合わさってライン終端を「丁寧に」書き換えるすべての一般的なトランスポートを検出する。
Base64画像はどこから来るか
このようなツールにたどり着くほとんどの人は何かをデバッグしている。よくある状況：
- JSONのAPIレスポンス。JSONにはネイティブのバイナリ型がないため、APIは画像、署名済みPDF、プロフィール写真、アップロードされたスクリーンショットをJSONフィールド内のBase64文字列として送信する。ここに値を貼り付けると実際に何だったかを確認できる。
- CSSとバンドルされたアセット。WebpackとViteには小さなアセットのしきい値（Viteのデフォルトは4 KB）があり、小さな画像をバンドルされたCSSやJSにデータURIとして自動的にインライン化する。「このアイコンはどこから来ているのか？」をデバッグするとき、データURIがここに着地する。
- HTMLメール署名。Gmail、Outlook、Apple Mailは署名画像を転送時に画像が存続するようデータURIとしてインライン化する。デザイナーが元のロゴを取り戻す必要があることがある。
- CMSとNotionのエクスポート。WordPressのXMLエクスポート、Notionエクスポート、Confluenceバックアップはエクスポートを自己完結させるためサムネイルをBase64としてインライン化する。
- QRコードと署名パッド。QRコードを生成するブラウザライブラリ（qrcode.js）や手書き署名をキャプチャするライブラリ（signature_pad）は通常、出力を
data:image/png;base64,…文字列として公開する。 - サーバーサイドのPDF生成。Puppeteer、openhtmltopdf、iTextなどのツールはインラインデータURIを持つHTMLを受け付ける。レンダリングされたPDFにロゴが「表示されない」場合、URIをデコードすることがバイトが画像だったかどうかを確認する最速の方法だ。
画像をBase64としてインライン化すべきか？
このトレードオフはかつてはより興味深かった。HTTP/1.1では画像ごとに別々のブロッキングリクエストが発生し、小さなアイコンをインライン化すると実際のラウンドトリップを削減できた。HTTP/2とHTTP/3ではケースが大幅に縮小した。正直なまとめ：
得られるもの：HTTPリクエストがゼロ、アトミックなデリバリー、外部依存なしで動作する自己完結したアーティファクト（単一ファイルのデモ、メール、サーバーレンダリングされたPDF）。
失うもの：ブラウザはインライン化されたデータURIを別々にキャッシュできないため、10ページに同じ画像があるとすべてのHTMLレスポンスとともに再ダウンロードされる。エンコードされたアセットはバイナリ相当より約33%大きくなる。CDNはページ間に埋め込まれた画像を重複排除できない。画像最適化パイプライン（Cloudinary、Vercel、Next.jsの<Image>）はインライン化されたアセットの検査、圧縮、リサイズ、AVIFやWebPなどの最新フォーマットの提供ができない。ブラウザはBase64を最初にデコードしてから画像をデコードするため、レンダリングのたびに余分なCPUが必要だ。
大まかな経験則：1箇所だけで使用する約4 KB未満の画像、1ピクセルのプレースホルダー、自己完結ファイル内を移動する必要がある画像はインライン化する。複数ページで使用するもの、約4 KB以上のもの、遅延ロードすべきもの、フォーマット交渉の恩恵を受けるものはインライン化しないこと。
セキュリティ：Base64がしないこと
Base64はエンコーディングであって暗号化ではない。RFC 4648 §12は明示的にデータを「視覚的に隠す」が「計算的な機密性は提供しない」と警告しており、誰でも即座にデコードできる。セキュリティ対策と思ってパスワードやAPIキーをBase64エンコードしないこと。
知っておく価値のあるセキュリティの詳細が2つある：
data:URLへのトップレベルナビゲーションは最新ブラウザでブロックされている（新しいタブで開いても機能しない）。データURIから偽のログインページをレンダリングするフィッシング攻撃を軽減するためだ。サブリソースの使用（<img src="data:…">、CSSのurl(data:…)）は引き続き許可されている。- SVGは特別だ。SVGはXMLであり、SVGドキュメントは
<script>要素とイベントハンドラーを含むことができる。<img>タグにSVGを読み込むのは安全だ（ブラウザはスクリプト無効レンダラーを使用する）が、同じSVGを<object>や<iframe>に読み込むと任意のJavaScriptが実行される可能性がある。このデコーダーは常に<img src>のみを設定するため、これが安全なパスだ。信頼できないソースからSVGをデコードした場合は、他の信頼できないドキュメントと同様に扱うこと。
その他の質問
Base64文字列が「InvalidCharacterError」で失敗するのはなぜか？
よくある原因が3つある：コピーペーストからの余分な空白や改行（古いMIME Base64プロファイルは76文字で行を折り返すが、JavaScriptのatob()はそれを拒否する）；-と_が+と/の代わりに使われているURL安全なBase64；または長さが4の倍数でなくなるように末尾の=パディングが削除されている場合。このデコーダーは空白をクリーンアップし、アルファベットを正規化し、デコード前に再パディングするが、非常に破損した文字列は依然として失敗する。
デコード時に品質は失われるか？
いいえ。デコードはエンコードの正確な逆演算であり、元の画像をバイト単位で取り戻せる。ダウンロードはBase64内にあったフォーマット（PNG、JPEG、WebP、GIF、BMP、またはSVG）で、再エンコードのステップはない。
ブラウザが受け付ける最大のデータURIとは？
MDNによると、現在の制限はChromiumとFirefoxで約512 MB、Safari/WebKitで約2 GBだ。実際のボトルネックはURLの仕様よりもメモリとCPUであり、一般的なノートパソコンでは約10 MBを超えると貼り付けが重くなり始める。
何かサーバーに送信されるか？
いいえ。デコードはネイティブのatob()関数とBlobまたはデータURIを<img>タグに割り当てることによってすべてブラウザ内で行われる。何もアップロードされない。ページは読み込まれた後オフラインで動作する。
すべてのJPEGのBase64が/9j/で始まるのはなぜか？
実際にはほぼすべてのJPEGファイルはFF D8 FF（Start-Of-Imageマーカーとその後に続くマーカーバイト）で始まる。すべてFFで中間にD8がある3バイトをBase64エンコードすると、ビットパターン11111111 11011000 11111111は6ビットグループ111111 111101 100011 111111に分割される：Base64アルファベット位置63、61、35、63で、これは/9j/と綴られる。4文字目はその後に続くマーカー（JFIFならE0、ExifならE1）によって変わるが、最初の3文字は普遍的だ。