Base64 為什麼會讓檔案變大？

這篇文章解釋 Base64 輸出為何比原始位元組還大。它不是資安教學。若要分辨編碼與加密，請改用 Base64不是加密：它真正在做什麼、如何解碼。

Base64 為什麼需要更多空間？

3 個位元組等於 24 位元。Base64 把這 24 位元拆成 4 組、每組 6 位元。每一組對應一個 Base64 字元，因此 3 個輸入位元組會變成 4 個輸出字元。若每個 ASCII 字元以 1 位元組存放，就是 4 / 3 ≈ 1.333——約增加 33.3%。

• 3 個位元組（24 位元）
• ↓
• 拆成 4 組、每組 6 位元
• 每一組 → 一個 Base64 字元
• ↓
• 4 個字元（寫成文字時常佔 4 位元組）

可自行核對的簡單範例

以下編碼與標準有補位的 Base64 相符。

Man

Man

Base64

TWFu

Man 是 3 個 UTF-8/ASCII 位元組。TWFu 是 4 個字元：3 → 4。

Hello

Hello

Base64

SGVsbG8=

Hello 是 5 個位元組。SGVsbG8= 是 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 個位元組用一個；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 嗎？

Base64 可以把二進位放進 JSON 欄位、小型內嵌資產、純文字 API、複製貼上或 Data URL。面對大檔時，儲存、記憶體與酬載都會變大。這並不是說「檔案絕對不要用 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 位元組會變成 1,336 個 Base64 字元。以 UTF-8/ASCII 存放時，每個字元通常是 1 位元組——請不要把 1,336 當成精確的記憶體位元組數。

Base64 用到的記憶體會比檔案大小看起來的更多嗎？

有些執行環境會用每個字元超過 1 位元組來存放字串，編碼／解碼過程也可能同時保留緩衝區與字串。記憶體用量並不完全等於字元長度。

一份簡單的大小決策指引

系統若接受原始二進位，為了大小請優先採用。只允許文字時，Base64 可能合適。酬載很大時，先確認有沒有二進位上傳路徑。需要 URL 安全文字時，可考慮 Base64URL——3 變 4 的擴張仍然存在。

• 需要傳送二進位資料
• ↓
• 允許原始二進位？為了大小請優先二進位
• 純文字欄位？Base64 可能合適
• 大酬載？檢查是否有二進位上傳路徑
• 需要 URL 安全文字？考慮 Base64URL
• ↓
• 偏大輸入預期文字大約多 33%

在瀏覽器裡編碼或解碼 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 位元）。存成文字後，偏大輸入大約多三分之一。

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 並非總是錯的。