Upload size is capped in more than one place — PHP has two separate settings, the web server has its own, and WordPress reports whichever is lowest. Raising one and not the others changes nothing, which is why this looks like it should be a two-minute fix and often is not.
Before you buy, one quick look
Read-only. In wp-admin go to Tools → Site Health → Info → Media and note the maximum upload size.
Compare it to the file you are trying to upload. If the file is only slightly over, resizing it may be all you need and costs nothing. If you regularly upload larger files, or the limit is unusually low, raising it properly is the right answer.
Upload_max_filesize / post_max_size limit fix
Uploads are rejected for being too large. We raise the limits at every level that enforces them and confirm the upload actually completes.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Upload rejected for exceeding the limit | This fix covers it |
| Upload fails with a permissions error | File permission errors |
| Upload starts then times out | Maximum execution time exceeded |
| Upload fails with a memory error | PHP memory limit exhausted |
| Only video files fail | This fix covers it |
What you are seeing
- An error stating the file exceeds the maximum upload size
- The limit shown in the media library is lower than you expect
- Large files fail while smaller ones succeed
- It may have changed after a host migration or a plugin update
Common causes
- upload_max_filesize set low in PHP configuration
- post_max_size set lower than upload_max_filesize, which caps it regardless
- A web server body-size limit below the PHP settings
- A host-wide limit that overrides site-level configuration
- A security plugin restricting uploads by size or type
What we do
- Take a full backup before touching anything
- Identify every layer enforcing a limit and which one is currently binding
- Raise the PHP settings to consistent, sensible values
- Raise the server-level limit where we have access to it
- Check execution time and memory, since large uploads need both
- Test with a real file at the new size and confirm it completes
What is included
- Uploads working at the size you need, tested with an actual file
- Limits raised consistently at every layer rather than just one
- Execution time and memory checked alongside, since they fail together
- A note on what was capping it
Not included
- Raising limits on hosts that do not permit it — we tell you and suggest alternatives
- Offloading large media to cloud storage, which is a separate service
- Upgrading your hosting plan where the limit is a plan restriction
- Design changes or content work
Questions about this fix
I already raised upload_max_filesize and nothing changed.
Then post_max_size or a server-level limit is lower and is now the binding constraint. WordPress reports the lowest of all of them, so raising one in isolation frequently changes nothing at all.
How high should the limit be?
High enough for what you actually upload, and no higher. A very large limit lets a single request tie up memory and time, which creates different problems. For most sites 64M to 128M is sensible; video needs more, and often needs offloading instead.
My host will not let me change it. What now?
Some hosts cap this at plan level. We tell you plainly if that is the case, and the honest alternative is usually offloading large files to cloud storage rather than pushing everything through PHP.
Large uploads start and then fail partway. Same problem?
Not quite. Starting and failing partway usually means execution time or memory rather than size. We check all three, because raising the size limit alone often just moves the failure a few seconds later.
Is there a downside to setting the limit very high?
A little — a much higher limit lets a single request use more server memory and time, which matters more on a constrained hosting plan. We set it to comfortably cover what you actually need rather than the maximum possible.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.