After a website goes live, images are one of the most vulnerable elements. Text is usually stored in a database and rarely lost during publishing, but images depend on file locations, link syntax, server configuration, and external platforms. A change in any of these can result in blank boxes or broken images on your pages. Below, we discuss common symptoms, causes, and a troubleshooting sequence.
Images Not Displaying at All: Start with the Browser Console
Open the problematic page, press F12 to open developer tools, switch to the Network panel, refresh the page, and check the status codes of image requests. Common scenarios include:
- 404: The file is not at that address, likely due to an incorrect path or the image not being uploaded.
- 403: The file exists but the server denies access, often due to directory permissions or hotlink protection rules.
- Mixed content warning: The page is HTTPS, but the image uses an http URL, which the browser blocks.
- Request canceled or timed out: The image file is too large, or the external server responds slowly.
Status codes help you quickly narrow down the issue to a specific category, which is more effective than repeatedly re-uploading images.
Images Broken After Migration: Paths Changed, References Didn't
When redesigning an old site or switching servers, image files are often reorganized into a new directory structure, but the image links in article content still point to old addresses. This results in: the homepage and list pages look fine, but images in old articles are all broken.
Recommended steps:
- Export all articles from the backend, extract image links from the content, and compile a list of old links.
- Compare the old links with the actual file paths on the new server to identify mismatches.
- If possible, keep the old directory structure; if not, set up redirects on the server to point old image URLs to new ones.
- Use redirects only as a temporary measure. Gradually replace links in the content with new addresses to avoid future breaks during another migration.
If your site has many images, consider using scripts or batch replacement tools. Manually editing each article is error-prone.
Case Sensitivity and Non-English Filenames Causing Some Images to Fail
Some issues are subtle: the same image displays on your editing computer but returns a 404 on the server. A common cause is inconsistent filename casing. Windows is case-insensitive, while Linux servers are case-sensitive, so Banner.jpg and banner.jpg are treated as two different files.
Another scenario involves filenames with non-English characters or spaces. Some servers and CDNs handle these characters differently, and links can become corrupted during copying, pasting, or encoding.
We recommend establishing a consistent naming convention before uploading, for example:
- Use only lowercase English letters, numbers, and hyphens.
- Use hyphens instead of spaces, and avoid mixing underscores.
- Make names descriptive for easy team search, e.g.,
service-consulting-01.jpg. - Place images for the same section in the same directory, avoiding clutter in the root directory.
External Image Links Breaking: Someone Else's Image Isn't Yours
Some content managers take shortcuts by copying image URLs from other websites and pasting them into their own articles. External images carry several risks: if the other party deletes or replaces the image, your page shows a broken image; if they enable hotlink protection, your site cannot load it; if their server is unstable, page load speed suffers.
To check, simply open the image URL in a browser to see if it still works. If the image is important, download it and upload it to your own server or image hosting service, then replace the link. Also be mindful of copyright when using external images—avoid using materials from unknown sources.
HTTPS Pages Loading HTTP Images
After enabling HTTPS, if image links still start with http, browsers treat them as insecure content and block them, resulting in broken images or security warnings. This often occurs with early uploaded images, content copied from old sites, and images in third-party analytics or ad code.
How to check: Search for "Mixed Content" in the developer console, or inspect the image URLs in the page source. To fix, change image URLs to https, or download the images to your own HTTPS domain. If images come from external platforms, first confirm they support https.
Images Load but Display Incorrectly: Size, Format, and Compression Issues
If the link is correct and the status code is 200, but the image appears distorted, blurry, or partially displayed, the issue is likely with the image itself, not the link:
- The actual image dimensions don't match the reserved space, causing stretching or cropping.
- The format is not supported by the browser, e.g., certain special formats may not display in some browsers.
- The image is over-compressed, losing detail.
- The file is too large, loading slowly, and users see a blank placeholder.
Address these issues before uploading: prepare images according to the actual display size, don't rely on code to shrink a large image; use PNG for transparency, JPG or WebP for photos; keep individual image sizes reasonable, and prepare different sizes for list and detail pages.
Daily Checklist for Image Links
Launching a website is not the end. Image links can break as content updates, server adjustments, and external platforms change. We recommend including the following in your routine checks:
- Before publishing a new article, click through each image in the preview to ensure they display correctly.
- After a redesign or migration, spot-check images in old articles, especially those published earlier.
- Regularly check pages using external images to confirm the external URLs are still valid.
- Verify that image filenames and directory structures still comply with team naming conventions.
- When backing up image files, also back up the links in article content, so you know which articles use which images.
Most image link issues are not technical challenges but maintenance habits. Establishing naming rules, upload processes, and checkpoints is far more efficient than fixing broken images one by one after problems arise.
