Identify which layer rejects the complete request, align its bounded size policy with the intended upload workflow and verify both allowed and rejected requests.
You select a document, submit a website form and receive “413 Content Too Large.” Increasing a limit inside the form plugin may have no effect because a proxy or web server can reject the request before that plugin runs. The first useful question is where the refusal happens.
Investigate with harmless files and an authorised test route. The aim is to support the upload the business actually intends while keeping a bounded request policy. This guide focuses on the rejecting layer; it does not repeat the separate design of file storage, retention or email attachments.
Confirm the actual status and request
MDN defines HTTP 413 as refusal because the request content is too large. Some interfaces use older wording such as “Request Entity Too Large.” If the condition is temporary, the response can include Retry-After; a permanent size cap will not be repaired by repeatedly sending the same file.
Open the browser’s network panel and reproduce once with a synthetic file. Identify the request that failed, including its method, route, status and time. A form can first upload the file to one endpoint and later submit the text to another; inspect the failed request rather than assuming it is the final submit action.
Record the visible error as well as the network status. A generic “upload failed” message can hide a 413, a connection interruption or an application validation error. Those need different investigations. Avoid deciding from a screenshot alone when the actual request is available.
Map the layers that receive the body
Draw the route for this particular upload: browser, CDN or edge proxy, hosting proxy, web server, runtime and application. An external upload service may form a separate branch. Do not assume a file passes through the same route as an ordinary page view.
For a fictional support form, the browser might send a multipart request through an edge service to the hosting server, where a runtime hands it to the form handler. Each layer can enforce its own policy. Raising the handler’s advertised maximum cannot override a smaller cap earlier in that route.
Ask the operator to correlate the harmless request’s time and route with redacted logs. A response header or branded error page can provide a clue, but it is not sufficient proof of the emitting component. Look for the corresponding rejection event and confirm whether the next layer received the request.
Measure the whole body, not only the file
An upload request can contain multiple files, text fields and multipart boundaries. Its complete body is larger than the sum of just the selected file bytes. A per-file rule and a whole-request rule therefore express different constraints.
Suppose the fictional form allows two files of up to 4 MiB each. Two files exactly at that boundary already account for 8 MiB before accompanying fields and encoding overhead. Setting a complete-body cap to exactly 8 MiB does not support that promise. The numbers are illustrative, not recommended limits for every form.
Measure representative requests in the test environment and choose a documented bounded allowance for the intended field sizes and file count. Check which units the actual platform uses. “MB” in a form label and a server directive’s suffix may not express an identical byte count.
| Control | Question it answers | Useful test |
|---|---|---|
| Per-file limit | How large may one accepted file be? | One file immediately below and above the stated boundary. |
| Whole-body limit | How large may the complete request be? | Several allowed files plus normal text fields. |
| File-count limit | How many files may one request contain? | The allowed count and one more. |
| Time limit | How long may an input or processing phase take? | A controlled slower upload, inspected separately from size. |
Inspect the effective server rule
For nginx, client_max_body_size limits the client request body and can be configured in different contexts. Setting it to zero disables that check. Disabling it is not a sensible substitute for understanding the supported upload size.
Have the responsible operator inspect the effective configuration for the actual host and upload route. A setting in a file that is not loaded, or in a different virtual host, cannot fix this request. Shared hosting may expose a supported control panel setting instead of editable server configuration.
Do not paste a server snippet into an application settings field and assume it takes effect. Record the previous value, the intended new value and how the operator verifies the active configuration. Apply the smallest change that supports the agreed route; unrelated sites and endpoints should not inherit a larger cap without a reason.
Separate runtime limits from the 413 emitter
The PHP upload manual distinguishes the per-file upload maximum, overall POST maximum, maximum file count and input-time constraints. These are separate from the web server’s request-body cap. PHP may not be the component returning the 413 at all.
Check the runtime configuration that serves the web request, not only a command-line configuration. Ask which mechanism the host supports for changes and whether an application pool reload is required. A saved settings page is not evidence that the running request uses the new values.
If the request now reaches the application but produces a different error, preserve that observation. You may have removed the first obstacle and exposed a second limit. Continue from the new evidence rather than declaring success because the original status disappeared.
Keep file validation and size policy independent
OWASP recommends proper upload size limits alongside other controls. An accepted request still needs the intended authorisation and file validation. A larger allowed body does not make a file’s claimed type trustworthy.
Do not disable a firewall or move uploads onto an unrestricted public route to make a test pass. If a provider’s hard limit cannot support the intended workflow, compare supported architectural options with the operator. A separate authorised upload service or a smaller file policy needs deliberate access and recovery design, not an improvised bypass.
Also distinguish compressed size from any later expansion or processing cost. Passing the HTTP boundary is only the acceptance of the request, not a guarantee that downstream processing can safely handle its contents. Keep those processing decisions within the upload service’s own controls.
Give visitors a recoverable error
Explain the allowed per-file size, count and relevant total limit before selection. If the upstream layer can return a custom error, make it consistent with the application. The person uploading should not have to interpret a raw server page to discover the form’s policy.
Preserve non-file answers through the application’s approved draft mechanism where feasible, and explain when the user must reselect a file. Do not promise that a browser will automatically restore a selected local file after a failed request or full-page navigation.
For the support example, the recovery screen should identify which file or request limit was exceeded, keep the harmless written description if the form design supports it, and offer a clear route to try a smaller file. Avoid suggesting public file-sharing services for sensitive documents without an approved process.
Retest the boundary deliberately
- Submit a small allowed synthetic file to confirm the basic route still works.
- Submit a file near the intended per-file boundary, then one clearly above it.
- Submit the maximum allowed file count with representative text fields.
- Exercise the whole-body rejection and confirm a useful recovery path.
- Verify the accepted record and file through the intended authorised application view.
- Repeat the affected mobile journey and confirm the rest of the form remains usable.
Change one layer at a time and keep its previous configuration available for a controlled rollback. Record the final effective limits and the observed results rather than merely the values entered into a dashboard. Do not send repeated large production requests as an informal load test.
If the observed problem is actually request frequency rather than request size, use the separate HTTP 429 diagnosis guide. For storage, access and deletion after acceptance, continue with the contact-form upload workflow. A successful 413 repair is a bounded, verified route for the intended request, with clear failure handling for everything larger.
Sources and verification
Editorial review 2026-10-14. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN: 413 Content Too LargeChecked The HTTP meaning of 413 and Retry-After when the rejection is temporary.
Limits: A status code does not identify which product or layer emitted it. - nginx: client_max_body_sizeChecked Complete client request-body limit, effective configuration context and the fact that zero disables this check.
Limits: Applies to nginx; the actual website may use a different server or another earlier limit. - PHP Manual: Common Pitfalls for File UploadsChecked Distinct upload_max_filesize, post_max_size, input-time and file-count constraints.
Limits: The runtime's effective settings and application error handling must be verified; PHP is not necessarily the component emitting a 413. - OWASP: File Upload Cheat SheetChecked Bounded upload sizes and independent validation and authorisation requirements.
Limits: A size change does not establish safe file contents or a complete upload security design.