WordPress's official documentation does not document an "HTTP error" for media uploads. The Common WordPress errors page in the Advanced Administration Handbook — the page that collects WordPress's known failure messages — has no entry for it. WordPress.com's support article on failed uploads lists three error messages, and this is not one of them.
That is the single most useful thing to know before you start troubleshooting. What the official docs do describe are the server-side conditions sitting underneath the media uploader: the size ceiling PHP hands WordPress, backend memory, upload time limits, Apache's mod_rewrite, and which file types are allowed. Those are checkable. Work through them instead.
The size ceiling is not a WordPress setting
This surprises people who go looking in the admin for a limit to raise. The Media Add New screen documentation says the number shown to you comes from somewhere else entirely:
"You will also see a message displayed at the bottom of your view that indicates maximum upload size for files, as set by your hosting provider."
The core function behind that number, wp_max_upload_size(), is described in one line: "Determines the maximum upload size allowed in php.ini." Its body takes the smaller of two PHP directives:
return apply_filters( 'upload_size_limit', min( $u_bytes, $p_bytes ), $u_bytes, $p_bytes );where the two values come from upload_max_filesize and post_max_size. The PHP Optimization handbook page explains both:
"The limit on the size of individual file uploads can be configured using the upload_max_filesize php.ini directive."
"The value for post_max_size must be greater than or equal to the value for upload_max_filesize. PHP will not process requests larger in size than the value for post_max_size."
Two consequences worth internalising. First, raising only upload_max_filesize does nothing if post_max_size is lower — WordPress reports the minimum of the pair. Second, this is often not yours to change: "on shared hosting accounts, those limits are usually set on a server level and you may not be able to modify them or increase them above a certain value."
WordPress's docs give no default number for either directive — not 2MB, not 64MB. If you need yours, read the figure at the bottom of the Media Add New screen or ask your host.
The fastest fix: shrink the file before the uploader sees it
Since the ceiling is your host's and not WordPress's, the reliable move is to bring the file under it. WordPress.com's own troubleshooting page gives exactly this advice: "Consider compressing your files and only uploading the size you need."
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
This runs in your browser tab — the file is re-encoded locally and never uploaded to a server, so you are not solving one upload problem by creating another. If you want the reasoning behind the settings rather than a preset, see how to compress a video without losing quality, or open the compressor on its own page.
Other conditions the docs do describe
Backend memory. WordPress ties this to media uploads explicitly. The handbook: "The option WP_MAX_MEMORY_LIMIT declares the amount of memory WordPress should request for rendering the backend of the website. WordPress default is 256 MB." And then, plainly: "This is mainly required for media uploads." The frontend equivalent is separate — "WordPress default is 40 MB and WordPress MultiSite default is 64 MB" — and the guidance is WP_MEMORY_LIMIT <= WP_MAX_MEMORY_LIMIT. When memory runs out, WordPress has a documented error for it: "An Allowed Memory Size Exhausted error means that your WordPress installation doesn't have enough memory to achieve what you want."
Upload time — and the directive most articles miss. Everyone reaches for max_execution_time. The handbook says the one that actually governs uploads is a different directive: max_input_time "is usually used to limit the amount of time allowed to upload files. It's important to note that the amount of time is separate from max_execution_time, and defines the amount of time between when the web server calls PHP and execution starts." If large files fail and small ones succeed, that is the setting to ask your host about.
A genuine timeout looks different. WordPress documents its own timeout message: "Maximum execution time of 30 seconds exceeded" or "Maximum execution time of 60 seconds exceeded". If that is what you see, you are not chasing a nameless HTTP error any more — the fix documented for it is max_execution_time = 60 in php.ini.
mod_rewrite, but only with a specific symptom pair. The docs are narrow here, and the qualifier matters: "If you are experiencing 404 errors with pretty permalinks and a white screen when you upload images, mod_rewrite may not be enabled in Apache by default." A white screen and broken pretty permalinks together points at this. A white screen alone does not.
Multisite carries a second, much lower cap. On a network install the Network Admin settings screen has its own fields: "Limit total size of files uploaded to [ 50 ] MB" for site upload space, and a Max upload file size where "Default is [ 1500 ] KB". That is roughly 1.5 MB per file regardless of how generous php.ini is. WordPress does not document how the two interact, so treat the network setting as a place to look.
File type, which produces a different message. If the type is the problem, WordPress says so in words: "Sorry, this file type is not supported here." in the editor, and on Multisite, "Sorry, this file type is not permitted for security reasons". Worth knowing: the allowed set is not one table for the whole site. get_allowed_mime_types() removes swf and exe unconditionally, and removes htm|html and js only for users without the unfiltered_html capability — so what an administrator can upload and what a contributor can upload genuinely differ.
If you are on WordPress.com, the list is different again
WordPress.com is a different limit system — plans, not php.ini — and it documents its own upload messages: "This file cannot be processed by the web server.", "Unexpected response from the server.", and "The server cannot process the image."
The first one carries a line that saves a lot of wasted effort: "The file type is not supported. This message is not about the file's size." If that is your message, compressing will not help; converting will. WordPress.com's advice for unsupported formats is to "convert them to a valid file type before uploading" — you can do that with any of the converters in the Clapr toolbox.
How to tell it worked
Reload the Media Library and confirm the file is listed, rather than re-uploading immediately. WordPress.com documents this habit for one of its messages — "The upload often worked anyway" — and it costs nothing to check. Then compare your file size against the figure printed at the bottom of the Media Add New screen, since that is the number your server will enforce.
FAQ
Is "HTTP error" listed in WordPress's official documentation? No. The Common WordPress errors page in the Advanced Administration Handbook has no entry for it, and WordPress.com's upload troubleshooting page lists three different messages, none of which is this one.
What is WordPress's default upload size limit?
WordPress does not set one. The admin shows a maximum "as set by your hosting provider", and wp_max_upload_size() returns the smaller of the upload_max_filesize and post_max_size values from php.ini. The official docs publish no default figure for either.
Which PHP setting controls how long an upload is allowed to take?
Per the handbook, max_input_time — it "is usually used to limit the amount of time allowed to upload files", and it is separate from max_execution_time.
Should I paste a code snippet into .htaccess to raise the limit?
WordPress's docs do not publish one for upload size. The handbook only notes that some server environments allow PHP configuration through files like .htaccess or .user.ini; the sole snippet it gives changes execution time, not file size. Ask your host before copying code from elsewhere.
Why can an administrator upload a file that I cannot?
Because the allowed types are partly role-dependent. get_allowed_mime_types() strips htm|html and js for users lacking the unfiltered_html capability, while swf and exe are removed for everyone.
Cited from WordPress's Advanced Administration Handbook, the core function reference on developer.wordpress.org, and WordPress.com's support centre, checked 16 September 2026. More troubleshooting write-ups live in the fix guides.
