When WordPress rejects a file, the upload may have stopped before the file reached temporary storage, during file-type validation, while writing to disk, or while creating image sizes. The same “upload failed” headline can therefore describe several unrelated problems.
Keep the complete error message and test with one small, ordinary file. That gives you a safer starting point than increasing every PHP limit or changing folder permissions without knowing which stage failed.
Compare the failed file with a small valid JPG or PNG. If the small file uploads, focus on the original’s format, dimensions or size. If both fail, investigate the shared upload path and hosting environment.
Guide reviewed: October 8, 2026. Menu labels use English WordPress; provider-specific controls may differ.
Identify the stage where the upload stopped
| Message or result | Check first | Do next |
|---|---|---|
| Missing a temporary folder | Effective PHP temporary path | Ask the host to inspect access to that path |
| Failed to write file to disk | Quota, file count, ownership and filesystem | Identify which path cannot be written |
| File type not allowed | Actual format and allowed MIME types | Export a valid supported file |
| Small image works, large one fails | Request limits versus image processing | Compare size and dimensions separately |
| Upload succeeds, Media Library stays blank | Administration interface request | Check the grid/list and failed script or API request |
When PHP cannot find temporary storage
Ask the host: “Which temporary directory receives PHP uploads for this site, does it exist, and can the PHP process write there?” A folder called tmp elsewhere on the account is not enough. Keep the precise PHP error and timestamp.
A “missing temporary folder” message generally points to the location PHP uses while receiving an upload. That directory needs to exist and be accessible to the process handling the request. A hosting configuration change or filesystem restriction can interrupt that access.
The host can inspect PHP’s upload_tmp_dir, its effective access and related restrictions. A custom WP_TEMP_DIR setting may also be relevant to WordPress operations, but it should not be treated as a guaranteed repair for PHP’s own upload error.
Creating a folder named tmp somewhere in WordPress does not establish that PHP will use it. The useful question is which temporary path the failing operation actually uses and whether that process can write there.
When the file cannot be written to disk
Available storage is a good starting point for “failed to write file to disk.” A hosting account can run out of disk quota or reach a file-count limit even when the dashboard still opens. Temporary storage and the final uploads directory may also have different constraints.
If capacity is available, ownership and permissions become relevant. The user running PHP needs appropriate access to the intended directory. A numeric permission value alone does not explain ownership, and making the whole installation writable to everyone is not a suitable general repair.
A timestamped hosting error log can help distinguish a read-only filesystem, inaccessible temporary path and final-directory problem. Give the host the file size and exact message rather than changing permissions across the entire site.
When WordPress rejects the file type
- Open the source file in the application that created it.
- Export a new copy in a supported format.
- Keep the correct extension for that format.
- Retry one file before requesting an additional allowed type.
Renaming document.exe to document.jpg does not create an image. File-name changes should not be used to bypass validation.
WordPress checks allowed upload types as well as the extension and MIME information. Renaming a file changes its name, not its underlying format. A file that claims to be a JPG but contains another format may therefore fail validation.
Compare the file with a known valid export from the application that created it. If the site genuinely needs an additional document or media type, look for a supported, narrowly scoped configuration. A security plugin or Multisite network setting may also limit the allowed types.
Disabling validation or allowing executable formats simply to dismiss the message creates a different problem. It is better to establish that the file is the intended format and that the site’s upload rules deliberately support it.
When only a large image fails
- Record the original byte size and pixel dimensions.
- Export a reduced-dimension copy and test it once.
- If the request is rejected before upload, inspect the reported request-size limit.
- If the upload finishes but processing fails, inspect the matching PHP/image-processing log.
An image’s processing cost depends on dimensions and format, not only its compressed file size. A photograph can upload successfully and then fail when the server tries to generate smaller copies. This differs from a request rejected before PHP receives it.
Compare a reduced-dimension export with the original. PHP upload and request limits, image-processing memory, the GD or ImageMagick environment and an optimization plugin can all be relevant. The failed request and server log help identify which of those actually stopped the operation.
Increasing every limit together makes that distinction harder to establish. If the request exceeds a known body-size limit, address that limit. If processing reports an error after upload, investigate processing instead.
A file path in the message can explain the problem
“Failed to open stream” needs the surrounding detail. “No such file or directory” points toward the expected path, while “permission denied” suggests an access problem. The path also indicates whether a plugin is reading a template, an image processor is writing a copy, or another operation is involved.
A WordPress path in an error does not, by itself, mean that WordPress core needs replacement. Identify the operation and preserve the full error for diagnosis. Remove private server paths or sensitive details before posting logs publicly.
Checking the result in the Media Library
After a correction, upload the small test file and then the original intended file. Confirm that the attachment opens and any required image sizes display. An empty Media Library grid despite successful uploads may be a separate script or administration-request issue.
The goal is to understand where the upload failed and restore that stage. That gives you a repeatable explanation if the same error appears after a hosting, PHP or plugin change.
Upload references and related troubleshooting guides
- WordPress Developer Reference: get_temp_dir()
- WordPress Developer Reference: _wp_handle_upload()
- WordPress Developer Reference: check_upload_mimes()
Test the saved attachment
After the identified correction, upload the small comparison file and then the intended file. Open the attachment, select it in the Media Library and check required resized images on a page. Record the corrected stage so the next failure is easier to recognize.