# Mixed Content blocked

> Your page loaded over HTTPS but asks for images, scripts or styles over plain HTTP, so the browser blocks them or drops the padlock.

Source: https://cwp.sg/errors/mixed-content/  
Author: Ben Johnson  
Last verified: 2026-08-04

**Also seen as:** Blocked loading mixed active content, not fully secure, padlock missing

## What it means

The page itself came over HTTPS. Some of the things it references did not.

Browsers treat this in two tiers:

- **Active content** — scripts, stylesheets, iframes — is **blocked outright**. A script loaded over HTTP could be modified in transit and would then control the whole page. This is why your site suddenly looks unstyled or a feature stops working.
- **Passive content** — images, video, audio — is usually upgraded or allowed, but the padlock is removed and the site is marked not fully secure.

So the visible symptom depends on what is mixed: broken layout and dead JavaScript means blocked active content; an intact page with a missing padlock means images.

## Why it happens

### Hardcoded http:// URLs in content

Images inserted before the site moved to HTTPS keep their original `http://` addresses in the database. Every one of those is a mixed-content warning.

This is the most common cause on any site that existed before its HTTPS migration.

### The site URL setting still says http

If WordPress's Site Address is `http://`, it generates `http://` URLs for its own assets — themes, scripts, uploads — no matter how the visitor arrived.

### A third-party embed that only offers HTTP

An old widget, tracker, font service or analytics snippet with a hardcoded `http://` URL. You cannot fix these by editing your own database; you have to update or drop the embed.

### Protocol-relative URLs behind a proxy

A `//example.com/script.js` URL inherits the page's protocol, which is usually right. It goes wrong when a proxy makes the server think the request is HTTP while the visitor is on HTTPS.

## How to fix it

### 1. Find out exactly what is being blocked

Open the browser console (F12). Mixed content is reported explicitly:

```
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS,
but requested an insecure script 'http://example.com/js/app.js'.
This request has been blocked.
```

That names the exact file. Do this before changing anything — it usually turns out to be two or three URLs, not a site-wide problem.

### 2. Fix the site URL setting first

On WordPress, pin both values in `wp-config.php`, which overrides the database:

```php
define('WP_HOME',    'https://example.com');
define('WP_SITEURL', 'https://example.com');
```

This alone resolves most theme and plugin asset URLs, because they are generated from these values.

### 3. Rewrite the URLs stored in your content

For hardcoded URLs in posts and pages, update the database. **Take a backup first** — this is a bulk edit you cannot undo.

```sql
UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://example.com', 'https://example.com');

UPDATE wp_postmeta
SET meta_value = REPLACE(meta_value, 'http://example.com', 'https://example.com');
```

Only rewrite **your own** domain. Blanket-replacing every `http://` breaks outbound links to sites that do not support HTTPS.

Note that serialised data in `wp_options` stores string lengths, so a plain `REPLACE` can corrupt it. Use a search-replace tool that understands serialisation for that table.

### 4. Let the browser upgrade what is left

As a safety net for embeds you cannot edit, add one header:

```apache
Header always set Content-Security-Policy "upgrade-insecure-requests"
```

That asks the browser to retry HTTP subresources over HTTPS automatically. It works when the remote host supports HTTPS, which most now do.

Use it as a backstop, not as the fix — it hides the problem rather than removing it, and it does nothing for hosts that are genuinely HTTP-only.

### 5. Replace embeds that refuse HTTPS

If a third-party widget only offers HTTP, there is no fix on your side. Either the provider has an HTTPS endpoint you should switch to, or the widget is old enough that it should be replaced.

## On CWP hosting specifically

Every CWP account gets a free SSL certificate, so serving your own assets over HTTPS needs no extra work — the mixed content you see will be hardcoded URLs in your database or third-party embeds.

The [.htaccess generator](/tools/htaccess-generator/) produces a proxy-safe HTTPS redirect, which is worth having alongside these fixes so nobody reaches the HTTP version in the first place.

---

Content Website Platform (cwp.sg) operates the free hosting it writes about; see https://cwp.sg/about/ for the methodology and the commercial disclosure.