Base64 のサイズ増加：正確な計算式

計算式

n バイトの入力に対して、パディング付きの Base64（RFC 4648 のデフォルト）の長さは正確に次のとおりです。

length = 4 × ceil(n / 3)

JWT 用の Base64URL のようにパディングがない場合は次のとおりです。

length = ceil(4n / 3)

両者の差は = の数で、n mod 3 に応じて 0、1、2 のいずれかになります。その由来は パディングの解説 で説明しています。

逆に、長さ L のパディング付き Base64 文字列をデコードしたサイズは次のとおりです。

bytes = 3 × L / 4 − (number of trailing "=")

つまり TWFu は 3 バイト、TWE= は 2 バイト、TQ== は 1 バイトです。数える前に空白と改行を取り除いてください。Base64 サイズ計算ツール は、改行や Data URI の接頭辞も含めて両方向の計算を行います。

コードでは次のようになります。

import base64, math, os
for n in [1, 2, 3, 100, 1000]:
    data = os.urandom(n)
    assert len(base64.b64encode(data)) == 4 * math.ceil(n / 3)

const b64Len = (n) => 4 * Math.ceil(n / 3);
const rawLen = (s) => (s.length * 3) / 4 - (s.endsWith("==") ? 2 : s.endsWith("=") ? 1 : 0);
b64Len(1000);    // 1336
rawLen("TWE=");  // 2

33% 増える理由

1 バイトは 8 ビットです。Base64 の 1 文字は 64 = 2⁶ 種類の記号の 1 つなので 6 ビットのデータを運びますが、保存されるのは 8 ビットの ASCII バイトとしてです。そのため、出力の 1 バイトには有効なビットが 6 つしかなく、出力は入力の 8/6 = 4/3 になります。これは 33.3% の増加で、越えられない下限です。アルファベットを捨てない限り、どの Base64 実装もこれより良くはなりません（ビットの組み替え方は Base64 の仕組み で順を追って示しています）。

小さな入力では、出力が常に 4 文字単位のブロックになるため、パディングによって比率が悪化します。1 バイトは 4 文字になり、300% の増加です。数百バイトにもなればパディングは無視できるほどになり、比率は 4/3 に落ち着きます。

より密なテキストエンコード方式もあります。Base85 は 4 バイトを 5 文字に収め（25% の増加）、Base91 はそれよりわずかに低くなります。ただし対応している環境は限られ、アルファベットには場面によって問題を起こす文字が含まれます。比較は Base64 と 16進数・Base32・Base58・Base85 の比較 にあります。

改行：MIME、PEM、コマンドラインツール

Base64 を行に折り返す形式もあり、行末の文字もサイズに含まれます。

MIME の数値は 4/3 × 78/76 から来ています。Base64 の 76 文字ごとに、CRLF の 2 バイトが加わるからです。L = 4 × ceil(n / 3) とすると、最後の行も含めて各行の後に CRLF を付けたサイズは次のとおりです。

mime_length = L + 2 × ceil(L / 76)

76 文字の完全な行にはちょうど 57 バイトの入力が入るので、MIME エンコーダーはデータを 57 バイト単位で処理します。メールについて詳しくは メールと Base64 をご覧ください。MIME Base64 エンコーダー は折り返された出力を生成します。

サイズ早見表

上の計算式で求め、Python の base64 モジュールで確認しました。

最後の行がメールのケースです。SMTP のサイズ制限（SIZE 拡張、RFC 1870）はエンコードを含めた送信時のメッセージを数えるので、25 MB のファイルは送信時に約 34.2 MB になり、25 MB のサーバー制限を通りません。添付ファイルのサイズで制限を説明しているプロバイダーもあるので、お使いのサービスがどう数えているか確認してください。

圧縮の効果

圧縮と Base64 の関係には 2 つの側面があり、順序が重要です。

両端を自分で制御できるなら、エンコードの前に圧縮します。 圧縮したデータの Base64 は、より小さな数値の 4/3 です。GPL-3 のライセンス文（35,149 バイト）を、Node.js の zlib で gzip レベル 9 を使って測定しました。

Gzip + Base64 ツールは、「gzip の後に Base64」の処理をブラウザで行います。

バイナリデータなら、転送時の圧縮で増加分の大半を取り戻せます。 gzip や Brotli で圧縮された HTTP レスポンスの中で Base64 文字列を送ると、圧縮器は 6 ビット分の情報しかない各文字を 6 ビット近くまで詰め直します。1 MiB のランダムなバイト列は、Base64 で 1,398,104 文字に増えましたが、gzip すると 1,053,023 バイト（元のデータより 0.4% 大きいだけ）になり、Brotli では 1,048,805 バイトになりました。同じデータに MIME の改行を入れたものは gzip で 1,088,689 バイトになったので、圧縮後でも CRLF の分だけ約 3.4% 余計にかかります。

テキストは事情が異なります。Base64 は圧縮器が頼りにする繰り返しを崩してしまうため、Base64 にしたテキストは元のテキストよりずっと圧縮されにくくなります。上の表では 12,091 バイトに対して 17,465 バイトでした。Data URI のパフォーマンス の記事には、PNG、JPEG、WOFF2、SVG での測定結果があります。

URL、ヘッダー、Cookie の制限

Base64 は URL、ヘッダー、Cookie に入れるものすべてを膨らませますが、この 3 つにはどれも制限があります。

• URL。 RFC 9110 は、送信側と受信側が少なくとも 8,000 オクテットの URI に対応することを推奨しています。多くのサーバーはデフォルトでそのあたりが上限です。nginx はリクエスト行用に 8 KB のヘッダーバッファーを割り当て、Apache の LimitRequestLine はデフォルトで 8,190 バイトです。それより長い URL は、たいてい 414 URI Too Long で失敗します。Base64URL なら、URL のほかの部分を除いて約 6,000 バイトのデータが入る計算です。
• ヘッダー。 同じサーバーバッファーが各ヘッダー行にも適用されます。Authorization: Bearer ... ヘッダーの長い JWT や、大きな Basic 認証の資格情報で問題になります。
• Cookie。 RFC 6265 は、ブラウザが名前と属性を含めて Cookie 1 つあたり少なくとも 4,096 バイトに対応することを求めています。Base64 でエンコードすると、データとしては約 3 KB です。

Base64 のペイロードがこれらの制限に近づいているなら、リクエストボディで送るか、サーバー側に保存して ID を渡すようにしてください。

よくある質問