Base64のサイズ増加（約33%）

Base64エンコード後の出力は常に入力より大きくなります。オーバーヘッドは約33%であり、その正確な理由と対策について解説します。

計算式：

Base64は3バイトの入力を4文字の出力に変換します。各入力バイトは8ビットで、各Base64文字は6ビットを表します：

• 3バイトの入力 = 24ビット
• 24ビット / 1文字あたり6ビット = 4つのBase64文字
• 4文字の出力 / 3バイトの入力 = 1.333...倍

つまり、エンコード出力は入力の4/3（約1.333）倍のサイズ、33.33%の増加です。

パディングを含む場合： 入力長が3の倍数でない場合、パディングにより1-2文字が追加されます。パディングを含む正確なエンコード長の公式は：

encodedLength = 4 * ceil(inputLength / 3)

行折り返し（MIME）を含む場合： MIME形式のBase64は76文字ごとにCRLF（2バイト）を追加するため、オーバーヘッドはさらに増えて約36-37%になります。

実際の影響：

元のサイズ	Base64サイズ	オーバーヘッド
1 KB	1.33 KB	+0.33 KB
100 KB	133 KB	+33 KB
1 MB	1.33 MB	+0.33 MB
10 MB	13.3 MB	+3.3 MB

小さなアセット（アイコン、サムネイル）では、オーバーヘッドは無視でき、HTTPリクエスト削減で相殺されることが多いです。大きなファイルではオーバーヘッドが問題になります：10MBの動画は13.3MBになり、帯域幅コストと転送時間が増加します。

オーバーヘッドの軽減策：

1. エンコード前の圧縮： Base64エンコード前にデータをgzipまたはBrotliで圧縮する。圧縮してからエンコードした結果は、生データのBase64よりもはるかに小さくなることが多いです。

2. エンコード後の圧縮： Base64データがHTTP経由で配信される場合、サーバーのgzip/Brotli圧縮が部分的に補償します。Base64テキストにはパターンがあり効果的に圧縮されるため、実効オーバーヘッドは通常5-10%に低減されます。

3. バイナリプロトコルの使用： サイズが重要な場合は、Base64を必要とするテキストベースのフォーマットの代わりに、バイナリデータをネイティブにサポートするプロトコル（Protocol Buffers、MessagePack、WebSocketバイナリフレーム）を使用する。

4. 閾値ベースのインライン化： サイズ閾値（通常4-10KB）以下のアセットのみをBase64エンコードする。大きなアセットは適切なキャッシュで個別ファイルのままにする。

よくある間違い： トランスポート圧縮を考慮せずにBase64ファイルサイズを比較すること。Brotli配信されたHTMLファイル内の100KBの画像のBase64は、画像を個別に配信する場合とほぼ同じバイト数で転送される可能性があります。