What matters first: WordPress displays the same generic message for several rejected requests, most commonly a file larger than PHP allows or a form submitted with an expired security token.
What this symptom actually tells you
The page does not name the failed limit. Comparing the action, file size, PHP settings and request timing prevents random changes to every upload setting.
Capture evidence before changing anything
- Record whether the error occurs during plugin/theme upload, media upload or form submission.
- Compare the file size with upload_max_filesize and post_max_size.
- Check max_execution_time and the web-server request-body limit.
- Repeat from a freshly loaded page to rule out an expired nonce.
Most common causes
- POST body too large: The web server or PHP discards the request before WordPress receives it.
- Upload limit mismatch: post_max_size is lower than upload_max_filesize or the host enforces another cap.
- Expired nonce: A cached or long-open admin page submits an invalid token.
- Timeout during extraction: A large package uploads but cannot be unpacked before the request ends.
Safe diagnostic and repair sequence
- Set coherent limits at the active PHP and web-server layer, then confirm their effective values.
- Use SFTP or WP-CLI for large trusted packages rather than raising public upload limits indefinitely.
- Exclude authenticated admin pages from full-page caching.
- Retry one controlled upload and inspect the server log if extraction fails.
How to choose between the likely causes
Do not treat POST body too large and Upload limit mismatch as interchangeable. The web server or PHP discards the request before WordPress receives it. By contrast, post_max_size is lower than upload_max_filesize or the host enforces another cap. Use two checks to separate them: Record whether the error occurs during plugin/theme upload, media upload or form submission; and compare the file size with upload_max_filesize and post_max_size. Those observations usually show whether the next safe move is to set coherent limits at the active PHP and web-server layer, then confirm their effective values or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not upload untrusted ZIP files through a larger limit. Validate the source and preserve a backup before installing code.
How to verify the repair
- A realistic package uploads and installs once.
- Fresh and normal-duration admin sessions submit without nonce errors.
- Public request-body limits remain no higher than operationally necessary.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
The page does not name the failed limit. Comparing the action, file size, PHP settings and request timing prevents random changes to every upload setting.
- Record whether the error occurs during plugin/theme upload, media upload or form submission.
- Compare the file size with upload_max_filesize and post_max_size.
- Check max_execution_time and the web-server request-body limit.
- Repeat from a freshly loaded page to rule out an expired nonce.
What must be verified
- A realistic package uploads and installs once.
- Fresh and normal-duration admin sessions submit without nonce errors.
- Public request-body limits remain no higher than operationally necessary.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Does this message always mean my security token expired?+
No. WordPress shows this same generic message for several different rejected requests, most commonly an oversized file upload or an expired nonce, so the wording alone does not identify the cause. Comparing the file size against upload_max_filesize and post_max_size settings usually clarifies which one applies.
I already increased upload_max_filesize — why does the upload still fail with this message?+
post_max_size must also be raised, since a value lower than upload_max_filesize will cause PHP to discard the request before WordPress ever sees it. Both settings, plus any web-server request-body limit, need to agree with each other.
Is raising upload limits site-wide a safe way to install a large plugin package?+
It works but is not the safest option. For large trusted packages, using SFTP or WP-CLI avoids raising public upload limits indefinitely, which reduces the exposure created by leaving a higher limit in place after the install.
The file uploaded but the install still failed with this error — what's different about that case?+
That points to a timeout during extraction rather than an upload-size problem: a large package can finish uploading but fail to unpack before the request ends due to max_execution_time. Checking the server log for a timeout at that stage separates this from a straightforward size limit issue.