Base64 會把一份完整的 SVG 檔案轉成 data:image/svg+xml;base64 字串，讓這個向量檔能直接內嵌在 HTML、CSS 或 JavaScript 中，不需要額外的 HTTP 請求。這個轉換是 RFC 4648 所定義的一種純文字對文字的處理:來源 SVG 的每三個位元組會變成四個 Base64 字元，所以在加上 data URL 前綴之前，編碼後的輸出大約會比原始檔案大三分之一。Unicode 字元、帶重音的拉丁字母、CJK 字形以及 emoji，都會先編碼成 UTF-8 位元組，再把這些位元組以 Base64 編碼。完整的可逆路徑是:SVG 原始碼 → UTF-8 位元組 → Base64 字元 → data URL。反向操作則是:拿到對應的 data URL，移除前綴，解碼 Base64，並把解出來的位元組驗證為 UTF-8，再回傳 SVG 文字。SVG to Base64 Converter 就是在你的瀏覽器中執行這個轉換，完全不需要上傳、不進行任何算繪，也不會對來源檔案偷偷做消毒處理。
SVG Data URL 的組成結構
Data URL 是一段單行的文字，包含媒體類型、編碼標籤，以及承載的主體內容。對 SVG 來說，標準化的格式是 data:image/svg+xml;base64,<payload>，其中前綴告訴接收端接下來是什麼樣的位元組，以及這些位元組是如何產生的。承載內容是 SVG 的 UTF-8 位元組序列經 Base64 編碼後的結果，而前綴本身並不屬於編碼後的位元組;解碼器會先把它去掉，再反轉編碼過程。根據 RFC 4648,Base64 是一種「二進位對文字」字母表，而不是壓縮格式，所以承載內容永遠會比原始位元組長度還要大。
這個結構會帶來一些實際上的影響:
- 往返轉換的兩端必須使用完全相同的前綴。嚴格的解碼器會拒絕缺少、拼錯或使用替代前綴的情況，而不是默默產生錯誤結果。
- 承載內容是不透明的 ASCII。原始 SVG 標記在 data URL 內不可讀，也無法在程式碼審查中直接做差異比對，必須先解碼才能檢視。
- Data URL 是一條獨立字串，不會參照任何外部檔案，因此 SVG 所需的一切(字型、圖片、腳本)都必須以內嵌方式提供，或可從嵌入環境本身取得。
如何將 SVG 轉成 Base64
- 在瀏覽器中開啟 SVG to Base64 Converter，選擇 編碼 (Encode) 方向。
- 把一份完整的 SVG 檔案貼到來源區。這個工具要求必須有完整的 svg 根元素並帶有結尾標籤，在處理時會先去除選擇性的 UTF-8 位元組順序記號 (BOM) 與周圍空白。它不強制要求特定的命名空間宣告，但你所提供的命名空間、屬性與元素內容都會原樣保留。
- 執行轉換。工具會先用瀏覽器的 TextEncoder 把 Unicode 文字編碼為 UTF-8 位元組，再以有界區塊處理這些位元組，並把每個區塊依序 Base64 編碼，合併成單一輸出字串。
- 檢視完整的文字結果。回傳的字串一開頭會是精確的前綴 data:image/svg+xml;base64，接在後面的是 Base64 承載內容。如果需要確認編碼是否正確，可以比對承載內容的前幾個字元是否與已知的往返測試一致。
- 複製完整的 data URL，貼到實際要使用它的目的地:img 的 src、CSS 的 background-image: url(...) 宣告、JavaScript 字串，或建置階段的樣板。
- 在真正會消費這段內容的環境中測試算繪結果。開啟頁面或預覽，確認 SVG 正確顯示，並檢查瀏覽器主控台是否有 CSP 或混合內容 (mixed-content) 錯誤。
來源輸入的上限為 500,000 個字元。產生的 data URL 仍可能超出目標網站的政策、HTTP 表頭大小，或目的地所規定的較小容量上限，所以在決定採用內嵌方式之前，務必先規劃好測試步驟。
如何把編碼後的輸出讀回來
當你從建置工具、CMS 匯出檔或樣式表中繼承到一段 data URL，想還原成原始 SVG 以便編輯時，反向操作就很有用。轉換器用相同的三步驟流程處理這個方向，只要改選「解碼 (Decode)」而非「編碼」即可。
| 方向 | 輸入 | 輸出 | 驗證步驟 |
|---|---|---|---|
| 編碼 (Encode) | 完整的 SVG 檔案 (UTF-8 文字) | data:image/svg+xml;base64,... 字串 | 去除 BOM，驗證 svg 根元素結構 |
| 解碼 (Decode) | 精確的 data:image/svg+xml;base64,... 字串 | UTF-8 SVG 文字 | 對解碼後的位元組執行嚴格的 UTF-8 驗證 |
解碼器只接受精確符合的前綴。它不會猜測純 Base64、URL 編碼的 SVG、其他媒體類型參數，或是經過空白正規化的承載內容。嚴格的輸入契約可以避免不小心解碼到無關的資料，並讓不同瀏覽器之間的往返行為保持一致。若輸入不符合，轉換器會回傳錯誤，而不是嘗試修補前綴或用替代字元取代。
為什麼編碼後的輸出會比來源大
Base64 為來源資料的每六個位元配一個 ASCII 字元。三個來源位元組(共 24 個位元)會變成四個 Base64 字元，這就是造成體積成長的規則。以較小的 SVG 來看，計算方式很直接。
一個 300 位元組的 SVG 會產生 300 / 3 * 4 = 400 個 Base64 字元，再加上 26 字元長的前綴 data:image/svg+xml;base64，總計大約 426 個字元。這比來源位元組多了大約 42%，其中尚未計入當輸入長度無法被三整除時，演算法額外加入的 = 填補字元。
這樣的膨脹並不是 bug。Base64 在規範中被定義為一種「二進位對文字」表示法，並非壓縮，而 WHATWG 編碼標準 規範了 Base64 所吃進的 UTF-8 位元組序列。體積成長就是把二進位資料搬進純文字管道的代價。對 SVG 而言有兩個實際的後果:
- SVG 若以獨立檔案形式提供，可以透過 HTTP 內容編碼(通常是 gzip 或 Brotli)進一步壓縮。同一個 SVG 若以 Base64 data URL 內嵌，通常就無法壓縮，所以實際在線上傳輸的體積，會比 Base64 本身的膨脹還要更大。
- Data URL 無法獨立於所在文件之外被快取。如果同一個 SVG 出現在多個頁面，每個頁面都會各自帶一份自己的拷貝。
可靠的經驗法則是實際量測夾帶 data URL 後的 HTML、CSS 或 JavaScript 大小，而不是預設內嵌就一定比較快。對較大且可重複使用的資產來說，獨立快取的 SVG 檔案幾乎總是更划算。
Unicode、UTF-8 與特殊字元
SVG 檔案經常包含非 ASCII 字元:text 元素內含重音拉丁字母、CJK 標籤、emoji 或註解。這些字元在 Base64 編碼之前，都必須先編碼成 UTF-8 位元組。一種常見的錯誤做法，是直接把 JavaScript 字串交給只支援 Latin-1 的 Base64 輔助函式，因為每個字元都被當成一個位元組，結果會把編碼點高於 255 的字元悄悄損毀。
本轉換器使用瀏覽器的 TextEncoder 來產生 UTF-8 位元組序列，接著以有界區塊處理位元組以避免參數清單過大，然後才進行 Base64 編碼。在解碼端，位元組序列會經過嚴格的 UTF-8 驗證器。格式錯誤的 UTF-8 會產生明確的錯誤，而不是以取代字元 U+FFFD 帶過，因為那會造成一個看起來正常、實際上並未正確往返的假成功結果。
| 來源文字 | UTF-8 位元組數 | Base64 字元數 |
|---|---|---|
| 純 ASCII(例如簡單標記) | 每字元 1 位元組 | 每 3 位元組 4 字元 |
| 帶重音的拉丁字母(例如 é) | 每字元 2 位元組 | 每 3 位元組 4 字元 |
| CJK 與大多數 emoji | 每字元 3 或 4 位元組 | 每 3 位元組 4 字元 |
Base64 本身決定了固定的位元組對字元比例;來源字元的類型只會改變在 Base64 編碼開始之前，來源文字會膨脹成多少位元組。在編碼標準規定了 UTF-8 位元組輸出的前提下，一旦取得位元組數，同樣的三分之一公式依然適用。
Data URL 最適合的使用情境(以及應該跳過的時機)
當向量圖檔很小、用途單一，而且與特定文件綁定時，Base64 SVG data URL 就能發揮作用。常見的適合情境包括:單一頁面或樣板內的內嵌圖示與標誌，在這種情況下，多一次的 HTTP 請求會比體積成長更昂貴;電子郵件樣板，因為許多郵件客戶端會擋掉外部圖片，而 data URL 會跟著郵件一起送達;伺服器端算繪的 HTML,SVG 由使用者控制的資料組成，而 data URL 是注入結果最簡單的方式;以及 CSS 展示與 CodePen 風格的程式碼片段，在這類場景中，來源的可讀性比能直接貼上更重要。
當 SVG 檔案較大、會在多個頁面重複使用，或是屬於某套設計系統的一部分時，就應該跳過內嵌。搭配正確的 HTTP 快取、內容編碼與穩定 URL 的獨立檔案，幾乎總是更省傳輸成本，也更容易除錯。轉換器的 500,000 字元來源上限，同樣意味著你能產生的 data URL 也有天花板;如果交付的內容超過這個上限，採用檔案方式才是正確做法。
安全性:Base64 能做與不能做的事
Base64 是一種呈現格式，而不是安全邊界。把 SVG 編碼並不會消毒它、不會移除腳本，也不會擋掉外部資源。腳本、事件處理器、foreignObject 內容、連結、外部字型參照以及濾鏡基本元素，都會原封不動地留在 data URL 內，一旦結果被嵌入到會執行它們的環境，這些內容就會重新生效。
本轉換器絕不會預覽或執行所提供的 SVG，因此在轉換步驟中移除了意外執行的立即風險，但風險只是轉移到了嵌入端。具體來說:不要把來源不可信的 SVG 輸出放進 iframe、object、DOM 或任何 CSS 屬性，除非該環境配備維護良好的消毒流程，以及針對該情境設計的內容安全政策 (CSP)。請把 data URL 視為與原始 SVG 檔案一樣對待:若你不會把該檔案放在自己的網站上，就不要內嵌它的 data URL。對來源不可信的 SVG 應使用獨立、沙箱化的服務環境，搭配嚴格的 HTTP 表頭與持續維護的消毒器。僅靠編碼並無法提供任何保護。
在實際目的地測試結果
轉換本身是在本地進行的，但真正重要的是目的地實際如何處理這個資料 URL。在發佈之前，請確認三件事。
- 目的地的內容安全政策允許該資料 URL。有些網站會在 CSS、行內腳本或圖片情境中完全封鎖 data: scheme 的 URL。img-src 'self' data: 是允許行內 SVG 圖片的常見值。
- 未超出目的地的大小預算。標頭、資料庫欄位、QR 碼和模板引擎都有其限制，而來源端的 500,000 字元上限並不會優先於這些限制。
- SVG 在嵌入情境中的呈現方式與其作為獨立檔案時相同。經過清理的 Markdown 渲染器、嚴格的 CSS 解析器，或精簡過的郵件客戶端，對腳本、濾鏡或外部參考的反應，可能與完整的瀏覽器不同。
如果呈現出來的結果出現差異，應該檢查的是來源 SVG 本身，而非資料 URL。編碼是確定性的且可逆的；差異來自嵌入情境，而非轉換過程。