HTTP 413 means a server refused a request because its content was too large. On a WordPress upload, the rejecting layer may be a proxy, web server or application limit. Raising PHP memory alone does not address a request-size limit elsewhere.
Confirm the response, not just the upload message
Record the failing action, file size and file type. Test with a small, harmless file of the same type. Use the browser network panel to identify the request that returns 413, its response headers and any branded error page. This separates an actual request-size rejection from a generic WordPress media error, a timeout or a permission failure.
Find the layer that refused the request
A request can travel through a CDN, a reverse proxy, a web server and PHP before WordPress sees it. Ask the host to correlate the timestamp with server logs. If the request never reaches PHP, editing WordPress settings cannot fix the earlier rejection. Preserve the URL and timestamp, but avoid sharing a complete authenticated request containing cookies.
Agree on a sensible maximum
Determine the legitimate upload size needed for the task. A product image, a theme archive and a site migration package have different requirements. For large media, reducing the asset size or using an appropriate media workflow may be preferable to raising every limit. A migration may require a hosting-level transfer rather than a browser upload.
Change the relevant configuration
Have the host or administrator adjust the identified request-body limit within the available plan and server configuration. If the request reaches PHP, review the applicable upload and POST limits together. Confirm which configuration file or hosting control actually applies to this site. Do not copy directives for a different web server into .htaccess or make unlimited-size changes without a reason.
Retest below and above the intended limit
Repeat the original legitimate upload and confirm the file is complete and usable. Check a larger test request is still rejected as intended. If the status changes to a timeout or storage error, investigate that new evidence separately. Record the final configuration and a rollback so the exception does not become an undocumented server-wide setting.
Questions about this problem
Will increasing PHP memory fix a 413 error?
Not when a proxy or web server rejects the body before PHP handles it. Identify the rejecting layer first.
Is a 413 error evidence of malware?
No. It is a request-size rejection. A sudden configuration change may need investigation, but this response alone does not show compromise.
Primary references
General diagnostic guidance, not a diagnosis of an individual site. Use a recoverable copy for changes that may affect production.