What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
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.
If an image exists in wp-content/uploads but does not appear on your site, start with the image’s direct URL and its HTTP status. A 404 points to a missing or incorrect path, a 403 means the server is refusing access, and a 500 usually indicates a server configuration or application error. Verify the original file and URL before rebuilding thumbnails, changing permissions, or purging a CDN.
Diagnose the failing image in three minutes
- Copy the complete image URL. Use the page source, the browser’s image address, or the Media Library and open that URL in a private browsing window. Record the status code and any response text.
- Compare the URL with the real file path. Check the domain, protocol, subdirectory, year/month folders, filename capitalization, spaces, hyphens, and extension character by character. A file in
uploads/2024/07will not satisfy a request foruploads/2024/06, andPhoto.JPGis different fromphoto.jpgon a case-sensitive server. - Classify the response. Treat 404, 403, and 500 differently; regenerating thumbnails cannot fix a request that never reaches the original file.
- Inspect the browser and server at the same time. Developer Tools can reveal mixed-content blocks, redirects, CORS messages, or hotlink protection. The access and error logs show what the web server received and why it rejected or failed the request.
Test the original-size file first. If the direct original URL does not load, a thumbnail tool is working on the wrong problem.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems
What WordPress expects in wp-content/uploads
WordPress uses wp-content/uploads as its default upload directory. When the year/month organization option is enabled, it creates folders such as wp-content/uploads/2018/06. The web server and the WordPress process must be able to reach that directory, and the directory must be inside the active document root for the site.
Permissions control who can read, write, modify, and access files. WordPress may need write access to wp-content when it creates uploads or generates image sizes. The exact owner, group, and mode depend on the host’s PHP and web-server setup. WordPress’s permissions guidance states: “Permissions will be different from host to host, so this guide only details general principles.”
On suexec-style hosting, the general examples are directories at 755 or 750 and files at 644 or 640. Those are starting points, not universal values. Do not make the uploads directory 777 on that setup; world-writable permissions create a security risk and can still fail if ownership is wrong.
Fix a 404 Not Found
A 404 means the requested resource was not found at that URL. It does not prove that no copy exists anywhere on the server: the file may be in a backup, staging tree, old document root, or a folder with a slightly different name.
Confirm the file is in the active document root
- Use the hosting file manager, SFTP, or SSH to locate the file under the production site’s actual document root, not a backup or staging directory.
- Check every directory in the URL, including the year and month.
- Match capitalization, punctuation, encoded spaces, and the extension. A URL containing
%20may not match a filename that was renamed with a hyphen, and a request for.webpcannot read a missing.jpg. - Check whether a migration placed uploads in a nested directory such as
public_html/site/wp-content/uploadswhile the domain now servespublic_html.
Check WordPress’s site addresses
In the dashboard, open Settings > General and compare WordPress Address (URL) and Site Address (URL) with the failing image URL. These fields define where WordPress is installed and where visitors reach it. A changed domain, HTTPS scheme, or subdirectory can leave old image URLs in posts, widgets, theme settings, and serialized options.
Both values should use the intended https:// address and normally have no trailing slash. If the site was moved, update references with a serialization-safe migration tool or WP-CLI rather than a blind SQL replacement. For example, after taking a database backup, an administrator can adapt this command to the old and new addresses:
wp search-replace 'https://old-site.example' 'https://new-site.example' --all-tables --skip-columns=guidReview the command for your installation, especially multisite tables and custom content. Do not alter the guid column during an ordinary URL migration; WordPress specifically warns that GUID values should not be changed for this purpose. A serialization-aware tool is important because PHP-serialized data stores string lengths; replacing text without updating those lengths can corrupt options and settings.
Restore before regenerating
If the original file is genuinely gone, restore the matching uploads directory from a known-good backup. Thumbnail generators derive smaller images from the original; they cannot recreate an image that no longer exists. After restoration, request the original URL directly, then rebuild sizes if thumbnails are still missing.
Fix a 403 Forbidden
A 403 means the server understood the request but refused to serve the file. The most common causes are ownership or mode problems, a denying rule in .htaccess, hotlink protection, a firewall, or a security layer that blocks direct access.
Check ownership and modes along the entire path
Inspect the site root, wp-content, uploads, each year/month directory, and the image itself. A readable file can still return 403 when one parent directory denies traversal. Use the host’s documented owner and group and its recommended modes; do not copy a value from another server without understanding how PHP runs there.
Rank #3
- Directories need execute (traverse) permission as well as read permission.
- The file must be readable by the web-server or PHP user that serves static files.
- An ownership change after a migration, restore, or command-line upload can make otherwise normal modes ineffective.
Inspect .htaccess and access rules
Back up each file before editing. Check the site-root .htaccess, then any file inside wp-content or uploads, for directives such as Deny, Require all denied, directory blocks, or plugin-generated hotlink rules. A rule intended to protect private files can accidentally cover public media.
Hosting firewalls, ModSecurity, and security plugins can also deny direct image requests. One documented support case found 403 responses because the uploads directory was not publicly accessible; the recommended checks were permissions and .htaccess. Temporarily disable only the suspected rule, test the direct URL, and restore protection once the cause is understood.
Separate origin problems from CDN problems
Test the origin URL before changing cache settings. If the origin serves the image but the public URL returns 403, a CDN, hotlink feature, or image proxy is applying the denial. Temporarily bypass or disable that layer, purge its cache after the origin works, and then re-enable it with the correct host and path rules.
Fix a 500 Internal Server Error
A 500 indicates that the server could not complete the request. For a static image, that often means a broken rewrite or access directive, a module mismatch, or a plugin-generated configuration file rather than a damaged JPEG or PNG.
Read the error log for the exact request
- Note the time of a fresh direct-image request.
- Open the web-server error log for that timestamp, or ask the host for the matching line.
- Look for an invalid directive, a syntax error, a missing module, a permission failure, or a PHP/application error.
An invalid Apache directive in an uploads-level .htaccess has been documented as a cause of image failures; removing the bad file restored access. Another documented outage followed removal of a WebP conversion plugin, when a stale generated .htaccess and incorrect file modes remained. These are case reports, so use the log to confirm that your installation has the same pattern before deleting anything.
Roll back the last image or server change
Restore the previous .htaccess copy, or temporarily revert the most recent WebP, cache, security, rewrite, or image-optimization change. Change one item at a time and retest the direct original URL. If the server is Apache but a directive belongs to another server, remove or replace it using the host’s supported configuration.
Free tools Windows power users keep installed
One-click scans. No signup required.
Migration and URL checks that prevent recurring failures
Moving a domain, changing HTTPS, or installing WordPress in a different directory can leave old media references in the database. WordPress’s migration guidance recommends a serialization-safe search-and-replace process and updating existing media links after files are moved.
- Back up the database and all files.
- Verify home and siteurl contain the same intended scheme and host as the live installation, with no trailing slash.
- Confirm the uploads directory and its year/month structure are present under the active document root.
- Search database content for the old domain, old subdirectory, and former upload path using a serialization-safe tool.
- Leave
guidvalues unchanged. - Open Settings > Permalinks and save the existing structure once, so WordPress can regenerate rewrite rules in the correct directory. Save the old
.htaccessfirst if you need to preserve custom rules. - Test one original-size image and one thumbnail on the front end and in the Media Library.
Why the Media Library shows a blank thumbnail
A blank thumbnail is a symptom, not a diagnosis. The attachment record may point to an old domain, the original may be missing, generated sizes may have been deleted, or the server may deny the image request.
- Open the thumbnail’s direct URL and classify its status before running a regeneration tool.
- If the original returns 404, correct the path or restore the uploads directory.
- If the original returns 403, fix access rules, ownership, or permissions first.
- If the original returns 500, use the server log and isolate the failing configuration.
- Only after the original loads should you regenerate the required image sizes.
If the original loads but the thumbnail does not, compare the thumbnail filename and dimensions with the attachment metadata, check free disk space and the PHP memory limit, and inspect the log generated during regeneration. A thumbnail tool is appropriate for missing derived sizes; it is not a substitute for repairing a broken URL or inaccessible origin.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Browser and network checks beyond WordPress
Mixed content and redirects
An HTTPS page can block an HTTP image as mixed content. A redirect chain can also end at an old host, a login page, or a rule that denies the request. In Developer Tools, inspect the request URL, every redirect, the final status, and the Location header. Update stored URLs and force the preferred HTTPS address only after confirming that the certificate and site configuration are valid.
CORS and hotlink protection
Most same-site images do not need special CORS headers. If an image is being requested from another origin, inspect the response headers and the policy that controls cross-origin access. Hotlink protection may deny requests that lack an allowed referrer or that arrive through a CDN; temporarily disable it to confirm the diagnosis, then add the legitimate domains instead of making all files public.
Cache and service-worker effects
After the origin is fixed, clear the browser cache, WordPress cache, CDN cache, and any service-worker cache that may preserve a stale 404 or 403. Purging cache before the origin works only hides the evidence and can repopulate the bad response.
Quick Recap
Use the symptom to choose the remedy
| Question | If yes | Most appropriate next action |
|---|---|---|
| Does the direct URL return 404? | The requested path or file is absent. | Verify document root, case, extension, year/month folder, and migration URLs; restore the original if it was deleted. |
| Does it return 403? | The server found the request but denied access. | Check ownership, modes, every parent directory, .htaccess, hotlink rules, firewall, and security layers. |
| Does it return 500? | Server configuration or application processing failed. | Read the error log, revert the last rewrite/image/security change, and repair unsupported directives. |
| Does the original load but a thumbnail fail? | The source is reachable; a derived size or metadata is the issue. | Regenerate the needed sizes and inspect disk space, memory, and regeneration logs. |
| Did the domain or directory change? | Stored media references may be stale. | Verify home and siteurl, run a serialization-safe replacement, leave guid untouched, and refresh permalinks. |
| Does the origin work but the public URL fail? | A CDN, proxy, cache, or security layer is altering the request. | Bypass that layer, correct its rules, then purge and retest. |
| Are server logs or policy inaccessible? | The host controls the evidence needed to diagnose the failure. | Contact hosting support with the exact URL, status, timestamp, request headers, and relevant log line. |
Safe repair order
- Back up the database and files.
- Capture one failing URL, its status, response headers, browser-console message, and timestamp.
- Verify the file’s existence and exact path, including case and document root.
- Check
home,siteurl, the uploads structure, and stale migration references. - Apply the host’s ownership and permission scheme; never jump to
777. - Temporarily isolate CDN, hotlink, security, WebP, cache, and plugin rules one at a time.
- Back up and repair
.htaccessonly when the log or test identifies it; refresh permalinks when appropriate. - Purge caches only after the origin URL works.
- Retest the direct original, the Media Library thumbnail, and the front-end page.
- Escalate with the exact evidence if the origin still returns 403 or 500.
Prevent future image outages
- Keep regular, restorable backups of both the database and
wp-content/uploads. - Record the production document root and the host’s supported owner, group, and permission values.
- After migrations, test an original image and a thumbnail before changing DNS or closing the old site.
- Keep custom
.htaccessrules under versioned backups and remove generated rules when uninstalling an image or cache plugin. - Monitor direct image requests in access and error logs after security, CDN, WebP, or rewrite changes.
- Use HTTPS consistently and avoid hard-coding environment-specific domains in theme or content settings.
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.
