WordPress Errors

WordPress image upload HTTP error

Advanced Risk: medium

Last reviewed August 7, 2026

Hosting access may not be needed Database access usually not needed

Direct answer

A WordPress “HTTP error” on image upload almost always means the Media Library ran out of memory, hit the PHP execution or upload-size limit, or was blocked by a security plugin/mod_security rule mid-upload — it is rarely a real network problem despite the generic name. Check PHP limits and image processing (Imagick/GD) first, then isolate plugins before touching server config.

The Media Library shows a bare “HTTP error” with no detail when the AJAX upload request fails partway through — usually while WordPress resizes the image into multiple sizes. This guide explains why the message is so vague, gives the PHP limits that actually matter, and lists the safe order of checks so you stop guessing at random plugin settings.

Advanced

Key facts

Verifiable numbers and definitions — each claim links to its source.

PHP upload_max_filesize caps the size of a single uploaded file; uploads larger than that limit fail before WordPress can finish media processing. (PHP upload_max_filesize)
PHP post_max_size limits the entire POST body and must be larger than upload_max_filesize or multipart uploads can fail even when the file alone looks small enough. (PHP core upload directives)
Imagick is the PHP ImageMagick extension WordPress may use when generating resized media; a broken or missing Imagick build can turn uploads into HTTP or processing errors. (PHP Imagick manual)

What the error means

“HTTP error” is WordPress’s fallback message when the `wp-admin/async-upload.php` (or REST API) request behind the Media Library uploader does not come back with a usable response. The browser sent the file, but somewhere on the server the process died — a PHP fatal from Imagick or GD while generating thumbnails, a hit against `upload_max_filesize`/`post_max_size`, a `max_execution_time` timeout on a large image, or a security module (mod_security, a firewall plugin, or the host WAF) closing the connection. Because the failure happens after the browser already got a response back from the initial POST, WordPress cannot show the real underlying error, so it displays the generic message instead. That is different from a stalled upload progress bar (usually a slow connection or a proxy timeout) and different from “Unable to create directory” errors, which point at file permissions rather than PHP limits.

Common symptoms

Media Library upload progress bar reaches 100% then shows “HTTP error”
Small images (thumbnails, low-resolution JPEGs) upload fine; large photos or PNGs fail
Editor “Add Media” and post/page featured image uploads fail the same way
Uploading via FTP or File Manager works, only the WordPress uploader fails
Error log shows a PHP fatal, memory exhaustion, or Imagick/GD error at upload time
Problem started after a plugin update, PHP version change, or hosting migration
Some images fail while others of similar size succeed, pointing at a specific file/format

Most likely causes

01 PHP memory_limit too low for image resizing (Imagick/GD generating multiple thumbnail sizes at once)
02 upload_max_filesize or post_max_size smaller than the image being uploaded
03 max_execution_time or max_input_time too short for large images on a slow server
04 Security plugin, mod_security, or host WAF rule blocking the multipart upload request
05 Corrupt or unusually large image (huge dimensions, embedded metadata, or a bad EXIF/ICC profile) crashing Imagick/GD
06 Insufficient disk space or a full temp directory rejecting the upload mid-write
07 A caching, optimization, or CDN-offload plugin intercepting the upload request and failing silently

What changed before the problem started

PHP version or hosting plan changed, altering default memory_limit/upload limits
New image optimization, WebP conversion, or CDN-offload plugin installed
Security plugin or firewall rule added/updated around the same time
Camera or design software started producing larger, higher-resolution image files
Server disk usage grew close to the account quota

Troubleshooting steps

01
Reproduce with a small test image first
Upload a small JPEG (under 200KB) to the Media Library. If that succeeds, the failure is size/resource related, not a totally broken uploader — narrow in on PHP limits and image dimensions next rather than disabling every plugin blindly.
02
Check PHP memory_limit and raise it if logs show exhaustion
Look at `wp-content/debug.log` or the host PHP error log for “Allowed memory size exhausted” at the upload timestamp. If present, add `define('WP_MEMORY_LIMIT', '256M');` to `wp-config.php` and confirm the host’s PHP memory_limit is not capping it lower via `php.ini` or a control panel setting.
03
Confirm upload_max_filesize and post_max_size cover your image
In wp-admin → Media → Add New, WordPress shows the current “Maximum upload file size.” If your image exceeds it, raise `upload_max_filesize` and `post_max_size` (post_max_size must be equal to or larger) via the host’s PHP settings panel, a `php.ini`, or `.user.ini` — not just a plugin toggle that cannot override server-level limits.
04
Isolate security plugins and firewall rules
Temporarily deactivate security/firewall plugins (Wordfence, security suites) one at a time and retry the same image. If the upload succeeds with a plugin off, check that plugin’s upload/file-type rules or WAF logs for a blocked request matching the failure time.
05
Resize or re-export the problem image and retry
If one specific file keeps failing while others succeed, open it in an image editor and re-save/re-export it (this strips corrupt metadata and normalizes the format). Very large dimensions (for example 8000px+ camera originals) are a common trigger for Imagick/GD failures during thumbnail generation.
06
Check available disk space on the hosting account
In cPanel, Plesk, or your host dashboard, confirm the account is not at or near its disk quota. A full disk or full temp directory can abort an upload partway through and surface as the same generic HTTP error.

Reproduce with a small test image first

Upload a small JPEG (under 200KB) to the Media Library. If that succeeds, the failure is size/resource related, not a totally broken uploader — narrow in on PHP limits and image dimensions next rather than disabling every plugin blindly.

Check PHP memory_limit and raise it if logs show exhaustion

Look at `wp-content/debug.log` or the host PHP error log for “Allowed memory size exhausted” at the upload timestamp. If present, add `define('WP_MEMORY_LIMIT', '256M');` to `wp-config.php` and confirm the host’s PHP memory_limit is not capping it lower via `php.ini` or a control panel setting.

Confirm upload_max_filesize and post_max_size cover your image

In wp-admin → Media → Add New, WordPress shows the current “Maximum upload file size.” If your image exceeds it, raise `upload_max_filesize` and `post_max_size` (post_max_size must be equal to or larger) via the host’s PHP settings panel, a `php.ini`, or `.user.ini` — not just a plugin toggle that cannot override server-level limits.

Isolate security plugins and firewall rules

Temporarily deactivate security/firewall plugins (Wordfence, security suites) one at a time and retry the same image. If the upload succeeds with a plugin off, check that plugin’s upload/file-type rules or WAF logs for a blocked request matching the failure time.

Resize or re-export the problem image and retry

If one specific file keeps failing while others succeed, open it in an image editor and re-save/re-export it (this strips corrupt metadata and normalizes the format). Very large dimensions (for example 8000px+ camera originals) are a common trigger for Imagick/GD failures during thumbnail generation.

Check available disk space on the hosting account

In cPanel, Plesk, or your host dashboard, confirm the account is not at or near its disk quota. A full disk or full temp directory can abort an upload partway through and surface as the same generic HTTP error.

When to stop troubleshooting

Escalate if you cannot access PHP settings or server-level WAF logs, the host cannot raise memory/upload limits on your plan, disk usage is at capacity and you cannot free space, or content teams need reliable uploads working before a launch or campaign deadline. A technician with server access can confirm the exact PHP fatal or blocked request faster than repeated trial-and-error uploads.

Information to collect before requesting help

01 Approximate file size and dimensions of an image that fails
02 Whether small test images upload successfully
03 PHP error log or debug.log entry at the exact upload timestamp
04 Current upload_max_filesize, post_max_size, and memory_limit values
05 Which security or optimization plugins are active
06 Available disk space on the hosting account
07 Whether the failure happens in classic Media Library, block editor, or REST API uploads

How a professional repairs the problem

A technician reproduces the failure with a known test image, reads the PHP/WAF logs at the exact timestamp to find the real fatal or blocked request, then raises the correct combination of memory_limit, upload_max_filesize, post_max_size, and execution time — or fixes the Imagick/GD extension — rather than guessing at plugin settings. Security rules are adjusted with a scoped exception instead of a blanket WAF disable, and bulk imports are moved to SFTP plus WP-CLI when server limits cannot be raised further.

Frequently asked questions

Why does WordPress just say “HTTP error” instead of the real problem? +

The upload request fails after the browser already has an open connection, so WordPress cannot retrieve the specific PHP fatal or server response. The real cause — memory, size limit, timeout, or a security block — is only visible in the server or debug log at that timestamp.

Will increasing upload_max_filesize alone fix it? +

Only if the file size limit was the actual cause. Many uploads fail from PHP memory exhaustion during thumbnail generation or a security rule instead, so check the logs before assuming it is purely a size limit.

Can I fix this from a plugin without server access? +

Some plugins can raise upload_max_filesize via `.htaccess` or `.user.ini` on Apache hosts, but they cannot override a hard limit set by the host at the PHP-FPM or server level. If plugin settings do not change the displayed maximum upload size, you need host-level PHP settings changed.

Why do some large images upload fine while others fail? +

Individual files can trip a memory or execution limit differently depending on dimensions, color depth, and embedded metadata (EXIF/ICC profiles). A corrupt or unusually large file is more likely to fail than a similarly sized but cleanly exported one.

Is this the same as “Unable to create directory” errors? +

No. “Unable to create directory” points at file/folder permissions on `wp-content/uploads`. “HTTP error” points at a request that failed during processing — memory, size, timeout, or a security block — after the upload folder was already writable.

Does disabling my security plugin fix uploads permanently? +

Disabling it only confirms the cause. Leaving security off is not a fix — once confirmed, add a scoped exception for the media upload path instead of running the site without protection.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

You will receive a clear explanation of the likely cause.
We will tell you if the issue falls outside our repair scope.
No additional work will be performed without approval.
A backup should be created whenever access and website condition allow it.

Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.