Why aren't images loading on a website?

Empty spaces usually have only a few technical causes

We see this in projects more often than you might think: The site is up, the layout fits – and then suddenly empty spaces appear. In shops, it's product images, in portfolios, the references, in blogs, the hero images. It feels dramatic because images are often the part that creates trust.

The causes map: three clusters

First: The image is not reachable. This is the classic: an incorrect path, a renamed file, one uppercase letter too many (yes, that's enough on many servers), or a folder was moved. The server then often returns a 404. We see 403 just as often when permissions or hotlink protection take effect.

Second: The image is being blocked. Since many websites now run entirely on HTTPS, we regularly run into „Mixed Content“: The page is secure (https), but an image is still embedded via http. Modern browsers then block it – not out of spite, but for security reasons. The console usually shows the warning quite clearly.

Third: The image is there – but it doesn't arrive in a useful way. This includes files that are too large (on mobile, they are more likely to fail or seem like they are „loading forever“), a format without a suitable fallback, or a CDN/cache that serves an old or corrupted variant. Images are still the heavyweight on the web: On typical homepages, the median is around 900 KB (mobile) to 1054 KB (desktop) for images alone. HTTP Archive Web Almanac 2024↗

Our perspective: An error is rarely „just technical“

At Pola, we always take a second look at image problems: What is broken – and why was it possible for it to break? Because often there isn't a single typo behind it, but a missing process. That's exactly why we combine repair with prevention: fewer failures, less data, more impact.

If you’re currently acutely affected, don’t switch into “everything new” mode right away. Start with a clean diagnosis – and you’ll be significantly wiser in just a few minutes.

The browser shows you first where it fails

If images are missing, the fastest route is almost always the same: We don’t look in plugins or server logs first, but where the truth ends up – in the browser.

Pola Method 1: The Three-Checks Flow

We use a process for this that deliberately stays short, but covers the most common causes. You only need Chrome or Firefox.

1) Open the image URL directly. Right-click the spot (or in the code the src) and open the image URL in a new tab. If you already see an error page there, it’s not a “rendering problem”, but a delivery problem.

2) Open DevTools and check the Network tab. Press F12, switch to “Network/Netzwerk” and reload the page. Filter by “Img”. Now you’ll see status codes: 404 (not found), 403 (forbidden), 500 (server error), or even 200 – then the problem is more likely related to display, cache or format.

3) Read the console, don’t guess. In the Console tab, hints such as “Mixed Content” or CORS problems are often stated word for word. This is the moment when gut feeling turns into a clear fix.

What the status codes really tell you

A 404 almost always means: path, filename, capitalization, wrong folder. We typically see a 403 with incorrectly set file permissions, security rules or when hotlinking is meant to be prevented.

If you see 200 but still nothing is displayed, things get more interesting: Then we check format and CSS next. An image can be “loaded”, but end up at display:none through CSS, be overridden as a background image or be covered by a cookie banner/overlay. In practice, this happens more often than it sounds in classic guides.

Tools when it gets bigger

If you have many pages, a targeted crawl is worthwhile. For a quick overview, depending on the setup, we often use Google PageSpeed Insights (for performance and image hints) or WebPageTest (for the waterfall and actual loading order). For “Are any image paths broken somewhere?” a Broken Link Checker works pragmatically.

The most important thing: Stick to the order. Anyone who adjusts ten things first sometimes fixes something by accident – and learns nothing from it. Anyone who measures first fixes things cleanly and sustainably.

Missing images damage orientation and trust

An image that doesn’t load is rarely “just” a visual problem. It’s a small breach of trust: You brought someone to your website – and then the page fails to provide the most important orientation.

UX, SEO and conversion depend on it

When images are missing, the answers are often missing too. In a shop: “What does the product look like?” In consulting: “Is the team real?” In NGO communications: “What does the project stand for?” Users leave before they even read your text.

And even if images eventually do appear, timing matters. In the performance context, what matters is which element takes the longest to become visible. In practice, this is often an image: According to the Web Almanac, an image is the element that determines the Largest Contentful Paint in around 68 % of cases. HTTP Archive Web Almanac 2024↗ If this image hangs, the perceived page hangs.

Then it quickly becomes an economic issue: More than half of mobile users leave a page if it takes longer than three seconds to load. Site Builder Report↗ That’s a figure we don’t use as a scare tactic, but as a reminder: Your content is only as effective as its delivery.

Our fresh perspective: Images are also sustainability

At Pola, there’s another layer. Images make up the largest share of data on many websites – and every byte has to be stored, transmitted, and processed. That costs energy in data centers, networks, and on end devices. The internet has a measurable carbon footprint, and unnecessary data transfer is part of it. SHIFT↗

It sounds big, but it starts small: A hero image that is only 180 KB instead of 1.2 MB doesn’t just load faster. It is also simply more responsible. “Less data, more impact” is not a slogan when it comes to images, but a design decision.

And yes: Google is watching too

Core Web Vitals have been part of the Page Experience signals for years. Since 2025, the expectations have noticeably increased in many teams: Performance is no longer “Nice”, but hygiene. Getting image problems under control usually improves LCP at the same time, reduces bounce rates, and makes content reliable again.

The nice thing: This is exactly where the fastest, cleanest improvements are often found – because images have so much potential.

Paths, formats and permissions explain most failures

In practice, it’s often the same stumbling blocks – just in different costumes. We deliberately go through them here in the way we encounter them in everyday work.

Path, filename, upper and lower case

The most common reason is banal: The image is not where the URL points. After a relaunch, after moving media folders, or after a migration (for example, from a staging to the live environment), old paths remain.

Also pay attention to file names: Special characters, umlauts, spaces, or a “final-final-2.png” can end up behaving strangely in combination with encoding and CMS logic. And very importantly: On many Linux servers, /Bilder/Foto.jpg is different from /bilder/foto.jpg.

Permissions, server, and upload errors

If a 403 is returned, it is often a permissions issue or a protection rule. Especially in WordPress, we see this after host changes: The uploads-folder has incorrect permissions or a security plugin is blocking certain file types.

If only one image does not load, it may also simply be damaged (upload aborted, file corrupted). Then the usual solution is: re-export, re-upload, don't spend too long discussing it.

Cache is a blessing and a curse

A cache can save a page – and it can drive you insane. If images are replaced but remain under the same URL, browsers or CDNs sometimes still deliver the old version. Our routine: do a hard reload once, then purge the cache in the CDN/plugin, and only then continue.

WordPress-specific: Plugins and image optimizers

Many image problems in WordPress are indirect. An optimization plugin converts images to WebP, but the rewrite rule is wrong. Or a lazy-loading plugin sets attributes so that the browser only loads the images when they are in the viewport – but an overlay prevents scrolling and therefore prevents the trigger.

If you want to optimize but need to remain stable, many teams start with established tools such as ShortPixel or Imagify. What matters is not the tool itself, but that you test afterward: in incognito mode, on your phone, and once in Safari.

Pola Method 2: Fixing with “one variable per step”

When we fix image problems, we never change five things at once. We take exactly one hypothesis (e.g. “Mixed Content”), apply the fix, check the result in the Network tab – and only then move on to the next variable.

This sounds slow, but it is the opposite: You stay in control. And you can document the fix later, instead of starting from scratch the next time.

Invisible security rules cause visible gaps

If the basics are correct (path correct, status 200, still no image), these “invisible” cases are usually what cost time. We are grouping them here because they often only appear on the margins in classic how-tos.

Mixed Content after switching to HTTPS

You have SSL enabled, the site runs on https – but a few images are still hard-linked to http. Then the browser blocks them. You can identify this very reliably in the console.

In WordPress, a search-and-replace in the database often helps (carefully and preferably with a backup). Many teams use Better Search Replace. The important thing is: Afterwards, check whether all assets are really being delivered via https.

CORS and external image sources

If you load images from another domain, CORS problems can occur with certain applications (Canvas, certain script access). For “normal display”, CORS is less often the cause, but we do see it in web apps. Then the solution is: Set the headers correctly or move the images to a suitable asset domain.

Hotlinking and referrer protection

Sometimes images are “there”, but may only be embedded from your own domain. A shop operator then copies an image from an old system or from a manufacturer – and suddenly it is gone because the source blocks hotlinking. This is not a bug, but intentional behavior by the source. The clean solution is always: Host the image yourself or clarify the permission.

CDN and edge cache: the broken echo

CDNs are great – until an edge node caches an incorrect variant. Then some users see images, others do not. If you have such a “only for some” problem, that is a strong indication.

A targeted purge often helps here (only the affected URLs), followed by a test from different regions, for example with WebPageTest or a multi-location check.

Format support and fallbacks (WebP, AVIF)

WebP is now widely supported, AVIF is rapidly gaining ground. According to the Web Almanac, AVIF quadrupled between 2022 and 2024, while JPEG shares are declining. HTTP Archive Web Almanac 2024↗

Nevertheless: If you serve next-gen formats, you need clean fallbacks via <picture> – otherwise “optimized” quickly becomes “invisible” as soon as a fringe browser or a special in-app browser comes into play.

These special cases are exactly why we always read debugging as a small story: Who calls whom, what comes back, and who blocks it? As soon as you see the image as a request chain, it becomes solvable again.

Robust processes prevent broken links

If we want to prevent image failures permanently, it’s not enough to patch individual broken links. Then we need an image pipeline that is as second nature as a brand guide: clear rules, simple routines, few surprises.

Our “small pipeline” that saves a lot of hassle

We recommend teams a pragmatic version that works without a large tool ecosystem:

1) Scale and compress before uploading. A photo from a camera is almost never web-ready. For quick quality control, we like to use Squoosh or tiny tools like TinyJPG.

2) Take responsive images seriously. If you send a 2400px image to a 390px-wide phone, it looks “sharp”, but above all it’s wasteful. Web Almanac shows that images are delivered at a median of around 25 % larger than necessary on mobile pages. HTTP Archive Web Almanac 2024↗ srcset and sensible size levels solve this.

3) Lazy loading, but with a sense of proportion. For images below the visible area, loading="lazy" is usually right. For the central hero image, it is often wrong because it can worsen LCP. (Depending on the setup, fetchpriority="high"can also help here.)

4) Configure caching so that updates don’t get stuck. Long cache times are good as long as you use versioning (filename or hash). Then the page stays fast and you don’t lose control.

Our fresh perspective: Minimalism as technical stability

One point we rarely read in other guides, but constantly see in design projects: The more images are “just decoration”, the more fragile the page becomes. Minimalist design is not just an aesthetic stance, it is often also the more robust technical decision.

That’s why we consciously ask: “Which image really carries meaning?” If an image only fills space, the risk increases (more requests, more dependencies) without a clear impact. If an image carries meaning, we treat it like core content: optimized, prioritized, with a fallback.

This way, prevention doesn’t become an extra task, but a way of building websites: light, clear, durable.

Good content works even without the image

When images don’t load, for some users it is “just” irritating. For others, it is a real obstacle. And that’s exactly where it gets interesting: accessibility is not just a legal issue or a checkbox, but a stress test for your content.

Alt texts are not decoration

A myth persists stubbornly: “If the image is missing, you can see the alt text.” In reality, this happens inconsistently – often the browser only shows a small icon, and the alt text is primarily valuable for screen readers. That means: alt texts do not replace images, but they save information.

We write alt texts in such a way that they convey the purpose of the image, rather than describing the pixels. A product photo needs something different from an atmospheric image. And a diagram needs a textual summary, otherwise the information is lost.

Placeholders and layout stability

Accessibility is also about layout: When images load late or fail, jumps often occur. This is not just annoying, but can put greater strain on people with cognitive impairments or concentration difficulties. A simple, often underestimated step: width and height set (or define fixed ratios via CSS), so that the space is reserved and the page remains stable.

Our fresh perspective: „Access despite failure“ as a quality criterion

We like to evaluate websites based on how they behave when things go wrong: slow network, blocked images, external service down. If everything then collapses, the experience was fragile.

If, on the other hand, you maintain alt texts properly, don't hide important information only in the image, and embed visual content with stable placeholders, your website remains usable – even when an image doesn't arrive.

This fits with our commitment „Access for all“: Not because we promise perfection, but because we take responsibility seriously.

Quick fixes can create new errors

When we see image problems, we see two typical reactions: Either everything is „analyzed to death“ – or quick solutions are adopted that create new problems in the long term. A few misconceptions keep coming up.

Myth: A CDN makes everything fast automatically

A CDN can reduce latency, but it doesn't suddenly make a 5-MB image small. If you don't use an image CDN with automatic transformation, the file size remains identical. The effect is then limited – and sometimes additional complexity even arises through cache invalidation.

If you really want to deliver automatically, take a look at services such as Cloudinary that dynamically serve formats and sizes. This isn't necessary for every site, but with large numbers of images it can save a lot of maintenance.

Myth: Highest quality is always the best decision

We love strong images. But we also see that users are more likely to give up than wait for perfection. If the load time increases from 1 to 10 seconds, the bounce rate can grow drastically. Site Builder Report↗ Our experience: Quality that is „visually clean“ beats quality that is „technically maximal“.

Myth: Optimized once, done forever

Performance is a state that changes every day because content changes. Today an editor uploads a 6-MB image, tomorrow a new plugin is added, the day after tomorrow a CDN is activated. That is why prevention is more important than heroics.

Myth: Alt text solves the problem

Alt texts are important – but they are no excuse for broken images. They are the seat belt, not the engine.

We don't like these myths because they are “wrong”, but because they steer you in the wrong direction: away from clear diagnosis, away from a clean image strategy. Once you understand the connections, the topic becomes much more relaxed – and you make decisions that bring design, technology and impact together.