n8n · troubleshooting · reproduced on n8n 2.41.3, 30 September 2026

n8n 413 Request Entity Too Large

A “413 Request Entity Too Large” in front of n8n comes from one of two places, and they need different settings. If nginx sits in front of n8n, its client_max_body_size defaults to 1 MB. n8n’s own limit is N8N_PAYLOAD_SIZE_MAX, 16 MiB by default. There is a trap: when n8n’s own limit is hit on a webhook, the caller does not get a 413 at all. On n8n 2.41.3 it got an HTTP 500 saying “There was a problem executing the workflow”, and the 413 only appeared in the server log.

Which layer refused the request

LayerWhat the caller seesLimitFix
nginx in front of n8nAn HTML page titled “413 Request Entity Too Large”, usually with “nginx” at the bottom. n8n never sees the request and logs nothing.client_max_body_size, default 1mRaise client_max_body_size in the server or location block that proxies to n8n
n8n REST API (editor, /rest/…)HTTP 413 with the body <pre>Payload Too Large</pre>N8N_PAYLOAD_SIZE_MAX, default 16 (MiB)Set N8N_PAYLOAD_SIZE_MAX higher and restart n8n
n8n webhook (/webhook/…)HTTP 500 {"code":0,"message":"There was a problem executing the workflow"}. The log says PayloadTooLargeError: request entity too largeN8N_PAYLOAD_SIZE_MAX, default 16 (MiB)Same variable, and restart. For big files, send multipart form-data instead: N8N_FORMDATA_FILE_SIZE_MAX, default 200 (MiB)

The two n8n rows were produced on n8n 2.41.3 on 30 September 2026, installed from npm on Node 24 and started with NODE_ENV=production. We sent the same 17 MiB JSON body to a Webhook node and to /rest/login. The nginx row comes from the nginx documentation, which states the default and says a larger body returns “413 (Request Entity Too Large)”. We did not run nginx for this page.

What n8n actually did with a 17 MiB body

A Webhook node set to respond immediately, and a 17 MiB JSON body, one mebibyte over the default:

$ curl -s -w ' %{http_code}' -H 'Content-Type: application/json' \
    --data-binary @big.json http://localhost:5678/webhook/big-body
{"code":0,"message":"There was a problem executing the workflow"} 500

Nothing on the caller’s side mentions size. The n8n log does:

PayloadTooLargeError: request entity too large
    at readStream (…/node_modules/raw-body/index.js:163:17)
    …
    at parseRequestBody (…/n8n/src/webhooks/webhook-helpers.ts:1474:17)
Error in handling webhook request POST /webhook/big-body: There was a problem executing the workflow

The same body sent to the REST API (the path the editor uses) got a proper 413 with a one-line HTML body, <pre>Payload Too Large</pre>. A normal-sized request to the same webhook returned {"message":"Workflow was started"} with 200, so the workflow itself was fine all along.

The fixes

Raise n8n’s limit: N8N_PAYLOAD_SIZE_MAX

The value is in MiB, and n8n only reads it at startup. The docs say “The n8n instance needs to be restarted to apply the new setting.” In Docker, recreate the container so the new variable reaches it:

# docker run
-e N8N_PAYLOAD_SIZE_MAX=32

# docker compose (environment: section of the n8n service)
- N8N_PAYLOAD_SIZE_MAX=32

With N8N_PAYLOAD_SIZE_MAX=32, the 17 MiB request that had failed returned {"message":"Workflow was started"} with HTTP 200, and no PayloadTooLargeError appeared in the log.

Raise the proxy’s limit: client_max_body_size

nginx rejects anything over its limit before n8n gets it, so raising n8n alone changes nothing. Per the nginx docs, the directive is client_max_body_size size; with default 1m, valid in http, server and location:

server {
    server_name n8n.example.com;
    client_max_body_size 32m;   # match or exceed N8N_PAYLOAD_SIZE_MAX
    location / {
        proxy_pass http://127.0.0.1:5678;
        # … your existing proxy headers
    }
}

Then nginx -t and reload. The nginx docs add that “browsers cannot correctly display this error”. If the editor shows only a generic failure when saving a large workflow, check the proxy’s error log as well as n8n’s.

Send big files as form-data instead of JSON

If the large part is a file, have the sender post it as multipart form-data. File parts in form-data webhook payloads fall under N8N_FORMDATA_FILE_SIZE_MAX, 200 MiB by default per the docs, not the 16 MiB JSON limit, and the Webhook node hands them to the workflow as binary data. A file base64-encoded inside JSON is about a third larger than the file and counts against the 16 MiB.

$ curl -s -w ' %{http_code}' -F "upload=@file20.bin"     http://localhost:5678/webhook/big-body
{"message":"Workflow was started"} 200

A 20 MiB file, sent as form-data to the same webhook with N8N_PAYLOAD_SIZE_MAX back at its default of 16. It went through, and n8n wrote the file under .n8n/storage/workflows/…/executions/…/binary_data/. The 17 MiB JSON body had failed on the same instance.

Related

If the webhook answers “The requested webhook … is not registered” instead, the size is not the problem. See webhook not registered. If callers are hitting a URL with localhost in it, see why n8n shows a localhost webhook URL. If n8n’s log behind the same proxy also shows a ValidationError about X-Forwarded-For, see the trust proxy error.

Sources and last verified

Reproduced on n8n 2.41.3 on 30 September 2026; every doc quote was read on the same day. If n8n’s docs and this page disagree, n8n wins. Write to support@flowtemplates.app and we will re-verify.

Frequently asked questions

What is n8n’s default maximum payload size?

16 MiB. The n8n docs list N8N_PAYLOAD_SIZE_MAX as a Number with default 16, “The maximum payload size in MiB,” and note that the instance needs to be restarted to apply a new value. In the 2.41.3 source the same number is passed to the body parser as the request-body limit.

Why does my n8n webhook return 500 instead of 413 for a large body?

Because the webhook handler catches the body-parser error and reports a failed execution. On n8n 2.41.3 a 17 MiB JSON POST to a Webhook node returned HTTP 500 with {"code":0,"message":"There was a problem executing the workflow"}. Only the server log carried the real reason: “PayloadTooLargeError: request entity too large”, followed by “Error in handling webhook request POST /webhook/…”. If a caller reports 500s on large payloads only, check the log for that line before debugging the workflow.

I raised N8N_PAYLOAD_SIZE_MAX and still get 413. Why?

Almost always because the 413 now comes from a proxy in front of n8n, not from n8n. nginx’s client_max_body_size defaults to 1m, so with nginx in the path anything over 1 MB is refused before n8n sees it, whatever n8n is set to. The nginx docs say the directive can be set in the http, server or location context, and that 0 disables the check. Raise it there as well, then reload nginx.

Does N8N_PAYLOAD_SIZE_MAX limit file uploads to a webhook?

Files sent as multipart form-data have their own limit. The docs list N8N_FORMDATA_FILE_SIZE_MAX, default 200, as the “Max payload size for files in form-data webhook payloads in MiB”. In the 2.41.3 source the webhook’s form-data parser is built from that value. If a client sends a large file as a base64 string inside JSON instead, that JSON body counts against the 16 MiB N8N_PAYLOAD_SIZE_MAX.

What value should I set?

The smallest that fits your real traffic, with some headroom. n8n’s docs warn that increasing the payload size may impact performance and that your infrastructure has to handle larger payloads. A webhook body is held in memory while the workflow runs, so a limit ten times larger than anything you receive only adds risk. On our test instance N8N_PAYLOAD_SIZE_MAX=32 was enough for the 17 MiB body that had failed.