把小圖片塞進網頁與 CSS
前端最常見的用法，是把小圖示、logo 轉成 Base64 後內嵌在 HTML 或 CSS 裡，變成 data:image/... 開頭的 URI。這樣瀏覽器不用再發一次請求去抓圖片，頁面載入更快，也少了一個可能失效的外部連結。
但只適合小圖：Base64 會膨脹約 33%，大圖內嵌反而讓網頁變慢。一般經驗是幾 KB 的小圖示適合，幾十 KB 以上的圖片還是用獨立檔案。
API 與設定檔裡的資料搬運
很多 API 用 Base64 來傳二進位資料，例如上傳圖片時把檔案內容編碼後塞進 JSON 欄位。因為 JSON 只能放文字，不編碼就傳不出去。
設定檔與環境變數也是重災區：憑證、私鑰、特殊字元一多的設定值，先做 Base64 編碼再寫進去，可以避開換行、引號、字元集造成的解析錯誤。
郵件與舊系統的相容層
電子郵件附件（MIME）底層就是用 Base64 傳的，這是幾十年來的標準。有些老系統只接受純文字，傳檔案前先編碼，是讓新舊系統能溝通的土方法。
日常工作中也常遇到：客戶貼來一串解不開的編碼、log 裡夾著編碼過的錯誤訊息，這時打開線上工具解碼一下，幾秒鐘就能看到原文，不用寫程式。
常見問題
data: 開頭的網址是什麼？
那是 Data URI，把檔案內容用 Base64 內嵌在網址裡。瀏覽器看到 data:image/png;base64, 後面那串，就知道直接解碼顯示，不用再去下載檔案。
JWT 前面那段 eyJ 開頭的是 Base64 嗎？
是的，JWT 的標頭與載荷用的是 Base64URL 編碼（Base64 的網址安全變體）。解開就能看到裡面的 JSON 內容，但注意它只是編碼、沒有加密。
什麼時候不該用 Base64？
大檔案、需要省空間、需要保密的場景都不該用。它會讓體積變大 33%，而且任何人都能解開，只適合「讓二進位走純文字通道」這個特定目的。