I’m running into a tricky issue with a multi-file upload workflow and would really appreciate some guidance
Setup
Users can upload multiple files via an On Form Submission node. The uploads can contain a mix of:
PDFs
PNGs / images
I then route them using an IF node:
PDF → PDF processing branch
PNG → image processing branch
Problem
When multiple files are uploaded at once, the IF node behaves incorrectly.
It seems to only evaluate the first file type and then applies that logic to all following items in the execution.
Example:
File 1 = PDF → goes into PDF branch
File 2 = PNG → still gets routed into PDF branch (incorrect)
So instead of evaluating each file individually, it looks like the condition is “carried over” or reused.
What it looks like internally
It also seems like n8n is “remembering” previous values during the loop/execution. Over time, both PDF and PNG references accumulate, and the IF node can no longer reliably distinguish the current file type.
Questions
What is the correct way to ensure that the IF node evaluates each file independently per item, especially in multi-file uploads?
Is there any way to clear internal state / loop memory / accumulated items inside a workflow step?
For example:
resetting loop context
clearing previous binary references
preventing previously processed file types from influencing the next item
It feels like something is being stored across iterations, which eventually breaks the routing logic.
Would really appreciate any best practice or recommended pattern for handling mixed file types in batch uploads
I’ve seen this pattern before—it’s usually not the IF node itself, but how binary data flows through the loop. The issue is that n8n doesn’t automatically clear binary references between iterations, so the node context can ‘carry over’ the previous file type.
Here’s the solution: Use a Set Node before the IF to explicitly clean up the file path / type. Right before your IF node, add a Set node that extracts only the current filename or MIME type as a fresh value:
Set: {{ $json.file_name }} (extract current file name)
Set: {{ $json.mimetype }} (extract current MIME type)
This resets the evaluation context per item. Then your IF node can evaluate fresh.
Alternatively, if you’re routing based on binary properties, try wrapping the binary field in a custom expression that forces a re-evaluation per iteration. Avoid referencing accumulated binary arrays across loop steps—reference only the current item’s binary data: {{ $json.binary.file_data[0] }} instead of {{ $json.binary.file_data }}.
@Leon22 the IF node is fine, problem is the Form node outputs all uploaded files as multiple binary keys on a single item, so the IF only runs once. split the binaries into separate items first with a Code node, then your IF evaluates each file on its own.
wire your Form Submission node into Split Files, it breaks each binary into its own item with the mimeType pulled out clean so no “carried over” state between files.
I’ve already implemented it this way, but I’m still running into the same issue as before.
It seems like the node is not evaluating the current item/file, but instead checking whether any of the previously uploaded filenames contain “pdf”. Because of that, it incorrectly treats all subsequent files as PDFs, even when they are not.
So instead of checking the current file’s type, it looks like it’s referencing past values from earlier items in the execution.
As you can see, there is one PDF and one PNG file, but the second file (PNG) is also being detected as a PDF.
This is incorrect, since only the first file is actually a PDF — the second one should be routed through the image/PNG branch, but it is still treated as a PDF instead.
When I try using the Split Out node, I run into a similar issue.
The output still keeps both files bundled together, and instead of properly separating them, it just duplicates the same combined result twice.
At this point it feels like the workflow simply isn’t handling the individual files correctly anymore, no matter which splitting or routing approach I try.
