在 n8n 中，將檔案轉換為 Base64 表示的是將任何檔案（影像、PDF、CSV、音訊）的二進位資料轉成單一文字字串，使其能夠在 JSON 承載內容、HTTP 請求主體、資料庫欄位或 Code 節點變數中傳遞，且不會遺失任何位元組。n8n 透過其內建節點（Convert to File、Move Binary Data 以及 Code 節點）提供此轉換功能，而社群套件則新增了直接進行二進位到 Base64 轉換的作業。由於許多下游端點會嚴格依據 RFC 4648 來驗證 Base64——即標準字母表加上標準填補且未使用的填補位元為零的規範形式——當編碼器產生未填補、Base64url、以 MIME 包裹或帶有 data-URL 前綴的字串時，n8n 工作流程就會中斷。File to Base64 Converter 提供了一個本地瀏覽器參考基準，說明嚴格的規範輸出應該長什麼樣子，並且也能將可疑的 Base64 字串解碼回可下載的檔案，讓您能確認 n8n 節點實際產生了什麼。由於所有處理皆透過 W3C File API 在目前的瀏覽器分頁中完成，您可以在不上傳機密檔案到第三方轉換器的情況下，針對承載內容格式進行測試。
為什麼 n8n 工作流程需要嚴格且規範的 Base64
將 PDF 上傳到內部 API、將影像推送到 CMS，或將 CSV 儲存於 JSON 欄位中的 n8n 工作流程，通常會對其接收的二進位資料執行下列三種作業之一：
- 將其傳遞通過內建節點，例如 Convert to File、Move Binary Data 或 HTTP Request，並將主體參數設定為 Base64 字串。
- 執行一個小型的 Code 節點，呼叫 Buffer.from(binary, 'base64').toString('base64') 或等效的輔助函式。
- 安裝社群套件——Data Converter、customJS 或其中一個無程式碼的「Binary to Base64」節點——在友善的 UI 背後包裝相同的作業。
許多目的地端點——GitHub 的內容 API、數個 webhook 接收器、受 OAuth 保護的 REST 服務，以及各種 SaaS 上傳器——會拒絕任何不符合 RFC 4648 §4 所定義形式的內容：標準字母表（大寫 A–Z、小寫 a–z、數字 0–9、加號、斜線）、必須的等號填補至四的倍數，以及未使用的填補位元為零。RFC 4648 同時定義了兩種看起來相似但會破壞嚴格驗證器的格式：Base64url（將加號替換為減號、斜線替換為底線，通常會省略填補）以及 MIME（在 76 個字元處進行換行包裝）。data-URL 前綴（例如 data:application/pdf;base64,）則位於所有這些格式之前。
| 格式 | 字母表 | 填補 | 空白字元 | URL 安全？ | 需要 data-URL 前綴？ |
|---|---|---|---|---|---|
| 標準 (RFC 4648 §4) | A–Z、a–z、0–9、+、/ | = 至 4 的倍數 | 不允許 | 否（使用百分比編碼） | 僅在接收端要求時 |
| Base64url (RFC 4648 §5) | A–Z、a–z、0–9、-、_ | 通常省略 | 不允許 | 是 | 否 |
| MIME 包裝 (RFC 4648 §5) | A–Z、a–z、0–9、+、/ | = 至 4 的倍數 | 每 76 個字元一個 CRLF | 否 | 僅在接收端要求時 |
| Data URL (RFC 2397) | 逗號之後可為上述任一格式 | 取決於內部格式 | 承載內容內不允許 | 有時 | 是——那就是前綴 |
如果 n8n 節點、程式碼片段或社群套件省略了填補、將加號換成減號，或插入了換行符號，那麼目的地驗證器就會回傳令人費解的「內容不是有效的 Base64」錯誤，導致工作流程停止。問題通常不在工作流程邏輯中——而在於必須符合目的地所預期的確切格式，並提供嚴格、規範的位元組。
瀏覽器轉換器在 n8n 管道中的定位
File to Base64 Converter 並非 n8n 節點，也無法從執行中的工作流程讀取資料。它的功能是——完全透過 W3C File API 在瀏覽器中執行——為特定檔案產生嚴格符合 RFC 4648 規範輸出的參考基準，並將任何 Base64 字串解碼回其所代表的確切位元組。不會進行任何上傳；應用程式不會將檔案名稱、MIME 類型或內容傳送到伺服器。
該參考基準在三個反覆出現在工作流程論壇中的 n8n 情境中非常有用：
- 靜態承載內容與範本。部分工作流程會將固定檔案（浮水印影像、HTML 標頭、範例文件）作為硬編碼的 Base64 字串嵌入 Set 或 Function 節點中。使用轉換器準備該字串，可確保其為接收端可接受的填補完整、規範形式。
- 除錯「不是有效的 Base64」錯誤。當 n8n 的 HTTP Request 或 GitHub 節點拒絕上傳時，最快的診斷方式是解碼工作流程實際產生的字串、將其儲存並加以檢查。轉換器的反向模式使用與接收端強制執行相同的嚴格字母表與填補規則來完成此作業。
- 往返驗證。在社群節點完成其 Binary to Base64 作業後，將該字串複製到轉換器並重新解碼，可以確認每個位元組皆完好無損，且編碼器輸出了規範的結果。
由於轉換器在本機執行，因此沒有任何檔案會離開瀏覽器。當工作流程處理發票、已簽署的合約、API 金鑰、內部螢幕擷取畫面或任何受資料處理政策約束的二進位資料時，此邊界至關重要。
使用瀏覽器工具在 n8n 中將檔案轉換為 Base64
下列步驟可產生一個規範且已填補的 Base64 字串，您可將其貼上至 n8n 的 Set 節點、Code 節點或任何固定的承載內容欄位。檔案保留在您的電腦上；瀏覽器透過 File API 讀取它並呈現編碼後的文字。
- 開啟 File to Base64 Converter 並確認頁面處於 File → Base64 模式。
- 點擊檔案選擇器並選擇不超過 10 MB 的檔案。頁面會顯示檔案名稱與精確的位元組大小，以便您驗證來源。
- 等待編碼後的文字完整呈現。輸出僅包含 Base64 字元以及用於將最後一組填補至四個字元的等號；沒有 data-URL 前綴、沒有 MIME 標頭，也沒有換行包裝。
- 複製完整的字串。在開頭或結尾遺漏任何字元都會導致另一端的解碼器失效，因此請使用單一的全選並複製作業，並驗證長度為四的倍數。
- 在 n8n 中，將該字串貼到適當的欄位中：Set 節點的字串值、Code 節點的常數、HTTP Request 節點的主體參數，或 Notion / Airtable / Database 的文字欄位。
- 若目的地預期採用 data URL 前綴（部分 CMS 會要求），請明確地在前面加上：data:<mime-type>;base64,<已複製的字串>。不要讓節點靜默地新增換行包裝或修剪等號。
- 在單一測試檔案上執行工作流程，並確認上游節點傳回的長度與首尾各 16 個字元與轉換器輸出相同。任何不符皆表示該節點已重新編寫字串。
對於大小敏感的承載內容，請記住位元組與字元之間的關係：每三個來源位元組恰好會變成四個 Base64 字元，因此 3,000,000 位元組的檔案會產生 3,000,000 × 4 ÷ 3 = 4,000,000 字元的字串。因此編碼會使線上傳輸大小增加約三分之一，而將該字串以 JSON 包裝於承載內容內部，會因引號跳脫而進一步增加額外負擔。
在 n8n 中使用反向作業解碼 Base64
轉換器的第二種模式解決相反的問題：您已擁有 Base64 字串——來自 n8n 節點的輸出、webhook 主體、記錄行或資料庫欄位——而您想要確認其所代表的位元組。
- 將轉換器切換至 Base64 → File。
- 移除來源字串所附帶的任何容器。若字串以 data:<mime>;base64，開頭，請刪除至逗號（含逗號）為止的所有內容。若字串包含來自 MIME 包裝的歸位或換行字元，請將其移除，僅保留字母表與填補字元。
- 貼上清理後的字串。解碼器在設計上是嚴格的：它會透過重新編碼已解碼的位元組並進行比較，來拒絕空白字元、遺失的填補、非零的未使用填補位元，以及其他非規範的拼寫形式。
- 設定誠實的檔案名稱與誠實的 MIME 類型。這些欄位僅控制下載建議與 Blob 媒體類型；它們並不會檢查或重新編寫位元組。若您將某個 PDF 的位元組誤標記為 image/png，它仍然是 PDF，但接收應用程式會嘗試將其解讀為 PNG。
- 下載暫存檔案。下載僅作為可撤銷的 Blob URL 存在於瀏覽器分頁內部，請立即將其儲存。
- 使用原本產生該檔案的應用程式進行驗證，或在需要完整性時使用加密雜湊值。若還原的檔案無法開啟，表示問題出在上游的 Base64 字串，而非轉換器。
限制、MIME 類型誠實性與安全性邊界
轉換器將來源與解碼後的檔案皆限制在 10,000,000 位元組。此上限是為了保護瀏覽器的記憶體，因為在處理過程中，原始位元組陣列、Base64 字串與呈現的文字可能同時存在。超過 10 MB 的檔案屬於串流命令列工作流程或以區塊方式處理資料的 n8n 節點的範疇；嘗試將其讀入單一緩衝區將會耗盡瀏覽器分頁的資源。
解碼端的兩個欄位值得特別注意，因為它們誤導下游工具的頻率比誤導位元組本身更高。檔案名稱僅控制建議的儲存名稱；MIME 類型則僅控制瀏覽器附加至下載的 Blob 媒體類型。這兩個欄位皆不會變更任何單一位元組。若上游工作流程以 contract.pdf 的檔案名稱與 application/pdf 的 MIME 類型儲存了 JPEG，則還原後的檔案仍然是 JPEG。請將這兩個欄位視為您依據已知格式誠實選擇的標籤，而非從 Base64 推測出來的標籤。
Base64 本身只是編碼，而非安全性。任何持有相同字串的人皆可在數毫秒內還原原始位元組；該編碼不會加密、雜湊、簽署、壓縮、掃描或清理內容。貼到記錄行、支援單據、分析事件或聊天記錄中的 Base64 字串，對於任何看到它的人而言都是完全可讀的。對於 n8n 中編碼後的承載內容，請套用與來源檔案相同的處理規則——並將機密檔案保存在遠離任何含有未知瀏覽器擴充功能、剪貼簿管理程式或下載檔案處理程式的裝置。
Verifying the result before it leaves your workflow
The final discipline in any n8n file-to-Base64 pipeline is verification. Two checks catch most regressions. First, a round-trip test: after the workflow encodes the file, copy the resulting string back into the converter's decode mode, save the recovered file, and confirm it opens in the original application. A SHA-256 of both files will confirm byte-for-byte equality. Second, a profile check: confirm that the output contains only the standard alphabet, that its length is a multiple of four, and that the unused pad bits are zero. The W3C File API guarantees the browser reads the exact bytes you select, so any deviation between the converter output and the n8n node output is attributable to the node — usually to dropped padding, to a silent Base64url conversion, or to a wrapper that the destination never asked for.
With those two checks in place, the n8n workflow and the receiver both operate on the same well-defined RFC 4648 bytes, and the cryptic "not valid Base64" errors stop appearing in the execution log.
If you're weighing options, Base64 to Hex Free No Sign Up: Convert in Browser covers this in detail.