WordPress 413 request entity too large? Find the limit

Before changing another PHP setting, ask a less exciting but more useful question: where was the 413 response generated?

A WordPress upload that returns 413 request entity too large has often been rejected before WordPress, the importer or PHP had a chance to deal with it. If a hosting panel says the upload limit is now larger but the error remains identical, you may simply be adjusting the wrong layer. It is a common way to lose an afternoon during a migration or catalogue import.

Follow the request path, not the WordPress setting

An upload request can pass through several systems before WordPress receives the file. A visitor may connect to a CDN or reverse proxy, then a web server, then PHP, then WordPress. Any of those earlier layers can impose a body-size limit.

For example, nginx documents that requests exceeding its client_max_body_size setting receive a 413 response. That is a web-server request-body limit, separate from PHP upload configuration. The relevant behaviour is set out in the nginx client_max_body_size documentation.

That distinction matters. Raising upload_max_filesize or post_max_size in PHP will not alter a 413 produced by nginx, a proxy or another front-end service. Change the limit at the layer that refused the request.

Decide which hop said no

Start with the route the file takes, rather than treating WordPress as the automatic culprit. A normal media upload, a WooCommerce product CSV import and a backup restore can all use different request paths, endpoints or tools.

• A small file succeeds, but a larger archive fails immediately: suspect a request-size limit in the proxy or web-server path.
• The upload reaches an importer screen and then fails with an application message: PHP, WordPress memory, processing time or the importer itself may be involved.
• The response has server or proxy headers and no WordPress-style error: investigate the front-end server before changing plugins.
• The file uploads but WordPress later reports an image error: the request was accepted, so this is a different stage. See the separate guide to finding the stage behind a WordPress image upload HTTP error.

A 413 is specifically about the request body being too large for a layer that accepted the connection. It is not a general diagnosis for image conversion trouble, a broken media grid or a thumbnail generation fault.

Compare the limits that apply to the same route

Once you know the likely route, list the limits in order rather than editing values at random. The effective maximum is usually constrained by the smallest applicable limit, but only among the layers actually handling that request.

Check the public-facing proxy or CDN where one is present, the web-server configuration, the PHP handler that serves that site, and the application setting shown in WordPress. A hosting panel can be misleading when it updates one PHP version while the live site runs another PHP-FPM pool. That rather dull detail catches plenty of otherwise sensible people out.

For wider faults involving server settings, WordPress configuration and production changes, our website repair support for Dubai businesses covers the sort of scoped investigation that is safer than repeated live edits.

A representative migration example

Imagine a Dubai retailer moving a product catalogue to a new WordPress site. Small product images upload without fuss, but a larger archive supplied by the previous developer is rejected with 413 before the importer displays any useful response.

Someone increases the WordPress media limit. Then PHP values are increased in the hosting panel. The archive still fails in exactly the same way because the request never reaches PHP. A web-server or reverse-proxy body limit remains lower than the archive size.

This is also why migrations deserve a bit more planning than dragging files into an importer until something gives way. If enquiries, redirects and existing contact routes matter, use a proper website migration plan that protects enquiry routes rather than treating the upload as the whole job.

Make one scoped correction, then retest once

After identifying the refusing hop, change the relevant limit through the appropriate managed configuration or hosting support route. Do not raise every value to something enormous just because an archive is inconvenient. That masks the original cause and can create a needlessly loose setup.

1. Record the file size, upload route and time of the failed request.
2. Save the response status and headers from the failed route where available.
3. Confirm which proxy, web server and PHP handler actually process that route.
4. Correct the body-size limit at the layer producing the 413.
5. Use the same representative file for one bounded retest.
6. Confirm the file reaches the expected WordPress or importer response before changing anything else.

The point of the retest is not to prove that every possible import will work forever. It is to confirm that the known blocking limit has been removed on the actual route. If a different failure appears afterwards, that is useful evidence too. It means the request has reached the next stage instead of being turned away at the gate.

Why a small upload can work while a larger import fails

Small files can sit below the active request-body threshold, so they pass through normally. A larger ZIP, XML export, product CSV with images or media archive crosses that threshold and receives 413 from the layer enforcing it. The successful small upload proves only that the route works for smaller requests. It does not prove that WordPress or PHP controls the maximum size.

Keep the repair narrow

If an import is blocked, resist the usual panic routine of changing WordPress settings, switching themes, disabling plugins and raising every PHP value in sight. None of that locates the response producer. It just makes it harder to tell what fixed anything, if anything was fixed at all.

Send the upload size, request path and response headers so the rejecting limit can be located.