HTTP error uploading
Two words of error for a dozen possible failures. Helpful.
WordPress's media uploader says 'HTTP error' the way a toddler says 'it broke' — sincerely, and without a single useful detail. Behind those two words hides a ranked list of real causes, most of them fixable fast once you stop guessing and start narrowing.
Diagnosis within one business day (Mon–Fri). Flat quote before any fix.
What’s actually happening
The message appears when the upload request fails and WordPress can't parse why — the server's actual complaint (memory exhausted, request too large, processing crashed, firewall said no) got swallowed somewhere between PHP and the browser. So the error is real; only the reporting is useless. The diagnosis is a narrowing game: what size fails, what type fails, and when did it start.
The usual physics: image uploads are the heaviest thing casual admin work does. WordPress doesn't just store your photo — it decodes it and generates a stack of resized copies in memory. A 6MB phone photo can balloon to hundreds of MB of working memory mid-processing. That's why uploads fail when everything else works: they're the first thing to hit the memory ceiling, the request-size cap, or the processing library's limits.
The usual causes, ranked
After twenty-seven years of these calls, the odds are well mapped. Start at the top.
Memory exhausted during thumbnail generation
The resize stack blowing past PHP's memory limit — big originals fail, small ones squeak through. The number-one cause.
Server upload and request caps
upload_max_filesize and post_max_size set conservatively by the host — anything past the cap dies with no useful message.
The image-processing library choking
Imagick crashing on specific files or resource limits — the classic 'this one photo always fails' pattern; GD as fallback often sails through.
Security layers vetoing the request
ModSecurity and WAF rules pattern-matching upload requests as attacks — sudden onset after a host-side rules update, nothing changed on your end.
What you can safely try first
Nothing below can make things worse — that’s the selection criterion. Anything riskier belongs in professional hands, on a backup.
- 1
Establish the size threshold
Upload a tiny image, then a huge one. Small-works-large-fails means limits (memory or caps). Everything-fails means processing or security. This single test halves the suspect list.
- 2
Resize one failing photo and retry
Export at 1600px wide and upload. If it goes through, you have a working workaround today while the ceiling gets raised properly.
- 3
Note when it started and what changed
Host migration, PHP version bump, new security plugin? Sudden onset almost always tracks a server-side change — which names the layer to look in.
Stop and call when…
- Raising limits means php.ini or host-panel changes you can't access or don't trust yourself in
- The Imagick/GD switch or resource tuning is the fix — server configuration territory
- A WAF rule is eating uploads — allowlisting precisely, without turning protection off, is the job
From there it’s our job: a look within one business day, flat quote, and the $149 flat repair covers most cases of exactly this.
Error Fix — buy it now, skip the hunt.
One error message, found and gone: memory limits, stuck updates, failed publishing, upload and SSL errors, broken forms.
A full backup before we touch anything, the fix tested on desktop and phone, and a short note on what broke and why. We start within one business day (Monday–Friday) of payment. Full refund if we can't fix it.
Questions we hear a lot.
Why do only some images fail?
Because the causes have thresholds. Memory failures key on pixel dimensions (a 7000-pixel-wide photo costs vastly more memory than its file size suggests). Caps key on file size. Library crashes key on specific encodings — that one photo from that one camera. Which pattern you see is which cause you have.
Is the browser or my computer part of the problem?
Rarely — the same upload failing in another browser and machine confirms it's server-side, which it almost always is. The one client-side suspect worth a glance: enormous images from modern phones, which are innocent files but heavyweight processing jobs on arrival.
What does the $149 fix include?
Reproducing the failure, reading the server's actual error (the one WordPress swallowed), raising the correct limit or repairing the processing library or security rule — and verifying with your real photos, not test files. Plus the numbers you should ask your host to make permanent.
Related symptoms & help
Errors travel in packs. If this one visited, check its friends.
- Memory ExhaustedThe same ceiling, hit elsewhere.
- Unoptimized ImagesWhat those giant uploads do to speed.
- wp-admin BrokenWhen the whole cockpit misbehaves.
- Plugin RepairWhen a plugin's in the upload path.
- Website RepairThe whole bench.
- Locked OutLocked out of WordPress
- Mixed ContentMixed content warnings
- New Site InvisibleNew site not on Google
Upload anything again — fixed and verified.
Send the symptom, get a look within one business day and a flat quote from the developer who's fixed this exact thing more times than either of us can count.