Base64サイズ計算ツール｜エンコード後容量確認

Base64は3バイトのデータを4文字のASCII文字に変換します。この変換比率（3:4）が固定のため、元データのサイズにかかわらず常に約33.3%のオーバーヘッドが発生します。例えば100バイトのPNG画像をBase64にエンコードすると約133文字になります。さらにHTMLやCSS内に埋め込むと、ブラウザがダウンロードするファイル全体のサイズも増加することに注意してください。

Data URIでBase64画像をHTMLやCSSに直接埋め込むと、別途HTTPリクエストが発生しないため小さなリソースでは高速化につながります。しかし埋め込むリソースはHTMLとともにキャッシュされるため、画像だけを更新することができません。また埋め込みファイルが大きいほどHTMLのダウンロード完了が遅くなるため、一般的には4〜5KB以下のアイコンやSVGに限定するのが現実的です。

Base64にエンコードしたデータをHTTP経由で送信する場合、GZip/Brotli圧縮がかかることで実際の転送サイズは理論値より小さくなります。Base64のテキストデータは圧縮率が高いため、圧縮後は元のバイナリとほぼ同等サイズになるケースもあります。ただしブラウザが解析・デコードするCPUコストは変わらないため、大きなファイルはBase64を避けるべきです。

Data URIとして画像をCSSに埋め込む場合、デコード後サイズが5KB以下を目安にしてください。5KB以下ならHTTPリクエスト削減のメリットがサイズ増加のデメリットを上回ります。このツールで「デコード後サイズ」を確認し、5KBを超えるデータは通常のファイル参照に切り替えることを推奨します。

Base64エンコード前に元のファイルサイズを圧縮することが最も効果的です。PNG画像はpngquantやTinyPNGで圧縮してからBase64にエンコードし直すと、同じ見た目で大幅にサイズを削減できます。SVGはBase64を使わず、URLエンコード（%エンコーディング）したSVGをdata:image/svg+xmlとして埋め込む方がサイズを小さくできます。

REST APIやGraphQLでBase64エンコードした画像データを送受信する際は、リクエストとレスポンスのボディサイズが元のファイルサイズより約33%大きくなることを前提に設計してください。タイムアウト設定やリクエストボディの最大サイズ制限（multipart/form-dataを使えばバイナリのまま送れるため推奨）も見直しましょう。