An image file can exist in wp-content/uploads and still fail in the browser because the requested URL is wrong, the server denies the file, or a server rule crashes while handling the request. Open one failing image directly, note whether it returns 404, 403, or 500, then repair that specific layer. Do not regenerate thumbnails until the original image URL works.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Start with a three-minute diagnosis
Treat a missing image as an HTTP request problem before treating it as a thumbnail problem. The status code tells you which branch to follow.
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Copy the complete image
srcURL from the page source, editor, or browser inspector. Open it in a private browser window so a logged-in session or cached response does not hide the failure. - Record the HTTP status, response text, and response headers. Also note the exact time so you can match the request in the web-server error and access logs.
- Compare the URL character-for-character with the real file path under the active site’s
wp-content/uploadsdirectory. Check the domain,https://, subdirectory, year/month folders, filename capitalization, spaces, and extension. - Interpret the result: 404 means the requested path or file was not found; 403 means the server found the request but refused access; 500 means server configuration or application processing failed.
- Open browser developer tools and look for mixed-content warnings, redirects, CORS messages, hotlink protection, or security-layer errors. Check the origin server log for the same URL before changing files.
This first pass prevents a common mistake: running a thumbnail-regeneration tool when the original upload is missing or inaccessible. A thumbnail tool can create derivative sizes only after WordPress or the server can read the original.
How WordPress maps an upload to a browser URL
WordPress uses wp-content/uploads as its default upload directory. When year/month organization is enabled, new files normally go into folders such as wp-content/uploads/2018/06. The directory must be writable by WordPress when it creates the folder or saves a file.
The URL is not necessarily the same as the filesystem path. The web server’s document root maps a public URL to a directory on disk. A site installed in a subdirectory, moved to another host, or served through a reverse proxy can therefore have a valid-looking file in FTP while the browser requests a different location.
Check the four parts that most often differ
- Domain: the page may still reference an old domain after a migration.
- Protocol: an
http://image on anhttps://page can be blocked as mixed content or redirected unexpectedly. - Installation path: a site moved from
/blogto the domain root, or the reverse, needs its image URLs updated. - Upload path and name: year/month folders, uppercase letters, URL-encoded spaces, and file extensions must match exactly. Most Unix-like servers treat
Photo.jpgandphoto.jpgas different files.
Fix a 404 Not Found image
A 404 means the server did not find a resource at the requested URL. It does not prove that no copy exists anywhere on the account; the file may be in a backup, staging tree, old document root, or differently named directory.
PC 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 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteVerify the active document root
Use the hosting file manager or SSH to identify the document root serving the live domain. Then locate the exact relative path from the URL inside that root. A copy under a backup folder or a second WordPress installation cannot satisfy a request sent to the live site’s document root.
Check path and filename details
- Confirm the year and month folder.
- Match upper- and lowercase characters.
- Check whether a space was encoded as
%20and whether punctuation was changed during upload. - Confirm the extension, such as
.jpgversus.jpeg, and whether the file was renamed to a WebP or other format. - Make sure the URL does not contain a duplicated subdirectory or a missing one.
Correct the site URLs after a move
In the WordPress dashboard, open Settings > General and compare WordPress Address (URL) and Site Address (URL) with the domain and path used by the failing image. WordPress documentation explains that these two fields define where WordPress is installed and where visitors reach the site. For a normal HTTPS site, both values should use https:// and should not end with a trailing slash.
If the fields are correct but posts and metadata still contain the old address, perform a serialization-safe database replacement. With a verified backup, WP-CLI can be used as follows:
wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --skip-columns=guid --dry-run
wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --skip-columns=guidRun the dry run first, review the number and location of changes, and use the exact old and new values for your installation. A serialization-aware tool is essential because serialized options and metadata can break when raw SQL replaces strings without updating their lengths. Do not change the guid column during an ordinary URL migration; WordPress migration guidance specifically warns against doing so.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Restore the original when it is genuinely gone
If the original upload is absent from the live uploads directory, restore the matching file or uploads subdirectory from a known-good backup. A thumbnail generator cannot reconstruct an original that no longer exists. After restoring it, test the original-size URL before rebuilding derivative sizes.
Fix a 403 Forbidden image
A 403 indicates that the request reached the server but an access decision denied it. The cause is usually permissions or ownership, an .htaccess rule, a firewall/security feature, or hotlink protection.
Inspect every directory in the path
Check ownership and mode on the document root, wp-content, uploads, each year/month directory, and the image file. The WordPress Developer Resources guide gives general suexec-style examples of directories at 755 or 750 and files at 644 or 640, while warning that hosts differ. It explicitly says no directory, including uploads, should be set to 777 on that setup.
As the guide states: “Permissions will be different from host to host, so this guide only details general principles.” Use the hosting provider’s documented owner, group, and mode rather than applying a blanket command. A file can be readable while a parent directory lacks the execute (traverse) permission required to reach it.
Rank #3
Review .htaccess files safely
Back up the site-root .htaccess and any file inside wp-content or uploads before editing. Search for directives such as Deny from all, Require all denied, referer-based hotlink rules, or plugin-generated blocks that match image extensions. Remove or narrow only the rule responsible, then retest the direct URL.
Separate origin access from security layers
Temporarily test the origin without a CDN image proxy, hotlink feature, WebP rewrite, cache rule, or security plugin rule. A documented support case found direct image requests returning 403 because uploads were not publicly accessible; the recommended checks were permissions and .htaccess. If the origin works while a proxy or firewall is enabled, inspect that layer’s path policy and allow the uploads directory rather than repeatedly changing WordPress files.
Purge CDN or page caches only after the origin returns the correct image. Clearing a cache cannot repair an origin that still answers 403.
Fix a 500 Internal Server Error
A 500 response means the server failed while processing the request. For an image URL, the failure is often an invalid rewrite directive or a stale optimization rule rather than a damaged image.
Read the error log at the request time
Capture the timestamp from your direct test and inspect the web-server error log for that exact request. The log normally identifies the unsupported directive, permission failure, PHP error, or rewrite loop. The access log confirms the path and status; the error log explains why processing stopped.
Test .htaccess and optimization changes
One WordPress support case traced image failures to an invalid directive in an uploads-level .htaccess; deleting the bad file restored access. Another case linked an outage to a stale WebP Express .htaccess file and incorrect modes left after the plugin was removed. These are case reports, not universal causes, but they illustrate why the log and the last configuration change matter.
- Save a copy of the current
.htaccessand note recent plugin, WebP, cache, firewall, or hosting changes. - Temporarily rename the suspect uploads-level rule file so the server stops loading it, then request one original image.
- If the image works, restore rules one change at a time and keep only directives supported by the active web server.
- If it still fails, re-enable the file and continue with the server log, ownership check, and host support; do not delete unrelated configuration blindly.
Repair migration-related image URLs
Moving a WordPress site changes more than the files. Posts, theme settings, widgets, custom fields, and serialized options can retain the old domain or subdirectory, leaving the Media Library or front end with stale URLs. WordPress migration guidance recommends updating those references with a serialization-safe tool or WP-CLI after the files are moved.
Migration checklist
- Back up the database and all files before changing URLs.
- Verify
homeandsiteurluse the current HTTPS domain, correct subdirectory, and no trailing slash. - Confirm the uploads directory was copied into the active document root with its year/month structure intact.
- Run a dry-run, serialization-safe search-and-replace for the old domain or path, excluding
guid. - Visit Settings > Permalinks and click Save Changes to regenerate rewrite rules in the correct directory after the move.
- Test one original-size image and one thumbnail from the Media Library, then test both on a front-end page.
If only newly uploaded images work, the database probably contains old references. If every image fails, investigate the document root, permissions, or server rules before editing thousands of records.
When the Media Library shows a blank thumbnail
A blank thumbnail can represent several different failures. Open the thumbnail URL and the original URL separately. If the original returns 404, restore it or correct the migration path. If it returns 403, fix access controls before regenerating. If it returns 500, inspect the server configuration. Only when the original is reachable should you regenerate missing derivative sizes.
Also check whether a plugin or theme is rewriting image formats, adding a CDN hostname, or requesting a size that was never generated. Disable one rewriting layer temporarily and compare the URL WordPress stores with the URL the browser requests. Regeneration is appropriate for missing derivatives; it is not a remedy for an incorrect domain, blocked directory, or absent source file.
Use the remedy that matches the evidence
| Observed condition | Best next action | What not to do first |
|---|---|---|
| 404 and file absent from the live uploads directory | Restore the matching original from backup, then test it | Regenerate thumbnails |
| 404 and file exists under another domain, path, or case | Correct home/siteurl or run a serialization-safe URL replacement |
Change file modes |
| 403 with restrictive ownership, mode, or parent directory | Apply the host’s documented owner and permission scheme | Set uploads to 777 |
| 403 with an access or hotlink rule | Back up and narrow the relevant .htaccess, plugin, firewall, or proxy rule |
Purge caches repeatedly |
| 500 after a server or image-optimization change | Read the error log and roll back the offending directive or stale rule | Run database replacements |
| Origin works but CDN/proxy URL fails | Inspect proxy rewriting, allow rules, and cache state | Modify the original upload files |
| Server policy or logs are inaccessible | Give the host the exact URL, status, timestamp, and log line | Guess at configuration changes |
A safe repair sequence
Use this order to avoid turning a localized image problem into a site-wide outage.
- Back up: copy the database, uploads directory, and configuration files.
- Capture evidence: save one failing URL, HTTP status, response headers, browser-console message, and matching server-log entry.
- Verify existence: locate the exact file in the active document root and check case, extension, and year/month path.
- Verify URLs: check
home,siteurl, HTTPS, subdirectory, and stale database references. - Correct access: use the host’s documented ownership and permissions on every directory and the file.
- Isolate rules: test without CDN rewriting, hotlink protection, security filters, WebP rules, cache rules, and recently changed plugins.
- Repair rewrites: preserve the old
.htaccess, remove only the invalid rule, and refresh permalinks when the installation path changed. - Retest in layers: request the direct original URL, then the Media Library thumbnail, then a front-end page in a private window.
- Escalate with evidence: send the host the URL, status, UTC timestamp, and relevant error-log line if the origin still returns 403 or 500.
Validate the fix and prevent a repeat
A successful dashboard preview is not enough. Confirm that the direct image URL returns the expected status and content type, that the original and thumbnail load while logged out, and that the front-end page uses the current domain. Check a file in an older year/month folder as well as a newly uploaded file; this distinguishes a historical migration problem from a current write or permission problem.
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 errorsKeep backups of uploads and the database before migrations, record the document root and ownership scheme supplied by the host, and treat generated .htaccess files as configuration that must be reviewed after plugin removal. When a CDN or security layer is involved, document the origin test separately so future cache purges do not mask an underlying 403 or 500.
The practical rule is simple: follow the status code to the layer that produced it. A 404 needs a path or file correction, a 403 needs access-policy correction, and a 500 needs log-led server-configuration repair. Thumbnail regeneration belongs at the end, after the original image is reachable.
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.
