iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The WordPress message File is empty. Please upload something more substantial. usually does not mean the photo, video, or document on your computer is blank. It means WordPress received a zero-byte temporary upload, or PHP discarded the request before WordPress could read it. The fastest fix is to check PHP upload limits first, then memory, the wp-content/uploads directory, storage or multisite quota, logs, plugin and theme conflicts, and finally file-type validation.
Work through those checks in that order and retry with one small, known-good image after each change. Make the smallest correction confirmed by the evidence; do not make every directory writable or raise every limit blindly.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11
What the WordPress empty-file error actually means
During a media upload, the browser sends the file to PHP. PHP creates a temporary upload, and WordPress then checks whether that temporary file contains more than zero bytes. If the size is zero, the core upload handler stops and displays File is empty. Please upload something more substantial. WordPress core also identifies two server-side possibilities in this message: uploads may be disabled in PHP, or post_max_size may be smaller than upload_max_filesize.
That distinction matters. A genuine zero-byte source file is only one possibility. A normal 8 MB photograph can produce the same message when PHP rejects the request before WordPress reads it, when the uploads directory cannot be written, or when another layer interrupts the request. Treat the message as a symptom of a failed upload pipeline rather than proof that the local file is empty.
#1 Best Overall
Use the symptom to choose the first check
| What you observe | Most useful first check | Why |
|---|---|---|
| Every file, including a tiny JPG, fails | PHP upload enablement, request limits, and the writable uploads path | A site-wide failure points to the server or WordPress storage path rather than one file. |
| Only large files fail | upload_max_filesize and post_max_size |
The request is probably crossing a PHP size limit. |
| Only one extension or file family fails | MIME-type validation and the account’s upload capability | WordPress may be rejecting the detected type even though the file has content. |
| The error began after a plugin, theme, PHP, or hosting change | Logs, then plugin and theme isolation | A recent software or runtime change can affect the request before the media library processes it. |
| Uploads fail only on a multisite network | Network upload quota and available disk space | Multisite can reject a file when the site’s allowance is exhausted. |
| No corresponding request appears in the PHP log | Web-server and hosting-layer logs | The request may be stopped before PHP handles it, so changing WordPress settings will not help. |
Step 1: Confirm PHP upload settings and request limits
Dashboard uploads are processed by PHP, not just by the WordPress editor. Ask your host where the active PHP configuration is managed, or inspect it through the host’s PHP settings panel. Depending on the host, the values may be in php.ini, a per-directory configuration file, or a control-panel interface. The important point is to inspect the configuration used by the web request, not a command-line PHP installation that may use different values.
Make sure uploads are enabled
PHP must have file uploads enabled. In the active configuration, check that file_uploads is on. If it is off, WordPress cannot receive a file regardless of its size. Change it only through the supported control panel or host configuration, then restart or reload the relevant PHP service if your hosting arrangement requires that step.
Set both size limits for the intended file
upload_max_filesize limits an individual uploaded file. Set it high enough for the largest file you actually need to upload. post_max_size limits the complete HTTP request, including the file and the request’s other fields, so it must be at least as large as upload_max_filesize. Leaving some headroom above the file limit avoids losing space to request overhead.
For example, if your media workflow needs a 20 MB video, an individual-file limit below 20 MB will reject it. A request limit equal to that value may still be tight because the request contains more than the file alone. Choose values according to the largest legitimate upload, not an arbitrarily huge number.
Verify the effective values from WordPress
After changing the host configuration, verify what the site is actually using. In the dashboard, open Tools > Site Health and inspect the information available under the server and media-handling sections. Hosting panels may also display the active PHP version and limits. If the displayed values do not change, the edit was made to the wrong PHP configuration, a higher-level policy is overriding it, or the PHP process has not reloaded.
Retry with a small JPG after the settings are active. If a small file still produces the empty-file message, stop increasing limits and move to the uploads path and logs. Size settings cannot repair a zero-byte request caused by permissions or a failed server process.
Step 2: Check memory only after size limits
WordPress distinguishes between memory available to normal requests and the larger limit commonly used for administration. Its current Advanced Administration Handbook documents a default WP_MEMORY_LIMIT of 40 MB and a default WP_MAX_MEMORY_LIMIT of 256 MB. The backend limit is particularly relevant when the Media Library processes an image or other asset.
Check the values shown by Site Health and compare them with the requirements of your media workflow. A memory exhaustion error normally appears in a PHP or web-server log, so use the log rather than guessing. If the log identifies memory exhaustion, raise the limit through the host-supported method and ensure the server’s PHP memory limit permits the requested value.
Memory is a separate failure path. Increasing either WordPress memory constant does not turn a zero-byte request into a valid file, does not enable PHP uploads, and does not grant write access to wp-content/uploads. Correct the size or filesystem problem first when those are the facts shown by the logs.
Step 3: Verify the uploads directory and its permissions
WordPress normally stores uploaded media beneath wp-content/uploads, often in year-and-month subdirectories. The PHP process needs to create directories and files there, and the resulting files must remain accessible so WordPress can serve them. A directory can exist and still fail because its owner is wrong, its mode denies the web process, or a parent directory blocks traversal.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsFind the path WordPress is using
Check the Media settings and the site’s configuration for a custom upload location before changing anything. On a standard installation the expected root is wp-content/uploads; a migration, multisite setup, or custom configuration can use a different path. Inspect the exact path named in the PHP or web-server log rather than assuming the default.
Test write access with a controlled retry
Back up the site before changing ownership or modes. Ask the host or administrator to test whether the PHP worker can create a temporary file in the uploads directory and remove it afterward. A shell administrator can first inspect the directory with a command such as ls -ld wp-content/uploads, but the correct owner and group depend on the web server and hosting model.
Do not solve a write failure by applying permission mode 777 to the whole site. WordPress warns that overly permissive settings can allow an attacker to upload or modify executable content. Use the least-privilege owner, group, and mode supplied by the host, and grant write access only to the directories that need it. If the directory is writable but files still cannot be served, check read and traverse access on each parent directory and the web-server mapping.
Recognize a permissions-specific pattern
If every file fails immediately and logs mention an inability to create a temporary file, move, or write into the uploads path, permissions or ownership are more likely than PHP size limits. If a file appears briefly and then disappears, inspect cleanup, storage, and security software logs rather than repeatedly changing modes.
Step 4: Check disk space and multisite quota
WordPress checks available upload space and can reject a file when the allowance is exhausted. On a multisite network, the site may have a per-site upload quota even when the server still has free disk space. Check both conditions.
- Inspect the hosting dashboard for the account’s remaining storage.
- On a server you administer, use the host’s disk-space tools, such as
df -h, and check the filesystem that contains the uploads directory. - For multisite, review the network’s site upload-quota setting and the site’s current usage.
- Check whether temporary storage is full; PHP may need temporary space before WordPress can move a file into the uploads directory.
Free space or raise a documented quota only after confirming that the file is legitimate and the account is allowed to use the additional capacity. A quota error is not fixed by raising PHP memory or changing directory modes.
Step 5: Read the logs before changing more settings
The exact failing request is more informative than the generic dashboard notice. Review the PHP error log and the web-server error log at the time of a controlled upload. Managed hosts may expose these in a control panel or provide them through support; self-managed servers usually have separate PHP-FPM or Apache/Nginx logs.
Match common log clues to actions
| Log evidence | Action |
|---|---|
| Uploads disabled or a request exceeds a PHP limit | Enable uploads or align upload_max_filesize and post_max_size, then reload PHP. |
| Memory exhaustion | Adjust the applicable PHP and WordPress memory limits after confirming the server policy. |
| Permission denied, cannot move, or cannot create directory | Correct ownership and least-privilege permissions on the actual uploads path. |
| No PHP entry for the browser attempt | Ask the host to inspect the web-server, proxy, firewall, or request-filtering layer. |
| Fatal error naming a plugin, theme, or PHP function | Isolate the named software and verify PHP compatibility. |
| Unsupported or mismatched MIME type | Test an allowed type and review the account’s upload capability and site restrictions. |
Record the timestamp, filename, approximate size, user account, and whether the retry was a small JPG or another type. That information lets a host match your attempt to the right log line and prevents unrelated warnings from sending the investigation in the wrong direction.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Step 6: Isolate plugin, theme, PHP, and core-file interference
WordPress lists plugin or theme conflicts, PHP incompatibility, and corrupted core files among common causes of failed operations. Test these only after preserving a backup and noting the current configuration.
Use the least disruptive conflict test
- Choose a maintenance window or test site if uploads are business-critical.
- Temporarily deactivate plugins, preferably in batches if the site has many, and retry with one small JPG.
- If the upload works, reactivate plugins one at a time, testing after each activation. The first failure identifies the likely conflict; update, reconfigure, replace, or report that plugin rather than leaving unrelated plugins disabled.
- Temporarily switch to a current default WordPress theme and repeat the test. Restore the original theme after the test if it is not the cause.
- On multisite, remember that network-activated plugins may require a network administrator to change their state.
Do not use a plugin conflict test as a reason to leave security or caching controls disabled permanently. The result is evidence about interference, not a final configuration.
Check PHP compatibility
Confirm that the PHP version supported by the installed WordPress version, active theme, and plugins is the version running the web request. A command-line PHP version can differ from the version used by PHP-FPM or the hosting panel. Logs that show deprecated functions, fatal errors, or incompatible extensions should be addressed with the host or the software maintainer.
Verify WordPress core files
If the problem survives a clean plugin and theme test and logs suggest missing or altered core files, use the dashboard’s supported WordPress update or reinstall process after taking a backup. Do not overwrite wp-content or configuration files casually. A core-file check is especially important after an incomplete migration or a failed update.
Step 7: Check MIME-type validation and file restrictions
WordPress validates the detected MIME type of an upload. Unsupported types are blocked unless the account has the unfiltered_upload capability. Consequently, a file containing data can still fail when its extension, detected type, or site policy is not allowed.
Use a known-good comparison
- Upload a small, ordinary JPG or PNG that opens correctly on your computer.
- Upload the problematic file type separately.
- Compare the results and inspect the log for the detected MIME type.
If common images succeed while one extension fails, investigate the type restriction rather than changing PHP size or memory. Confirm that the account should be allowed to upload that format; granting an unrestricted-upload capability broadens the security boundary and should be a deliberate administrator decision.
Renaming an extension without converting the file does not change its underlying format and can make validation less reliable. Use a real conversion tool when a different format is required, and keep the original outside the public uploads directory until the result is verified.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Follow a controlled retry procedure
A repeatable retry prevents several changes from hiding the real cause.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Choose a small, known-good JPG and note its exact byte size.
- Open the Media Library upload screen in a fresh browser session and attempt only that file.
- Record the time and the exact message.
- Check the PHP and web-server logs immediately.
- Change one confirmed setting or ownership rule.
- Reload the applicable PHP or web service if the host requires it.
- Repeat the same upload and compare the new log entry.
- After the small file succeeds, test a larger file and then the original file type separately.
Testing in this order distinguishes a general pipeline failure from a size threshold and from MIME validation. It also gives a host support technician a clean before-and-after record.
How to decide which cause fits your symptoms
| Question | If yes | If no |
|---|---|---|
| Does every file fail, including a tiny JPG? | Prioritize PHP enablement, the uploads path, storage, and logs. | Continue with size and type comparisons. |
| Do only files above a particular size fail? | Compare that size with both PHP limits and any host-level request limit. | Look at permissions, quota, conflicts, and MIME rules. |
| Can PHP write to the exact uploads directory? | Move on to quota, software, and type validation. | Correct owner and least-privilege access. |
| Is the site on multisite? | Check the site’s upload quota as well as physical disk space. | Skip the network-quota branch. |
| Does the failure disappear with plugins disabled or a default theme active? | Identify the conflicting component by reactivating items one at a time. | Continue with PHP compatibility, core files, and MIME checks. |
| Does a log line identify an unsupported type? | Use an allowed format or have an administrator review the capability and policy. | Do not loosen MIME restrictions without evidence. |
Safe ways to change server settings
There is no universal file path or control-panel label for PHP settings. Shared hosting, managed WordPress hosting, containers, and self-managed servers expose different controls. Use the host’s documented PHP configuration interface, and ask support to confirm the web-facing PHP process rather than editing a random local php.ini.
- Change only the directive supported by the evidence: upload enablement, file size, request size, memory, or filesystem ownership.
- Keep a record of the old value, the new value, the date, and the reason for the change.
- Set limits high enough for legitimate media but not so high that oversized requests become an avoidable resource risk.
- Reload the service when required and verify the effective value from the WordPress request.
- Remove temporary diagnostic changes after the cause is fixed.
If you use managed WordPress hosting, give support the site URL, upload timestamp, file size and type, current PHP version, and the relevant log line. A hosting-support team can usually verify request limits, temporary storage, ownership, and web-server filtering together, which is safer than applying broad permissions yourself.
What not to do
- Do not keep retrying the same large file while ignoring a log entry that shows a lower request limit.
- Do not set the entire WordPress installation to 777.
- Do not raise memory limits when the error is caused by a non-writable directory or a zero-byte request.
- Do not grant
unfiltered_uploadmerely to bypass a file-type restriction without assessing the security implications. - Do not deactivate security controls permanently after a plugin test.
- Do not assume the command-line PHP configuration is the one used by dashboard requests.
- Do not delete existing media or temporary files to create space without confirming backups and retention requirements.
Prevent the error from returning
- Document the PHP version, effective upload limits, memory limits, and uploads path for each production site.
- Monitor account storage and, on multisite, each site’s upload quota.
- Keep WordPress core, themes, plugins, and PHP versions within their supported compatibility range.
- Use least-privilege ownership and permissions, and review them after migrations.
- Keep PHP and web-server logs available long enough to investigate an upload failure.
- Test a small image after major hosting, PHP, migration, plugin, or theme changes.
- Set media policies around the actual file types and sizes your editors need instead of allowing every format.
When to contact your host or administrator
Escalate when you cannot inspect the active PHP configuration, when the web-server rejects the request before PHP, when ownership is controlled by the host, or when disk and quota information is unavailable. Include the controlled-retry record rather than only the dashboard message. The smallest confirmed correction—such as aligning two PHP limits or repairing one directory’s owner—is safer and faster than a blanket server reset.
Recommended Free Tools
The practical verdict is straightforward: treat File is empty as a failed handoff between the browser, PHP, and WordPress. Check request limits first, then memory, write access, storage and quota, logs and software conflicts, and MIME validation. Once a log entry or controlled comparison identifies the branch, fix that branch alone and verify it with the same test file.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
