Base64 是一種可逆且文字安全的編碼方式，定義於 RFC 4648，它能將任何位元組序列（包括 Unicode 文字、表情符號和原始二進位檔案）轉換成僅由 64 個 ASCII 字元組成、可選擇性加上「=」填補字元的字串，而這正是 Base64 轉換工具所要解決的問題。Base64 轉換工具是日常用來透過只接受純文字的通道（例如 JSON 欄位、HTML 屬性、查詢字串、電子郵件內文和 HTTP 標頭）傳遞二進位或非 ASCII 資料的工具。它在一端接收你的輸入，套用 RFC 4648 的字母表（A–Z、a–z、0–9、'+' 和 '/'），然後在另一端輸出編碼結果；反轉方向後，同一個轉換工具會將該字串還原成原始位元組。關鍵在於，正確的轉換工具會先將文字編碼為 UTF-8 位元組，這樣帶腔調字母、中文字元和表情符號才能在不損壞的情況下完整往返——這是多數天真的實作會出錯的地方，因為它們依賴瀏覽器內建的 btoa()，而 btoa() 只接受 Latin-1。輸出永遠是文字，且永遠可逆，這就是為什麼 Base64 在現代網路技術堆疊中無處不在，卻永遠不能取代加密。
Base64 在真實系統中出現的地方
Base64 並非學術上的好奇心。它幾乎出現在現代網路的每一層，快速瀏覽這些用途就能明白為什麼 Base64 轉換工具是開發人員與進階使用者的每日利器。
最顯眼的地方就是 HTML 與 CSS 中使用的 data: URI。你可以選擇不連結到外部檔案，而是直接把圖片、字型或圖示直接內嵌進去：
background: url("data:image/png;base64,iVBORw0KGgo...")
那段 Base64 文字 blob 就是以文字形式表達的 PNG 檔案位元組，這讓樣式表、電子郵件或單一檔案的 HTML 頁面可以攜帶圖片而無需額外的網路請求。其他常見的出現位置還包括 JSON Web Token（JWT）以點分隔的三個段落、Basic HTTP 認證標頭中的 username:password 配對、MIME 多部分電子郵件附件，以及任何需要在 JSON API 負載中以字串形式傳遞二進位 blob（縮圖、PDF 雜湊、加密簽章）的情況。
| 用途 | 在哪裡看到 Base64 | 為什麼 Base64 有幫助 |
|---|---|---|
| Data URI | HTML 的 src 與 CSS 的 url() 屬性 | 將二進位資產以文字形式內嵌，省去一次額外的網路請求 |
| JSON Web Token | 標頭、負載與簽章段落 | 讓 JSON 安全地穿過 HTTP 標頭與表單欄位 |
| MIME 電子郵件 | 附件的 Content-Transfer-Encoding 標頭 | 透過只接受 7 位元純文字的 SMTP 傳輸二進位檔案 |
| Basic HTTP 認證 | Authorization 標頭的值 | 以單一 ASCII 字串形式傳送憑證 |
| JSON API 中的二進位資料 | 用來承載圖片、雜湊或簽章的字串欄位 | 即使負載包含原始位元組，仍能保持 JSON 格式正確 |
每當系統需要讓位元組安全通過純文字通道時，Base64 就是答案，而轉換工具就是負責把位元組送進去與取出來的角色。
如何逐步使用 Base64 轉換工具
轉換文字或位元組最快速的方法，就是開啟一個 Base64 轉換工具、選擇方向，然後讓它隨著你的輸入即時運作。Base64 Encode / Decode 的工具完全遵循 RFC 4648 標準，並且無需按下送出按鈕就能即時更新輸出。
- 選擇方向。選擇 Encode 把純文字轉成 Base64，或選擇 Decode 把 Base64 字串轉回文字。
- 在頂端輸入框中輸入或貼上你的內容。輸出會在你輸入的同時立即出現在下方的輸入框中——無需按按鈕。
- 在輸出框中讀取結果，或點選 Copy 將其複製到設定檔、curl 指令或程式碼片段中使用。
- 如果需要把結果直接再回送一次，點選 Swap direction 切換 Encode/Decode 方向，並把輸出當成新的輸入重複使用。
這套流程在兩個方向上完全相同。貼上 JWT 段落來檢視其 JSON 負載、貼上 data: URI 來還原原始文字、或貼上一段像 foobar 的短字串來看它變成 Zm9vYmFy。轉換是逐位元組在本機執行，因此即使是大篇幅的貼上也不會逾時。
為什麼 UTF-8 處理是優秀 Base64 轉換工具的決勝點
UTF-8 是區分一個能用的 Base64 轉換工具和一個令人挫折的工具的唯一關鍵。Base64 演算法是處理位元組而非字元，所以轉換工具必須在編碼前先決定如何把你的文字轉成位元組。錯誤的選擇是假設每個字元都能塞進一個位元組；正確的選擇是先用瀏覽器的 TextEncoder 將文字編碼為 UTF-8 位元組，再對這些位元組執行 Base64。
天真的做法——直接呼叫內建的 btoa()——在你餵入非 ASCII 內容的那一刻就會悄悄出錯。btoa() 只接受 0–255（Latin-1）的碼點，所以像 café、你好 或 😀 這類字串會直接丟出 InvalidCharacterError，而不會產生 Base64 字串。正確的轉換工具會先把文字編碼為 UTF-8 位元組，因此表情符號的四個 UTF-8 位元組會像其他任何二進位資料一樣被編碼，而反向路徑則會執行一個嚴格的 fatal: true UTF-8 解碼器，這樣格式錯誤的輸入會被拒絕，而不是產生悄悄替換的字元。
這就是為什麼任何 Base64 轉換工具的基本煙霧測試都應該包含超出純 ASCII 範圍的內容。編碼 café、你好 和 😀；分別複製結果；然後把結果再貼回 Decode。如果你拿回完全相同的原始文字，沒有替換字元、沒有亂碼、也沒有錯誤，那這個轉換工具就是做對了。
解讀 Base64 結尾的「=」填補字元
Base64 是一種固定長度的封裝機制：三個輸入位元組會變成四個輸出字元。當輸入長度不是三的倍數時，輸出會以一個或兩個「=」號填補，使編碼後的長度維持為四的倍數，這是每個相容解碼器所預期的。
規則很簡單，值得記住：
- 一個位元組的輸入 → 兩個 Base64 字元加上兩個 = 號（例如 "f" → "Zg=="）。
- 兩個位元組的輸入 → 三個 Base64 字元加上一個 = 號。
- 三個位元組的輸入 → 四個 Base64 字元，沒有填補。
- 六、九、十二個位元組，或任何其他三的倍數的位元組 → 都不需要填補。
這就是為什麼 "foobar"（六個位元組）會變成 "Zm9vYmFy 而沒有「=」號，反觀單一個字母則會補上兩個。「=」填補屬於 RFC 4648 中定義格式的一部分，不是解碼前應該先剝掉的雜訊。有些程式庫為了方便會接受未填補的 Base64，但正式形式仍保留「=」號，讓任何解碼器——包括 Base64 Encode / Decode 工具所用的嚴格版本——都能依賴長度永遠是四的倍數。
Base64 不是加密
這一點值得一再重申，因為這個混淆很常見：Base64 是一種編碼，不是加密。任何能讀懂 64 字元字母表的人都能完全將其還原，沒有金鑰、沒有秘密，也沒有任何解碼的運算成本。把 Base64 當成「加密」這種錯誤，正是會出現在事故報告中的那種失誤。
正確的心智模型是：Base64 解決的是傳輸問題，而非機密性問題。它接收包含不可列印值的位元組——NUL、高位元位元組、原始影像資料——並將它們改寫成安全的 ASCII，讓它們能夠在 HTML 屬性、JSON 字串、電子郵件內文與 HTTP 標頭中傳輸而不會破壞剖析器。一旦位元組抵達另一端，就會用同一套字母表精準地還原。
如果你真的需要機密性，就需要真正的加密工具：對稱資料使用 AES-GCM，非對稱金鑰包裹使用 RSA-OAEP，或使用像雲端 KMS 這樣的代管服務。若要在不保密的情況下驗證完整性，SHA-256 或 HMAC 雜湊才是正確的工具。Base64 只是負責把這些基礎工具的結果安全地帶過純文字通道而已。
本機瀏覽器處理與隱私
因為 Base64 是純粹的位元組轉換，它可以完全在用戶端執行。Base64 Encode / Decode 工具使用標準瀏覽器 API——TextEncoder 用於 UTF-8、嚴格的 TextDecoder 用於驗證，以及一個逐位元組處理大量貼上內容而不會發生堆疊溢位的編碼器——所以不會有任何資料被上傳到伺服器。
這在實務上很重要。JWT、除錯時貼進標頭的 API 金鑰，以及簡短的設定片段，往往含有足夠敏感的資料，你不會想讓它們出現在別人的紀錄檔中。使用完全在用戶端運作的轉換工具時，唯一一次的網路請求就只有頁面本身；你貼上的位元組永遠不會離開這個分頁。這讓你可以在共用電腦或公司網路上，安全地把權杖放進輸入框，而不必擔心被第三方側錄。
對於想從 Base64 再進一步到原始十六進位——以便一次檢查一個位元組，或將它們餵進低階工具——的讀者，Base64-to-hex conversion guide 會在沒有猜測的情況下，逐步說明確切的位元組對應方式。
如果你正在權衡各種選項，From Hex to Base64 in Python Without Breaking the Bytes 有更詳細的說明。