In n8n, converting a file to Base64 means turning the binary data of any file — image, PDF, CSV, audio — into a single text string that can travel inside a JSON payload, an HTTP request body, a database field, or a Code-node variable without losing a single byte. n8n exposes this transformation through its built-in nodes (Convert to File, Move Binary Data, and the Code node), and community packages add direct binary-to-Base64 operations. Because many of those downstream endpoints validate Base64 strictly against RFC 4648 — the canonical padded form with the standard alphabet and zero-valued unused pad bits — n8n workflows break when the encoder produces an unpadded, Base64url, MIME-wrapped, or data-URL-prefixed string. The File to Base64 Converter gives you a local browser reference for what strictly canonical output looks like, and it can also decode a suspect Base64 string back into a downloadable file so you can confirm what an n8n node actually produced. Because processing happens entirely in the current browser tab through the W3C File API, you can test payload formats against sensitive files without uploading them to a third-party converter.
Why n8n workflows need strict, canonical Base64
An n8n workflow that uploads a PDF to an internal API, pushes an image to a CMS, or stores a CSV inside a JSON column usually does one of three things to the binary data it receives:
- Passes it through a built-in node such as Convert to File, Move Binary Data, or HTTP Request with a body parameter set to a Base64 string.
- Runs a small Code node that calls Buffer.from(binary, 'base64').toString('base64') or an equivalent helper.
- Installs a community package — Data Converter, customJS, or one of the no-code "Binary to Base64" nodes — that wraps the same operation behind a friendly UI.
Many of those destination endpoints — GitHub's content API, several webhook receivers, OAuth-protected REST services, and various SaaS uploaders — reject anything that is not exactly the form defined in RFC 4648 §4: the standard alphabet (uppercase A–Z, lowercase a–z, digits 0–9, plus, slash), required equals-sign padding to a multiple of four, and zero-valued unused pad bits. RFC 4648 also defines two profiles that look similar but break strict validators: Base64url (which replaces plus with minus and slash with underscore and usually drops padding) and MIME (which wraps the line at 76 characters). A data-URL prefix such as data:application/pdf;base64, sits in front of all of them.
| Profile | Alphabet | Padding | Whitespace | URL-safe? | Needs data-URL prefix? |
|---|---|---|---|---|---|
| Standard (RFC 4648 §4) | A–Z, a–z, 0–9, +, / | = to a multiple of 4 | Not allowed | No (use percent-encoding) | Only if the receiver requires it |
| Base64url (RFC 4648 §5) | A–Z, a–z, 0–9, -, _ | Usually omitted | Not allowed | Yes | No |
| MIME-wrapped (RFC 4648 §5) | A–Z, a–z, 0–9, +, / | = to a multiple of 4 | CRLF every 76 chars | No | Only if the receiver requires it |
| Data URL (RFC 2397) | Any of the above after the comma | Depends on the inner profile | Not allowed inside the payload | Sometimes | Yes — that is the prefix |
If the n8n node, the Code snippet, or a community package drops padding, swaps plus for a minus, or inserts line breaks, the destination validator returns the cryptic "content is not valid Base64" error and the workflow halts. The fix is rarely in the workflow logic — it is in matching the exact profile the destination expects and supplying strict, canonical bytes.
Where a browser converter fits in an n8n pipeline
The File to Base64 Converter is not an n8n node and it cannot read data from a running workflow. What it does — running entirely in the browser through the W3C File API — is produce a reference of what strictly canonical RFC 4648 output looks like for a specific file, and decode any Base64 string back into the exact bytes it represents. No upload happens; the application does not send the file's name, MIME type, or contents to a server.
That reference is useful in three n8n scenarios that appear repeatedly in workflow forums:
- Static payloads and templates. Some workflows embed a fixed file (a watermark image, an HTML header, a sample document) as a hard-coded Base64 string inside a Set or Function node. Preparing that string with the converter guarantees the padded, canonical form the receiver will accept.
- Debugging "not valid Base64" errors. When an n8n HTTP Request or GitHub node rejects an upload, the fastest diagnostic is to decode the string the workflow actually produced, save it, and inspect it. The converter's reverse mode does this with the same strict alphabet and padding rules the receiver enforces.
- Round-trip verification. After a community node finishes its Binary to Base64 operation, copying that string into the converter and re-decoding it confirms that every byte survived and that the encoder emitted canonical output.
Because the converter runs locally, no file leaves the browser. That boundary matters when the workflow handles invoices, signed contracts, API keys, internal screenshots, or any binary data covered by a data-handling policy.
Convert a file to Base64 in n8n using the browser tool
The following steps prepare a canonical, padded Base64 string that you can paste into an n8n Set node, a Code node, or any fixed payload field. The file stays on your computer; the browser reads it through the File API and renders the encoded text.
- Open the File to Base64 Converter and confirm the page is in File → Base64 mode.
- Click the file picker and select a file no larger than 10 MB. The page shows the file's name and exact byte size so you can verify the source.
- Wait for the encoded text to render fully. The output contains only Base64 characters and the equals signs that pad the final group to four characters; there is no data-URL prefix, no MIME header, and no line wrapping.
- Copy the complete string. Any character dropped at the start or end will break the decoder on the other side, so use a single select-all-and-copy and verify the length is a multiple of four.
- In n8n, paste the string into the appropriate field: a Set node's string value, a Code node's constant, the HTTP Request node's body parameter, or a Notion / Airtable / Database text field.
- If the destination expects a data URL prefix (some CMSes do), prepend it explicitly: data:<mime-type>;base64,<copied string>. Do not let a node silently add line wrapping or trim the equals signs.
- Execute the workflow on a single test file and confirm the upstream node returns the same length and the same first and last 16 characters as the converter output. Any mismatch indicates the node has rewritten the string.
For size-sensitive payloads, remember the relationship between bytes and characters: every three source bytes become exactly four Base64 characters, so a 3,000,000-byte file produces a 3,000,000 × 4 ÷ 3 = 4,000,000-character string. Encoding therefore grows the on-the-wire size by roughly one third, and JSON-wrapping that string inside a payload adds further overhead from quote escaping.
Decode Base64 inside n8n with the reverse direction
The converter's second mode solves the opposite problem: you already have a Base64 string — from an n8n node's output, a webhook body, a log line, or a database column — and you want to confirm what bytes it represents.
- Switch the converter to Base64 → File.
- Strip any container the source string carries. If it begins with data:<mime>;base64,, remove everything up to and including the comma. If it contains carriage-return or line-feed characters from MIME wrapping, remove them so only the alphabet and padding remain.
- Paste the cleaned string. The decoder is strict by design: it rejects whitespace, missing padding, non-zero unused pad bits, and alternate non-canonical spellings by re-encoding the decoded bytes and comparing.
- Set an honest filename and an honest MIME type. These fields control only the download suggestion and the Blob media type; they do not inspect or rewrite the bytes. A PDF whose bytes you mislabel as image/png will still be a PDF, but the receiving application will try to interpret it as a PNG.
- Download the temporary file. The download exists only inside the browser tab as a revocable Blob URL, so save it immediately.
- Validate the recovered file with the application that originally produced it, or with a cryptographic hash when integrity matters. If the recovered file does not open, the upstream Base64 string is the bug, not the converter.
Limits, MIME type honesty, and security boundaries
The converter caps both the source and decoded file at 10,000,000 bytes. That bound protects the browser's memory because the original byte array, the Base64 string, and the rendered text can coexist during processing. Files larger than 10 MB belong in a streaming command-line workflow or an n8n node that processes data in chunks; trying to read them into a single buffer will exhaust the browser tab.
Two fields on the decode side deserve attention because they mislead downstream tools more often than the bytes themselves do. The filename controls only the suggested save name; the MIME type controls only the Blob media type that the browser attaches to the download. Neither field changes a single byte. If the upstream workflow stored a JPEG with the filename contract.pdf and the MIME type application/pdf, the recovered file is still a JPEG. Treat both fields as labels you choose honestly from the known format, not as something to guess from Base64 alone.
Base64 itself is encoding, not security. Anyone with the same string can recover the original bytes in a few milliseconds; the encoding does not encrypt, hash, sign, compress, scan, or sanitize the content. A Base64 string pasted into a log line, a support ticket, an analytics event, or a chat transcript is fully readable to anyone who sees it. Apply the same handling rules to an encoded payload inside n8n that you apply to the source file — and keep sensitive files off any device that has unknown browser extensions, clipboard managers, or downloaded-file handlers.
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.