I would like to create a form which receives base64 string (image) from previous node and the image is to be displayed on the form. Tried multiple approaches (custom html, iframe etc) but still unable to get it right. The outcome is a broken image icon on the form.
FYI, I have tried the solution provided by this thread but unfortunately it’s not working for me now.
Appreciate if anyone can provide any idea on how to achieve the objective above. Thanks!
I’d first make sure the value includes the full data URL prefix, not only the raw base64 string.
Can you share one sample of the exact value being passed into the Form node for the image field?
The Form node’s text fields don’t render HTML - you need to use an “HTML” type field (if on n8n 1.x with Form Trigger) or pass the image as a data URI in an HTML block. The working approach: in the Form node, add a field of type “HTML” and set its value to <img src="data:image/png;base64,{{ $json.imageBase64 }}" style="max-width:100%">. Make sure imageBase64 is just the raw base64 string without any prefix - the prefix goes in the src attribute as shown above. If your base64 already includes the data:image/...;base64, prefix, use <img src="{{ $json.imageBase64 }}" ...> directly.
@nguyenthieutoan Thanks for your reply. I’ve tried your suggestion before and it doesn’t work. I am using a wait node (version 1.1) with “On Form Submitted”.
Have you tried on your end if it works for you? If yes, appreciate if you can share your setup.
The Form Wait node (v1.1) has a known limitation - the “Custom HTML” element type renders fine in the Form Trigger’s built-in form, but in the Wait node’s continuation form the HTML can get sanitized differently depending on the version. A few things to check: first, verify the $json.data value actually starts as a clean base64 string with no whitespace or line breaks - large base64 strings from binary conversion sometimes have newlines that break the data URI. In your Code node, run $json.data.replace(/\s/g, '') to strip whitespace before passing to the form. Second, try wrapping in a div: <div><img src="data:image/png;base64,{{ $json.data.replace(/\s/g, '') }}"></div>. If it still breaks, this may be a sanitization issue in the Wait node’s v1.1 rendering - worth checking if the same setup works with a Form Trigger node directly (without the Wait).
@WilsonT3D
can you share the value of the data field?
if we can open it directly in the browser as data:image/png;base64,<base64_here>, but it keeps breaking in the wait node, it’s easier to assume the problem is in the HTML rendering.
I did follow the exact suggested format, that is, data:image/png;base64,<base64_here>, but the wait node still fails to render the image properly. In fact, I’ve also tried the same in a browser and it works fine (the image is rendered properly). Hence, my guess is there might be an issue with the wait node rendering an image.
Hopefully there is someone from n8n support team can see this thread and look into the issue. I can provide the steps to reproduce the issue if required.
Thanks for the suggestions. However, it still fails despite trying all the suggested formats and also in Form node.
I believe there might be an issue with the node on rendering an image (decoding a base64 string properly). Hopefully someone from n8n support team can see this thread and look into the issue. I can provide the steps to reproduce the issue if required.
@WilsonT3D if you’ve confirmed the data URI renders correctly in the browser but fails in the Form Wait node’s custom HTML, this is very likely an HTML sanitization issue specific to that node - the Wait node strips certain HTML attributes or inline styles when rendering. One thing worth trying before sharing the workflow: instead of embedding the image directly in custom HTML, use a workaround where you write the base64 image to a temporary URL via the n8n binary data and reference it by URL instead. But do share the workflow with @barn4k - if it’s reproducible, this is worth filing as a bug on GitHub so the team can look at it properly.
Thanks for the response. Here’s a simple test where I try to render an image on both form nodes. It appears that the image is not able to render properly with a broken image icon. The trigger form node (version 2.5) has the base64 string hardcoded into the image element tag in Form description. The Next Form page node (version 2.5) takes the base64 string from the Set node as input to the image element tag. Both show the same result.
If you try to save that html and view it with browser, you should be able to see n8n logo.
@WilsonT3D thanks for the detailed test - that confirms it’s a sanitization bug in the Form node itself, not a data issue on your end. Both the trigger and the next form page node stripping the src attribute in the same way pretty much rules out everything else.
At this point the best move is to file a GitHub issue with that minimal reproduction workflow attached - the team can see exactly which sanitizer is doing this and fix it at the source. Link: Issues · n8n-io/n8n · GitHub
try with (remove the spaces). Custom HTML accepts and the src attribute, but the HTML is sanitized and only http:// and https:// URLs are allowed. According to the documentation, this is standard functionality.
Anything beyond that is an enhancement.
allowed html tags and attributes and allowed protocols
Thanks for the info. I can see that the allowed attributes for Image tag in Form node are as follow (in the document).
Images (<img>): src, alt, width, height
I have removed the style attribute in my original html but it still gives me the same issue, that is, a broken image icon. Here’s my html for your reference:
@WilsonT3D
n8n uses a sanitization library (probably DOMPurify or similar) that blocks the data: scheme in src attributes for this exact reason — an attacker could inject JavaScript disguised as an image.
I recommend hosting your image somewhere accessible via URL.
@WilsonT3D Can you try swapping out the base64 encoded image and using a URL as the docs page and the message from @tamy.santos suggests? This will then result in it working.
I have marked their answer as the solution as it looks to cover everything and links to the relevant documentation.
(remove the spaces). Custom HTML accepts 