"HTTP Error" When Uploading Images to WordPress: Every Cause, Ranked

You drag an image into the media library. The progress bar creeps along, stalls, and you get two words: "HTTP error."

No code, no explanation, no indication of what to do. A WordPress image upload error is genuinely one of the least helpful messages in the platform, because a dozen unrelated problems all produce the same text.

Here they are in the order worth checking.

First, narrow it down in two minutes

Before changing anything, answer these. Each one eliminates several causes.

• Does a small image work? Try something under 100KB. If small files upload and large ones fail, it is a size or timeout limit
• Does a different format work? If PNG works and WebP does not, it is a permitted-file-type issue
• Does it fail every time or intermittently? Intermittent points at timeouts or server load; consistent points at configuration
• Did it work last week? If so, what changed — a plugin, a host migration, a PHP update

Cause 1: The file is larger than the upload limit

The most common by a wide margin. WordPress shows your limit at the bottom of the media upload screen — often 2MB, 8MB or 64MB depending on the host.

Modern phone photos routinely exceed the lower limits. Raise it in php.ini:

upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300

All three matter. post_max_size must be at least as large as upload_max_filesize, or the upload fails regardless. If you cannot edit PHP settings, ask your host.

Worth saying though: you should rarely need to upload a 20MB image. Resizing before upload is better for your site speed anyway.

Cause 2: PHP memory exhausted during processing

WordPress does not just store an image — it generates several resized versions. That processing needs memory, and a large image can exceed the limit partway through.

The signature is a large image failing while a small one succeeds, with no size-limit message. Raise the limit in wp-config.php:

define('WP_MEMORY_LIMIT', '256M');

Our guide to the WordPress memory limit covers this in more depth.

Cause 3: A script timeout

Large images take time to process. If the server caps script execution at 30 seconds and processing takes 45, PHP stops midway.

This is why the error often appears intermittently — the same file succeeds when the server is quiet and fails when it is busy. Raising max_execution_time addresses it.

Cause 4: The image processing library

WordPress uses either ImageMagick or GD to handle images. ImageMagick is preferred but is sometimes misconfigured, missing, or restricted by the host.

Adding this to your theme's functions.php forces WordPress to use GD instead:

add_filter('wp_image_editors', function() { return ['WP_Image_Editor_GD']; });

If uploads immediately start working, ImageMagick was the problem and your host should look at it. Treat this as a diagnostic rather than a permanent fix — GD produces slightly lower quality output.

Cause 5: File permissions

WordPress must be able to write to wp-content/uploads. After a migration or a bulk permissions change, it sometimes cannot.

Folders should be 755 and files 644. Never set anything to 777 — it will often work and it is a genuine security risk.

Cause 6: A plugin conflict

Image optimisation, CDN, media library and security plugins all interact with uploads. Any of them can break the process, particularly after an update.

Deactivate plugins in batches and retry. Image compression plugins are the most frequent culprit — they hook into the upload and fail silently when their own limits or API quotas are exceeded.

Cause 7: The file type is not permitted

WordPress only accepts certain formats. Older installations may not allow WebP or AVIF, and SVG is blocked by default for good reason — SVGs can contain executable code.

If you genuinely need SVG uploads, use a plugin that sanitises them rather than simply allowing the type. Permitting raw SVG uploads for anyone with an author account is a real security decision, not a convenience setting.

Cause 8: A mod_security rule

Some hosts run server-level security filtering that blocks uploads it considers suspicious. This produces exactly the same unhelpful message.

The clue is that everything looks correctly configured and uploads still fail. Ask your host to check whether mod_security is blocking the request — they can see it in logs you cannot.

Cause 9: The filename

Spaces, apostrophes, accented characters and non-Latin scripts in filenames cause problems on some servers. So does an unusually long name.

Rename to something simple and lowercase with hyphens, and retry. This is worth doing as a habit — it also produces tidier URLs.

A practical order to work through

1. Try a small, simply-named JPEG to establish whether uploads work at all
2. Check the size limit shown on the upload screen
3. Raise upload_max_filesize, post_max_size and max_execution_time
4. Raise the WordPress memory limit
5. Force the GD image editor as a test
6. Check permissions on the uploads folder
7. Deactivate plugins in batches
8. Ask your host about mod_security

One thing to check while you are in there

Since you are looking at the uploads folder anyway, check what is in it. It should contain images and documents organised into year and month folders.

If there are .php files anywhere in wp-content/uploads, they are not yours. That folder should never contain executable code, and its presence indicates a compromise. Our guide to removing malware from WordPress covers what to do.

Blocking PHP execution in that folder is one of the more worthwhile items on our hardening checklist.

If uploads still fail

This error wastes a surprising amount of time precisely because the message says nothing. Working through nine possible causes to publish one blog post is not a good use of an afternoon.

Our WordPress error fixing service diagnoses it directly from the server logs rather than by elimination, and fixes the underlying configuration so it does not recur.

Get in touch with your web address and roughly what size files are failing.