Inconsistency in the Read Binary Files and Webhook Trigger nodes for binary data output

Describe the issue/error/question

I started testing my workflows with local files: read them using the Read Binary Files node and process them down the line. It was convenient as the binary property name was always consistent (data).

Now, I’d like to get the input from a Webhook trigger node. However, when passing multiple files via a POST request, they get a number appended, making it inconsistent with the Read Binary Files node.

Looking at that made me wonder why they had different behaviors? Having the same binary property name is what allows easy workflow processes…

Right now, a binary properly name can be set in the Webhook trigger node, but it is used as a prefix. I’d suggest a way to override the data property name to keep it consistent.

Is there a different way to make the data property name consistent?

Information on your n8n setup

  • n8n version: 0.217.2
  • Database you’re using (default: SQLite): SQLite
  • Running n8n with the execution process [own(default), main]: own
  • Running n8n via [Docker, npm,, desktop app]: Docker

Hey @Nurgak,

The big difference there is the read binary files node outputs one item for each file so it can use the same field name. In the webhook node it is one item that happens to have 2 files so they are labelled to keep them unique and prevent overwriting the binary data.

What you would need to do is split out the binary data into multiple items using a code node or modify your workflow so it can work with multiple binary items in the same item.

Hi @Jon ,

I understand the difference and why it is done this way.

I think the Code node is the most appropriate for my use, thank you for this tip.

1 Like

Hey @Nurgak,

No problem at all, I have also popped a vote on an internal feature request to have support for managing binary data in the Item Lists node (or something similar) to make this easier.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.