Base64 encoding turns a binary image file into a single line of plain ASCII text so it can travel through JSON payloads, HTTP requests, and Code nodes inside n8n. To convert an image to base64 for an n8n workflow, open a local PNG, JPEG, GIF, or WebP file in a browser-based encoder such as the Image to Base64 Converter, choose between a plain Base64 string or a complete data URL, run the conversion, verify the detected format and decoded dimensions, and copy the text into the workflow. Several third-party services reached through n8n reject image payloads when the string contains line breaks, spaces, or a data URL prefix that does not match the actual file bytes, so the encoder must verify the container from its bytes rather than rely on the filename. The converter also enforces a 5 MiB input ceiling, a maximum output of 6,990,531 characters, and edge limits of 20,000 pixels with a total area of 40,000,000 pixels, all of which matter when a payload is being assembled inside an n8n Code node.
Why n8n Workflows Need Base64 Image Strings
n8n moves data between nodes as JSON or as binary items, and not every downstream service can accept a binary item. APIs for vision models, OCR engines such as CapSolver, ERP integrations like Odoo, and many webhook endpoints expect the image inline as a string property. The standard pattern in these integrations is: a trigger node, a Read Binary File or HTTP Request node that pulls the file, a Code or Function node that converts the bytes to a string, and finally an outgoing HTTP Request node whose JSON body contains that string.
When the file arrives at the receiving service, two conditions usually have to be true. The string must be a single uninterrupted line with no newline or whitespace characters, and the data URL prefix, when used, must match the file's actual container. A PNG renamed to photo.jpg still expects data:image/png;base64, not data:image/jpeg;base64, and many vision APIs will reject the call if the prefix disagrees with the decoded bytes.
Working this out in a Code node works for files already inside the workflow, but during development you often want a reference string you can paste into a Set node, a template literal, a JSON fixture, or a test webhook. A browser encoder that runs locally, never uploads the file, and proves the container from the bytes is the cleanest way to get that reference value before the runtime path is wired up.
Get a Clean Base64 String for n8n (Step-by-Step)
- Open the Image to Base64 Converter in the same browser tab where you will copy from, so the clipboard result is not blocked by another app.
- Click the file input and choose one PNG, JPEG, GIF, or WebP file that you plan to send through n8n. The tool reads up to 5,242,880 bytes; one byte over is rejected before the body is read.
- Pick the output mode. Choose plain Base64 if your downstream service expects a raw string, or data URL if it expects a complete data:image/...;base64,... value with prefix.
- Run the conversion and wait for the preview, detected byte format, decoded dimensions, and file size to appear.
- Check the detected format string. It should match the file's real container. A PNG renamed to .jpg still reports image/png, which is the value that will appear in the data URL prefix.
- Click the copy button. The result text is now in your clipboard without any wrapping, newlines, or extra spaces.
- Paste the string into your n8n Set node field, Code node variable, or JSON fixture.
If you switch files or output modes after a successful conversion, the previous preview, output, error, and copy status are cleared automatically. Copy again after every change so you never paste a stale value. If the clipboard write is denied, the visible text remains selectable and you can copy it manually with a keyboard shortcut.
Pasting the Output Into an n8n Code Node or Set Node
Inside n8n, the converted string usually lands in one of three places: a Set node as the value of a string property such as image_base64, a Code node expression that wraps it into a JSON body, or a static workflow value used to test the integration before swapping in a live binary stream. The reference string produced by the browser converter lets you confirm that your downstream call works before you wire up the runtime encoding path.
When you move from a tested reference string to runtime conversion inside n8n itself, add a Code node that reads the binary item and encodes the buffer using Buffer.from(data).toString('base64'). A common pattern looks like this:
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 } };
Use the value produced by the converter to confirm that your HTTP Request node sends a payload the receiving service accepts. If the service rejects the call, the first thing to check is the MIME string. Many services validate that the data URL prefix matches the container, and the converter's detection of the verified bytes is the easiest way to settle that disagreement. For the reverse direction, where an n8n workflow receives a base64 string and must turn it back into an image file, the Decode a Base64 Image from an n8n Workflow guide covers the matching Code node pattern.
Format and Size Limits That Affect n8n Payloads
Every container check happens from the actual file bytes. The filename, the file picker filter, and the operating system's reported MIME type never decide the format. This is the property you want when you paste a value into an n8n payload, because the data URL prefix is guaranteed to match the bytes, not the file's name.
| Container | Detection signal in file bytes | Resulting data URL prefix |
|---|---|---|
| PNG | Eight-byte signature, valid first IHDR chunk, terminal IEND boundary | data:image/png;base64, |
| JPEG | SOI marker, valid following marker, terminal EOI marker | data:image/jpeg;base64, |
| GIF | GIF87a or GIF89a header, logical screen descriptor, terminal trailer | data:image/gif;base64, |
| WebP | RIFF length that matches the file, WEBP FourCC, valid VP8, VP8L, or VP8X first chunk | data:image/webp;base64, |
After detection, the converter decodes the file in the browser through createImageBitmap with an HTMLImageElement fallback. A corrupt payload that only mimics a header still cannot produce output unless the browser reports positive dimensions, which means a misleading prefix or a stub signature is rejected before any text is generated.
| Limit | Exact value | Why it matters for n8n |
|---|---|---|
| Maximum input file size | 5,242,880 bytes (5 MiB) | Larger files are rejected before the body is read |
| Maximum Base64 output length | 6,990,508 characters | One byte over the input cap pushes output over this limit |
| Maximum data URL output length | 6,990,531 characters | Includes the longest supported data URL prefix |
| Maximum edge after decoding | 20,000 pixels per side | Either edge above this is rejected |
| Maximum total decoded pixels | 40,000,000 | Above this is rejected even when edges fit |
The output cap is a direct consequence of the input cap and the RFC 4648 alphabet. Per the standard, every three input bytes map to four output characters using uppercase letters, lowercase letters, digits, plus, and slash. When the last group has only one or two bytes, the encoder writes one or two terminal equals signs so the decoder can recover the original length. Applying that to the largest accepted input: 5,242,880 bytes divided by three gives 1,747,626 full groups with a remainder of 2, producing 1,747,627 groups of four characters for 6,990,508 characters of plain Base64. Adding the longest data URL prefix yields the 6,990,531 character ceiling the converter enforces. You can verify the grouping and padding cases directly against RFC 4648.
Base64 also grows the data by about one third before any prefix, so a 1 MiB image becomes roughly 1.33 MiB of text inside an n8n JSON body. A multi-megabyte image is rarely a good fit for a JSON property; when the payload is just for testing or fixtures, a small sample is usually enough.
Related Conversions Before You Encode
The Image to Base64 Converter preserves the original validated file bytes inside the Base64 payload. It does not draw onto canvas, resize, recompress, recolor, flatten transparency, remove metadata, repair damage, or optimize file size, and it does not select a frame from an animated GIF. Animated GIF and WebP bytes stay animated in the payload when the receiving consumer supports them. If you need a smaller file before encoding, handle that with a dedicated tool first and encode the result.
- Use the Image Compressor to shrink a JPG, PNG, or WebP in your browser before encoding.
- Use the Image Resizer if you need specific pixel dimensions; the encoder does not resize.
- For the reverse workflow in n8n, see the Decode a Base64 Image from an n8n Workflow guide.
The converter only accepts these four containers. SVG, AVIF, HEIC, BMP, TIFF, PDF, and arbitrary text are outside scope even if the browser or a file extension calls them images. Convert those to PNG, JPEG, GIF, or WebP first if you need them as base64.
For runtime encoding inside n8n, use a Code node against $input.item.binary so each workflow run handles whatever file arrives. For producing a static string you will paste into a workflow, the browser converter is the safer choice because it verifies the container and the decoded pixels before giving you any text to copy. Treat an unknown image as untrusted content even though it stays local: successful browser decoding confirms technical readability, not authorship, accessibility, copyright status, or freedom from concealed data.