anyone has this issue, when i click download in the binary file, browser return this error. Received this file via webhook formData
Hi @imkev8888 Welcome!
That is strange, although have you tried getting the file straight from the n8n form? As sometimes i have also seen webhook’s post method not getting the file properly.
Try testing from the n8n form directly instead of webhook formData — sometimes the data encoding differs. If that works, check how your webhook is transforming the file data.
I need to use a webhook to listen for new images. This is strange, because the issue only started in the last two days — the workflow was working perfectly before. Now I’ve tested that a binary file can’t be accessed in one workflow, which is very odd. I wonder whether an n8n workspace or server update caused the issue. See the screenshot: the same expression, one run fails and one passes
That intermittent pattern + the timing (only started 2 days ago) strongly suggests a recent n8n Cloud update changed something in binary data handling for webhooks. If identical runs produce different results, that’s almost certainly a platform-level regression rather than something in your workflow logic.
I’d open a support ticket with n8n Cloud and include those screenshots — they’re solid evidence of inconsistent behavior across runs. In the meantime, try adding a Move Binary Data node right after the webhook to normalize the binary property before accessing it downstream.
@imkev8888
So I’d test this first: Set the field to file_0 directly, or use an expression like {{ Object.keys($binary)[0] }}
If the Download button in the execution view still fails even after switching the field to file_0, then I’d start suspecting a Cloud-side issue or a temporary platform regression. But based on the screenshots alone, I would first rule out the field reference, because that part looks incorrect.
yeah the field reference is the simpler thing to rule out first. if file_0 works but the expression still fails, thats a key naming issue not a platform regression. support ticket only if both paths fail
it fails from the start, couldnt download file from first node
if it’s failing at the very first node then field references are out of the picture — that’s pointing straight at a platform issue. open a support ticket with n8n Cloud, include those screenshots and the execution IDs from the failing runs. they’ll need to check server-side what changed in the last few days.
