Content Website Platform cwp.sg

Error MIXED · ssl

Mixed Content blocked

In one line

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

Ben Johnson · last verified 2026-08-04

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

What it actually 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.

Diagram illustrating ssl errors on shared web hosting.

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:

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.

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:

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 specifically

Our platform

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 produces a proxy-safe HTTPS redirect, which is worth having alongside these fixes so nobody reaches the HTTP version in the first place.

Still stuck?

Post the exact error and your account name on the community forum — staff and other users answer there, and the thread helps the next person who hits this.