PC・モバイルのトラブル
なぜBase64にするとファイルが大きくなるのか
Base64はバイナリをだいたい3分の1ほど大きくします。3バイトが4文字になる構造、パディング、Data URLのオーバーヘッド、その増加が見合うときを確認します。
Base64はバイナリ3バイトを印字可能なBase64文字4つで表すため、バイナリデータはだいたい3分の1ほど大きくなります。
入力長が3の倍数でないとき、標準のパディング付きBase64は = を付けることがあります。エンコード後の長さは 4 × ceil(n / 3) で、n は元のバイト数です。
「約33%」は大きな入力の話です。ごく短い入力はパディングで比率が大きく見えます。Base64は圧縮ではありません。エンコードと暗号化の違いは [Base64は暗号化ではない：実際に何をするのか](/ja/story/base64-is-not-encryption) を見てください。
この記事は、Base64の出力が元のバイトより大きくなる理由を説明します。セキュリティ案内ではありません。エンコードと暗号化の違いが必要なら Base64は暗号化ではない：実際に何をするのか を使ってください。
なぜBase64は場所を余分に取るのか
3バイトは24ビットです。Base64はその24ビットを6ビットずつ4グループに分けます。各グループがBase64文字1つになるので、入力3バイトは出力4文字になります。ASCII文字1つを1バイトで格納すると 4 / 3 ≈ 1.333、約33.3%の増加です。
- 3バイト（24ビット）
- 6ビットのグループ4つに分割
- 各グループ → Base64文字1つ
- 4文字（テキストとして多くの場合4バイト）
確認できる簡単な例
次のエンコードは、標準のパディング付きBase64と一致します。
Man
ManBase64
TWFuMan は UTF-8/ASCII の3バイトです。TWFu は4文字です。3 → 4。
Hello
HelloBase64
SGVsbG8=Hello は5バイトです。SGVsbG8= は = を1つ含めて8文字です。小さなデータでは、パディングで比率が33%より大きく見えます。
Base64のサイズはどう計算するか
標準のパディング付きBase64では、encodedLength = 4 × ceil(originalBytes / 3) です。
| 元のバイト数 | Base64文字数 |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 4 | 8 |
| 5 | 8 |
| 6 | 8 |
1バイトや2バイトでも4文字になります。固定の33%ではなく、この式を使ってください。
「=」パディングは何を意味するか
= は、最後の3バイトブロックが埋まっていなかったことを示します。入力1バイトは = が2つ、2バイトは1つ、3バイトは無しです。パディングは暗号化でもセキュリティ機能でもありません。
Base64URLは場所を節約するか
Base64URLは + を - に、/ を _ に変え、Base64エンコード・デコード はエンコード時に末尾の = を省きます。その = の分だけ文字列は短くなり得ます。3バイト → 4文字の構造は同じなので、Base64URLがより省スペースなバイナリ形式というわけではありません。
ごく短い入力はなぜ33%を超えて増えるのか
1バイト → 4文字は長さ300%増です。2バイト → 4は100%です。3バイト → 4は約33.3%です。n が大きくなるとパディングの影響は相対的に小さくなり、オーバーヘッドは約33%に近づきます。Base64が常にちょうど33%大きいわけではありません。
Base64のData URLはなぜさらに大きいのか
Data URLはペイロードの前に data:image/png;base64, のような接頭辞を付けます。ごく小さなファイルでは、その接頭辞が比率の大半を占めることがあります。Base64エンコード・デコード は生のBase64もData URLも出せます。Data URL出力は標準のアルファベットを使います。
Base64とバイナリ、どちらが小さいか
生のバイナリは転送と保存のスペース効率が良いです。Base64は大きいですが、JSON、メール、その他テキスト専用の経路ではテキストとして安全です。バイナリからテキストへのエンコードであり、圧縮ではありません。
Base64はファイルを圧縮するか
しません。Base64は圧縮形式ではありません。エンコードしたテキストは通常、元のバイトより大きいです。そのテキストに後から gzip や Brotli をかければ、冗長の一部は縮むことがあります。結果はデータと圧縮器に依ります。gzip がBase64のオーバーヘッドを完全に消すわけではありません。
Base64をgzipするとどうなるか
HTTP圧縮はBase64テキストの繰り返しパターンの一部を減らせます。JPEG、PNG、ZIPは生バイトでも圧縮しにくいことが多く、Base64のあと gzip しても場合によります。gzip 後の一律の追加パーセントはありません。
ファイルをBase64で保存すべきか
JSONのフィールド、小さなインライン資産、テキスト専用API、コピー＆ペースト、Data URLにはBase64が合うことがあります。大きなファイルでは保存、メモリ、ペイロードがすべて増えます。「ファイルにBase64を使うな」という意味ではありません。
JSON APIでBase64がよく使われる理由
JSONには生バイナリの型がないので、APIはバイトをBase64文字列に入れることがよくあります。大きなファイルでは multipart/form-data、オブジェクトストレージ、直接のバイナリアップロードの方が合うことがあります。どちらが常に最善というわけではありません。
メールでBase64が使われる理由
MIMEはバイナリ添付をテキストとして安全な文字で運ぶためにBase64を使うことがあります。同じサイズのオーバーヘッドはそのままです。より小さいファイルではなく、転送用の表現です。
いつ余分なサイズが見合うか
バイナリをテキストの中に置かねばならないとき、ペイロードが小さいとき、APIがBase64を求めるとき、Data URLが必要なときは、余分なサイズが見合うことがあります。大きなメディアでは、システムが許すなら生バイナリを優先してください。
いつBase64を避けるべきか
大きなファイル、帯域が厳しいとき、頻繁な転送、すでにバイナリ経路があるときは飛ばしてください。状況の話であり、「Base64は悪い習慣」ではありません。
確認できるパディング付きBase64の長さ
元のバイト数と、標準のパディング付きBase64文字数：
| 元のバイト | Base64文字 |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 10 | 16 |
| 100 | 136 |
| 1,000 | 1,336 |
すべての行は 4 × ceil(n / 3) に従います。これはBase64の文字数です。
例：1,000バイトのファイルはどれくらいになるか
4 × ceil(1000 / 3)。ceil(333.333…) = 334、4 × 334 = 1336 です。つまり1,000バイトはBase64文字1,336個になります。UTF-8/ASCIIで保存すると文字は通常1バイトですが、1,336を正確なメモリ上のバイト数とは見なさないでください。
Base64はファイルサイズ以上にメモリを使うか
ランタイムによっては文字あたり1バイト超で文字列を持ち、エンコードとデコードのあいだバッファと文字列が同時に残ることがあります。メモリ使用量は文字長とちょうど同じではありません。
簡単なサイズ判断の案内
システムが生バイナリを受け付けるなら、サイズのためそれを優先してください。テキストしかだめならBase64が合うことがあります。大きなペイロードならバイナリアップロード経路を確認してください。URL安全なテキストならBase64URLを検討してください。3対4の拡大はそのままです。
- バイナリデータを送る必要がある
- 生バイナリが使える？サイズのためバイナリを優先
- テキスト専用フィールド？Base64が適切なことがある
- 大きなペイロード？バイナリアップロード経路を確認
- URL安全なテキストが必要？Base64URLを検討
- 大きな入力ではテキストが約33%増えると見込む
Base64はデータを小さくする設計ではありません。テキスト系のシステム内でバイナリを表しやすくし、その対価が余分なサイズです。
ブラウザでBase64をエンコード・デコードする
NEXNARA Base64エンコード・デコード はテキストをエンコード・デコードし、ファイルをBase64またはData URLにし、Base64をファイルに戻せます。
テキストはUTF-8バイトにしてからBase64です。ASCIIだけではありません。StandardかBase64URLを選びます。ファイル出力は生Base64またはData URL（標準アルファベット）です。不正な入力は拒否されます。UTF-8でないバイトはテキストデコードではなく、ファイルへ戻してください。
10 MB を超えるファイルはタブが遅くなることがあります（警告）。32 MB を超えるファイルはブロックされます。
エンコードとデコードはこのブラウザ内で行います。このツールのためにファイルがNEXNARAサーバーへ送られることはありません。広告や他のサイト機能はネットワークを使います。
Base64エンコード・デコード にテキストやファイルを入れて、元のバイトとエンコード後の長さを比べてください。
FAQ
なぜBase64はファイルサイズを増やすのか
3バイト（24ビット）を4文字（4 × 6ビット）に対応づけます。テキストとして保存すると、大きな入力ではだいたい3分の1増えます。
Base64は常に33%大きいのか
いいえ。大きな入力は約33.3%に近づきます。ごく短い入力はパディングでもっと増えます。4 × ceil(n / 3) を使ってください。
Base64はバイナリよりどれだけ大きいか
標準のパディング付き長さは 4 × ceil(n / 3) 文字です。Data URLの接頭辞がさらに加わります。
Base64圧縮はファイルを小さくするか
Base64は圧縮しません。エンコードしたテキストに gzip や Brotli をかけると一部は縮むことがありますが、どの場合でもオーバーヘッドが消えるわけではありません。
Base64URLは場所を節約するか
= パディングを落とせるので、文字列が0〜2文字短くなることがあります。3対4のエンコード構造は同じです。
大きなファイルにBase64を使うべきか
テキストが必要なときだけです。大きいか頻繁な転送では、バイナリ経路の方が小さいことが多いです。APIでBase64が常に誤りというわけではありません。