"413 Request Entity Too Large": Increase Payload Limits (FAQ)

The error "413 Request Entity Too Large" usually appears in n8n when a webhook receives a larger file, such as a PDF, an image, or an extensive JSON payload, and the configured upper limit is exceeded. By default, n8n sets a limit of 16 MiB per payload, which can be raised via a single environment variable. In many cases, however, the actual bottleneck is not n8n itself but a layer in front of it, the reverse proxy. As of: July 2026.

This FAQ article shows which variable you need to set, how to distinguish between an n8n-internal limit and a proxy limit, and what to watch out for when raising the limit so that your instance stays stable.

What does the 413 error in n8n actually mean?

The HTTP status code 413 signals that the server is rejecting the incoming request because its payload is larger than allowed. In n8n, this limit mainly applies in two places:

• Webhook triggers, which receive files or large JSON bodies from outside, for example from forms, chat widgets, or external systems.
• Internal processing of large datasets within a workflow, when a node returns a result that exceeds the configured upper limit.

According to the n8n documentation on the endpoint environment variables, the default limit is 16 MiB. This is sufficient for most automations involving text data, small images, or normal API responses. However, once PDFs, high-resolution images, or multi-page documents pass through a workflow, the limit is quickly reached.

The key environment variable: N8N_PAYLOAD_SIZE_MAX

The decisive lever is called N8N_PAYLOAD_SIZE_MAX. It defines the maximum payload size in MiB and, according to official documentation, is set to 16 by default. To raise the limit, set the variable to a higher value, for example:

• `N8N_PAYLOAD_SIZE_MAX=64` for 64 MiB
• `N8N_PAYLOAD_SIZE_MAX=128` for 128 MiB

In a Docker installation, add the variable to your Compose file or the Docker run environment; in an npm installation, set it before starting, for example via `N8N_PAYLOAD_SIZE_MAX=64 n8n`. Important: after setting the variable, the n8n instance must be restarted for the change to take effect. Simply reloading the web interface is not enough.

For form uploads with files, there is also a separate variable N8N_FORMDATA_FILE_SIZE_MAX, which according to the same documentation defaults to 200 MiB and specifically governs the file size within form-data payloads, for example when a webhook receives file uploads from a form. So if you want to specifically allow larger file attachments, check both variables and align them with each other.

Why setting the variable sometimes isn't enough

A common pitfall from the n8n community: the variable is set correctly, but the error persists anyway. The reason is almost always an upstream instance that intercepts the request before it even reaches n8n. A community thread on 413 errors when uploading PDFs via webhookconfirms this pattern: it was not n8n itself but the upstream Nginx configuration that limited the request, even though the n8n-internal limit was significantly higher.

Therefore, check in order:

• Nginx as a reverse proxy:The `client_max_body_size` directive limits the body size independently of n8n. A value like `client_max_body_size 100M;` in the server or location configuration must match the n8n limit or be more generous.
• Traefik or Cloudflare Tunnel:These also have their own upper limits for request bodies that must be configured separately.
• Docker setups with an upstream load balancer:Cloud load balancers often bring their own, sometimes lower, default limits that apply independently of n8n.

Only once all layers, both the proxy and n8n itself, are set to a sufficiently high limit does the 413 error reliably disappear. In an older, now resolved case from the n8n community forum, the cause was even a bug in an earlier n8n version that blocked payloads starting at just 100 KB, regardless of the configured limit. Updating to a current n8n version reliably fixes such legacy issues too.

Set limits deliberately instead of maximizing across the board

Before reflexively setting the limit to a very high value, it's worth taking a brief look at the downside. The documentation explicitly points out that a higher payload limit requires more memory and more processing power and can affect the performance of the entire instance. Anyone running many parallel workflows in production should therefore adjust the limit to actual needs, not to what is theoretically possible.

A few practical guidelines:

• Set the value as high as necessary, not as high as possible. For PDF processing, 32 to 64 MiB is often enough; video data may require more.
• Monitor your instance's memory usage after the adjustment, especially with self-hosting on limited resources.
• Where possible, combine large payload limits with the filesystem mode for binary data, controlled via N8N_DEFAULT_BINARY_DATA_MODE, instead of keeping large files in memory. According to the documentation, n8n holds binary data in memory by default in "default" mode, which quickly leads to memory pressure with large payloads.

If you run an n8n instance in production and don't want to research every infrastructure topic yourself, you can outsource configuration, monitoring, and troubleshooting through n8n consulting and support by NordFlux. You retain control over your workflows and data while the technical fine-tuning happens in the background.

Frequently asked questions

Which environment variable raises the payload limit in n8n?

The variable N8N_PAYLOAD_SIZE_MAX sets the maximum payload size in MiB and, according to n8n documentation, defaults to 16. You raise it by setting the variable to a higher value and then restarting the instance.

Why do I still get a 413 error despite raising N8N_PAYLOAD_SIZE_MAX?

In most of these cases, there is another limit in front of n8n, for example in an Nginx configuration with `client_max_body_size`, in Traefik, or in an upstream load balancer. n8n itself may already allow the request, but the proxy blocks it beforehand. Therefore, check each layer of the infrastructure individually.

What is the difference between N8N_PAYLOAD_SIZE_MAX and N8N_FORMDATA_FILE_SIZE_MAX?

N8N_PAYLOAD_SIZE_MAX limits the total size of a request to n8n. N8N_FORMDATA_FILE_SIZE_MAX specifically governs the maximum file size within form-data payloads, for example for file uploads via a webhook form, and defaults to 200 MiB. For pure file uploads via forms, this second variable is usually the relevant one.

Do I need to restart n8n after setting the variable?

Yes. Environment variables like N8N_PAYLOAD_SIZE_MAX are read in when the n8n process starts. Reloading the web interface is not enough; the instance or the container must be restarted for the new limit to take effect.

Are there downsides to setting the limit very high?

Yes. According to the documentation, a higher payload limit increases the demand on memory and processing power and can affect the performance of the entire instance. Therefore, set the limit deliberately based on actual needs rather than across the board to a very high value.