An n8n workflow can hand you a perfectly valid image as nothing but a Base64 string, and the only way to confirm what it really is — a PNG, JPEG, GIF, or WebP — is to decode those bytes back into a file you can open. The Base64 to Image Converter takes that string, parses it as RFC 4648 Base64 or as an RFC 2397 data URL, then validates the decoded bytes against the real file signature before producing a preview and a download. Because the conversion runs entirely inside the browser tab, no payload from your workflow is sent to a server, which makes it safe to drop in customer avatars, signed document thumbnails, or webhook payloads that may contain sensitive material. The result is predictable: the file extension is chosen from the byte structure the converter actually decodes, not from the MIME label the producer claimed.
Why n8n workflows produce Base64 image strings
n8n is a fair-code workflow automation platform that connects APIs, databases, and SaaS services through nodes. When one of those nodes receives image data, the upstream system often serializes the picture as a Base64 string because Base64 travels cleanly inside JSON, fits inside a single text column, and survives any text-only transport such as email bodies or webhook POST forms. Several n8n situations produce Base64 on a regular basis:
- HTTP Request nodes that call avatar endpoints, document scanning APIs, OCR engines, or e-commerce product services whose JSON response carries a field such as image_base64, data, or base64Image.
- Webhook nodes receiving form submissions or third-party callbacks where the sender embedded the picture inline rather than uploading it as multipart.
- IMAP Email nodes pulling message bodies that contain inline images, where the raw MIME part exposes the picture body as Base64 alongside its cid: reference.
- Postgres, MySQL, or MongoDB nodes returning columns that the source application stored as Base64 to keep BLOBs out of binary fields.
- Code nodes assembling an image payload from several fields before passing it to another service, for example when a downstream HTTP node only accepts JSON.
In every case the picture arrives in n8n as text, and the only way to confirm what is actually inside that text is to decode the bytes and let a real image decoder report back.
What the converter checks before it shows a preview
The converter treats Base64 as a byte encoding rather than as a trustworthy file label. The input is parsed as either strict RFC 4648 Base64 or as an RFC 2397 data URL containing a comma separator and exactly one terminal ;base64 token. Once the bytes are decoded, the tool runs a structural preflight against the four supported container formats:
| Image format | Structural preflight |
|---|---|
| PNG | Complete eight-byte signature, a first IHDR chunk with the mandated length, and a terminal IEND boundary. |
| JPEG | Start-of-image marker followed by a valid marker, ending with a terminal end-of-image sequence. |
| GIF | Header of GIF87a or GIF89a, enough bytes for the logical screen descriptor, and the stream trailer byte. |
| WebP | RIFF and WEBP markers, an exact RIFF byte count, and a bounded VP8, VP8L, or VP8X first chunk. |
The declared MIME type from a data URL is never used to choose the output. If a producer writes data:image/jpeg;base64,... but the decoded bytes start with the PNG signature, the converter shows the declared MIME as ignored, lets the PNG structure win, validates the bytes through the browser, and hands the download a .png extension. This avoids creating a misleading file whose extension was copied from untrusted metadata. After structural preflight, the resulting Blob must still decode through the browser's image decoder and report real positive dimensions before any preview or download is published, so a malformed container that happens to pass preflight still fails rather than appearing as a successful conversion.
How to decode a Base64 image from n8n
- Copy the Base64 string from the n8n node. In an HTTP Request node, open the output panel, expand the JSON, and copy the value of the field that holds the image (commonly image, base64, data, or image_base64). If the value begins with data:image/... it is already a data URL and can be copied as-is.
- Open the converter and paste the string. The tool accepts either plain RFC 4648 Base64 or a data URL that includes the ;base64 marker. Do not paste with surrounding whitespace, line breaks, or tabs — the validator will reject them.
- Click Convert to image. The decoder validates the alphabet, the four-character grouping, the terminal padding, and the unused pad bits, then runs the signature preflight for PNG, JPEG, GIF, or WebP.
- Confirm the detected format, dimensions, and byte size. The summary next to the preview shows the format the converter actually decoded, the width and height the browser reported, and the decoded byte count. If these numbers look wrong, the producer's label was wrong and the real structure is being shown.
- Download the file with the chosen extension. The download contains the original decoded bytes — no canvas redraw, no recompression, and no metadata stripping — so an animated GIF keeps its frames and a PNG keeps its alpha channel.
Working with different n8n node outputs
n8n outputs vary in shape, and a few patterns come up often enough to be worth naming before you paste into the converter.
HTTP Request with a JSON Base64 field. Many image APIs return a JSON object such as { "image_base64": "iVBORw0K..." }. Set the HTTP Request node's response format to JSON, then add a Set or Edit Fields node that promotes the Base64 field to a top-level item property. Paste that string directly. If the API instead returns a full data URL field such as data:image/png;base64,iVBORw0K..., copy the entire data URL including the prefix.
Webhook payloads with form data. Webhooks arriving as application/x-www-form-urlencoded sometimes carry the picture as a Base64 string inside a hidden form field. n8n parses that into a normal string property, and the converter treats it the same as any plain Base64 payload.
IMAP Email inline images. IMAP nodes expose message parts as attachments or text. When an email signature uses inline images, the raw MIME part contains the Base64 body of the picture. Most n8n users extract this with a Code node that strips the MIME headers and concatenates the body chunks before passing the result to the converter.
Database columns stored as Base64. Postgres BYTEA columns are typically surfaced as Base64 by n8n's database nodes, as are VARCHAR columns used to store Base64 for compactness. Use the column value directly. Older MySQL setups sometimes return a string with line wrapping every 76 characters — that wrapping will trigger a whitespace error, and you should either reformat it in a Code node with .replace(/\s+/g, '') or normalize the column at the source before pulling it into n8n.
Code node assembly. If you build the Base64 payload yourself in a Code node before forwarding it to another service, the string you produce must be canonical: standard alphabet, four-character grouping, padding only at the end, and zero unused pad bits. The converter's strict validation surfaces a clear error the moment your Code node generates something the receiver cannot decode, which makes the converter a useful spot-check alongside any in-workflow assertion.
Strict input rules and size limits
Base64 validation inside the converter is intentionally strict and deterministic so that the result reflects the actual bytes, not a quietly rewritten copy. The input must use the standard RFC 4648 alphabet with plus and slash, have a length divisible by four, place one or two padding characters only at the end when required, and have zero unused pad bits. Whitespace is not removed. Line-wrapped Base64, embedded spaces or tabs, URL-safe minus and underscore characters, missing padding, surplus padding, and non-zero pad bits all produce an explicit error rather than a silent fix-up. Data URLs must include a comma separator and exactly one terminal ;base64 token, with media types in type/subtype syntax and any pre-base64 parameters in name=value syntax. Duplicate base64 tokens, parameters after the base64 token, percent-encoded payloads, and non-Base64 data URLs are outside scope.
To keep the browser tab stable while decoding large API responses, the converter enforces a small set of hard limits:
| Boundary | Exact value | What it protects |
|---|---|---|
| Input characters | 8,000,000 UTF-16 code units | The length of the string you can paste |
| Decoded bytes | 5 MiB (5 × 1024 × 1024 = 5,242,880 bytes) | The size of the resulting file |
| Image edge | 20,000 pixels | The maximum width or height of the decoded image |
| Total area | 40,000,000 pixels | The maximum width × height of the decoded image |
The decoder computes the expected output size before allocating the byte array, accepts the exact boundary, and rejects one byte beyond it. It never slices, shortens, samples, or partially decodes oversized input. After browser decoding, width and height must each be no more than 20,000 pixels and their product must be no more than 40,000,000 pixels. These decoded-dimension limits matter because a compact Base64 payload can expand into a very large pixel surface and exhaust browser memory.
What to do after you have the image file
Conversion preserves the decoded bytes. The download is not drawn onto canvas, resized, recompressed, recolored, or stripped of metadata, so a downloaded GIF can retain its animation and a PNG can retain alpha plus any embedded chunks present in the source. That also means the tool cannot repair a corrupt file, optimize file size, change format, or guarantee that every other application accepts the result. If the preview succeeds and you need a smaller file, download it first and pass it to the Image Compressor. If you need different dimensions, use the Image Resizer after the download. If you need to send the picture back into n8n as Base64, convert the resulting file with the Image to Base64 Converter. This focused separation keeps the n8n-to-file workflow predictable while preserving the original image bytes exactly.