Base64 編碼會把二進位影像檔轉成一行純 ASCII 文字，讓它能在 JSON 承載、HTTP 請求，以及 n8n 內部的 Code 節點中傳遞。若要在 n8n 工作流程中將影像轉成 base64，請在本機的瀏覽器編碼器(例如 Image to Base64 Converter)中開啟 PNG、JPEG、GIF 或 WebP 檔，選擇輸出為純 Base64 字串或完整的 data URL，執行轉換，確認偵測到的格式與解碼後的尺寸，然後把文字複製到工作流程中。透過 n8n 串接的多個第三方服務，當字串包含換行、空格，或是 data URL 前綴與實際檔案位元組不符時，會拒絕接收影像承載，因此編碼器必須依據位元組而非檔名來驗證容器。這個轉換器同時強制 5 MiB 的輸入上限、6,990,531 字元的輸出上限，以及單邊 20,000 像素、總面積 40,000,000 像素的邊緣限制，這些限制在 n8n 的 Code 節點內組裝承載時都很關鍵。
為什麼 n8n 工作流程需要 Base64 影像字串
n8n 以 JSON 或二進位項目在節點之間傳遞資料，但並非所有下游服務都能接收二進位項目。視覺模型的 API、像 CapSolver 這類 OCR 引擎、像 Odoo 這類 ERP 整合，以及許多 webhook 端點，都預期影像以字串屬性的形式內嵌傳入。這類整合的標準模式是:一個觸發節點、一個用來抓取檔案的 Read Binary File 或 HTTP Request 節點、一個把位元組轉成字串的 Code 或 Function 節點，最後是一個外送的 HTTP Request 節點，在其 JSON 主體中包含該字串。
當檔案抵達接收端時，通常必須同時滿足兩個條件。字串必須是連續不中斷的一行，不能包含換行或空白字元;若有使用 data URL 前綴，則必須與檔案實際的容器相符。即使是將 PNG 重新命名為 photo.jpg，仍應使用 data:image/png;base64，而非 data:image/jpeg;base64，許多視覺 API 在前綴與解碼後位元組不一致時會拒絕呼叫。
在 Code 節點中處理這件事，適用於已經在流程內的檔案;但在開發階段，你通常會想要一組可以貼到 Set 節點、模板字面值、JSON fixture 或測試 webhook 的參考字串。一個在本機執行、不上傳檔案，並能從位元組證明容器正確性的瀏覽器編碼器，是在串接執行階段路徑之前取得該參考值最乾淨的方式。
為 n8n 取得乾淨的 Base64 字串(逐步操作)
- 在將用來複製內容的同一個瀏覽器分頁中開啟 Image to Base64 Converter，這樣剪貼簿結果才不會被其他應用程式攔截。
- 點擊檔案輸入欄位，選擇一個你打算透過 n8n 傳送的 PNG、JPEG、GIF 或 WebP 檔。該工具最多讀取 5,242,880 位元組;只要多一個位元組，就會在讀取主體前被拒絕。
- 選擇輸出模式。若下游服務預期接收原始字串，請選擇純 Base64;若預期接收帶前綴的完整 data:image/...;base64,... 值，請選擇 data URL。
- 執行轉換，並等待預覽、偵測到的位元組格式、解碼後的尺寸與檔案大小出現。
- 確認偵測到的格式字串。它應該與檔案實際的容器相符。將 PNG 重新命名為 .jpg 仍會回報 image/png，這也是 data URL 前綴會出現的值。
- 點擊複製按鈕。產生的文字就會在剪貼簿中，不會帶任何換行、新行或多餘的空白。
- 將字串貼到 n8n 的 Set 節點欄位、Code 節點變數或 JSON fixture 中。
若在成功轉換後切換檔案或輸出模式，先前的預覽、輸出、錯誤與複製狀態會自動清除。每次變更後請重新複製，避免貼上過期的值。若剪貼簿寫入被拒絕，仍可選取可見的文字，並用鍵盤快捷鍵手動複製。
將輸出貼到 n8n 的 Code 節點或 Set 節點
在 n8n 中，轉換後的字串通常會落在三個地方之一:Set 節點中當作字串屬性(例如 image_base64)的值、Code 節點運算式中用來包成 JSON 主體的片段，或是在串接即時二進位串流之前，用來測試整合的靜態工作流程值。瀏覽器轉換器所產生的參考字串，讓你能在串接執行階段編碼路徑之前，先確認下游呼叫能正常運作。
當你從已測試的參考字串，轉換到 n8n 內部的執行階段轉換時，可加入一個 Code 節點，用 Buffer.from(data).toString('base64') 讀取二進位項目並編碼緩衝區。常見的模式如下:
const item = $input.item; const buffer = await this.helpers.getBinaryDataBuffer(0, item.binary.data.fieldName); const b64 = buffer.toString('base64'); return { json: { image_base64: b64, mime: item.binary.data.mimeType } };
用轉換器產生的值來確認你的 HTTP Request 節點送出的承載，是接收端服務可接受的格式。若服務拒絕呼叫，第一個要檢查的就是 MIME 字串。許多服務會驗證 data URL 前綴與容器是否一致，而轉換器對已驗證位元組的偵測結果，是釐清這種不一致最簡單的方式。反向流程(由 n8n 工作流程接收 base64 字串並轉回影像檔)的部分，可參考 Decode a Base64 Image from an n8n Workflow 指南，裡面有對應的 Code 節點模式。
影響 n8n 承載的格式與大小限制
每個容器檢查都是依據實際的檔案位元組進行。檔名、檔案選擇器的篩選條件，以及作業系統回報的 MIME 類型，都不會決定格式。這正是把值貼進 n8n 承載時你所需要的特性:data URL 前綴一定會與位元組一致，而不是與檔名一致。
| 容器 | 檔案位元組中的偵測訊號 | 對應的 data URL 前綴 |
|---|---|---|
| PNG | 八位元組簽章、合法的第一個 IHDR 區塊、結尾的 IEND 邊界 | data:image/png;base64, |
| JPEG | SOI 標記、其後合法的標記、結尾的 EOI 標記 | data:image/jpeg;base64, |
| GIF | GIF87a 或 GIF89a 標頭、邏輯螢幕描述元、結尾的 trailer | data:image/gif;base64, |
| WebP | 符合檔案大小的 RIFF 長度、WEBP FourCC、合法的 VP8、VP8L 或 VP8X 第一個區塊 | data:image/webp;base64, |
完成偵測後，轉換器會透過 createImageBitmap 在瀏覽器中解碼檔案，並以 HTMLImageElement 作為備援。即使承載刻意模擬某個檔頭但內容已損毀，只要瀏覽器回報正尺寸，才會產生輸出，這代表在產生任何文字之前，具有誤導性的前綴或虛假簽章會先被擋下。
| 限制 | 精確數值 | 對 n8n 為何重要 |
|---|---|---|
| 最大輸入檔案大小 | 5,242,880 位元組 (5 MiB) | 超過的檔案會在讀取主體前被拒絕 |
| 最大 Base64 輸出長度 | 6,990,508 字元 | 輸入上限再多一個位元組，就會使輸出超過此限制 |
| 最大 data URL 輸出長度 | 6,990,531 字元 | 已包含最長支援的 data URL 前綴 |
| 解碼後的最大邊長 | 單邊 20,000 像素 | 任一邊超過即拒絕 |
| 解碼後的最大總像素數 | 40,000,000 | 超過時即使邊長符合也會被拒絕 |
輸出上限是輸入上限與 RFC 4648 字元集的直接結果。根據該標準，每三個輸入位元組會對應到四個輸出字元，使用的是大寫字母、小寫字母、數字、加號與斜線。當最後一組只剩一個或兩個位元組時，編碼器會補上一個或兩個等號，讓解碼端能還原原始長度。套用到最大可接受輸入:5,242,880 位元組除以三得到 1,747,626 個完整群組，餘 2，產生 1,747,627 個由四字元組成的群組，即 6,990,508 字元的純 Base64。加上最長的 data URL 前綴後，就得到轉換器強制執行的 6,990,531 字元上限。你可以透過 RFC 4648 直接驗證分組與填補的各種情況。
Base64 在任何前綴加入之前，大約會讓資料成長三分之一，因此 1 MiB 的影像在 n8n 的 JSON 主體中會變成約 1.33 MiB 的文字。對於 JSON 屬性來說，數 MB 的影像通常不是好的選擇;若承載僅用於測試或 fixture，通常一個小樣本就足夠了。
編碼前的相關轉換
Image to Base64 Converter 會在 Base64 承載中保留原始且通過驗證的檔案位元組。它不會在畫布上繪製、縮放、重新壓縮、改色、攤平透明、移除中繼資料、修復損壞或最佳化檔案大小，也不會從動畫 GIF 中挑選某一個畫格。動畫 GIF 與 WebP 的位元組，在接收端支援的情況下，於承載中會保持動畫。若你需要先取得較小的檔案再編碼，請先用專門的工具處理，再對結果進行編碼。
- 使用 Image Compressor 在瀏覽器中先壓縮 JPG、PNG 或 WebP，再進行編碼。
- 若需要特定的像素尺寸，請使用 Image Resizer;編碼器本身不會調整大小。
- 若需要反向的 n8n 工作流程，請參考 Decode a Base64 Image from an n8n Workflow 指南。
此轉換器僅接受下列四種容器。SVG、AVIF、HEIC、BMP、TIFF、PDF 以及任意文字檔都不在支援範圍內，即使瀏覽器或副檔名把它們視為影像也一樣。若需要這些格式的 base64，請先轉成 PNG、JPEG、GIF 或 WebP。
若要在 n8n 內部進行執行階段編碼，請使用針對 $input.item.binary 的 Code 節點，讓每次工作流程執行都能處理實際傳入的檔案。若要產生會貼到工作流程中的靜態字串，瀏覽器轉換器是較安全的選擇，因為它在提供任何可複製的文字之前，會先驗證容器與解碼後的像素。即使內容都留在本機，仍應將來源不明的影像視為不受信任的內容:瀏覽器成功解碼只代表技術上可讀，並不代表作者身分、無障礙性、著作權狀態，或沒有夾藏資料。
如果你正在權衡不同做法，Convert Multiple Base64 Strings to Image Files 有更詳細的說明。