Resolve WordPress Upload Size Errors Across PHP and the Web Server

WordPress may report a maximum upload size, return a 413 response, show an empty form submission, or fail while creating image sizes. Each points to a different stage of the upload path.

The reliable route is not the longest checklist; establish the failing boundary, keep one clean reproduction, and change one layer at a time until the evidence lets you align upload_max_filesize, post_max_size, request limits, temporary storage, and WordPress behavior instead of changing one number blindly.

Read the failure at the right layer

• PHP upload_max_filesize or post_max_size rejects the request; post_max_size must accommodate the whole request.
• Nginx, Apache, a proxy, or a CDN enforces a smaller request-body limit.
• The upload temporary directory or wp-content/uploads is unwritable or out of space.

The branches are ordered to protect the strongest evidence around this possibility: pHP upload_max_filesize or post_max_size rejects the request; post_max_size must accommodate the whole request. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Runtime incidents cross several boundaries: the browser reports an HTTP result, the web server hands work to PHP, and WordPress then loads core, plugins, the theme, and data; evidence from the earliest failing boundary is more useful than the component visible on screen; in this guide, the practical goal is to align upload_max_filesize, post_max_size, request limits, temporary storage, and WordPress behavior instead of changing one number blindly.

Build a clean diagnostic record

1. Read Media → Add New and Site Health for the effective PHP values.
2. Inspect the response status: 413 often occurs before PHP, while empty $_FILES can indicate post_max_size was exceeded.
3. Check temporary and uploads directory space, ownership, and permissions.
4. Test a small known-good image before a large archive.

The sequence moves from observation toward intervention. Preserve the result of the final check—test a small known-good image before a large archive—because it provides a useful comparison after the repair.

Repair the cause—not the message

1. Set post_max_size above upload_max_filesize and keep memory/time needs realistic for later processing.
2. Align the proxy or web-server request limit with the intended policy.
3. Correct the specific writable path or use SFTP/CLI for large administrative imports.

Before applying “Set post_max_size above upload_max_filesize and keep memory/time needs realistic for later processing,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can upload files just below the intended ceiling and confirm generated image sizes exist; a changed symptom at that point is new evidence, not permission to make several more changes at once.

Verification checklist

• Upload files just below the intended ceiling and confirm generated image sizes exist.
• Reject a file above the ceiling with a clear message.
• Confirm temporary files are cleaned after success and failure.

One successful refresh is not closure. Keep the incident open until you can also reject a file above the ceiling with a clear message, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

A hosting escalation should include the UTC timestamp, affected URL, response status, request or trace ID when available, PHP version, WordPress version, and the first relevant log entry; redact cookies, passwords, tokens, database credentials, and personal data; include the result of this first observation: read Media → Add New and Site Health for the effective PHP values.

State what was tested, including the result of “Read Media → Add New and Site Health for the effective PHP values,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

wp eval 'echo size_format( wp_max_upload_size() ), PHP_EOL;'
php -r 'echo "upload_max_filesize=", ini_get("upload_max_filesize"), PHP_EOL;'
php -r 'echo "post_max_size=", ini_get("post_max_size"), PHP_EOL;'

Tempting moves to avoid

• Do not allow unlimited uploads because one administrator needs a single large migration.
• Do not grant 777 permissions to solve a write failure.

Primary references

• PHP core directives — official reference consulted for this guide.
• WordPress PHP optimization — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Set post_max_size above upload_max_filesize and keep memory/time needs realistic for later processing”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.