Mixed content is when a page served over HTTPS still fetches a script, stylesheet, image or other sub-resource over plain HTTP. A browser either blocks the fetch outright or loads it with a warning, and either way the page's padlock can downgrade even though the site itself runs on HTTPS. The most common mistake in reading this warning is the opposite problem: treating an ordinary link to an http page as mixed content, when it fetches nothing and triggers nothing.
What exactly counts as mixed content?
The test is narrow: did the browser fetch something over http while rendering an https page. A link a visitor might click is a different thing entirely.
Which tags actually trigger it?
Only elements that pull in a sub-resource qualify, and only a few of them:
| Element | What it fetches | Counts as mixed content |
|---|---|---|
| <script src> | A JavaScript file | Yes, blocked outright |
| <link rel="stylesheet" | "icon" | "manifest"> | A stylesheet, favicon or manifest | Yes, blocked or flagged |
| <img>, <video>, <audio>, <source> | A photo, video or audio file | Yes, usually loaded but flagged |
| <iframe>, <frame>, <embed>, <object> | An embedded page or plugin | Yes, blocked outright |
| <a href="http://..."> | A navigation link to another site | No, nothing is fetched |
| <form action="http://..."> | A form posting to an http endpoint | No, a separate insecure-form warning |
| <link rel="canonical" | "alternate"> | Metadata the browser never fetches | No |
Seven element patterns. Only the ones that fetch a sub-resource while the page renders can trigger a mixed-content warning.
Does the browser block it, or just flag it?
It depends on what kind of sub-resource it is:
- Active content is blocked outright. A script, stylesheet, iframe or other content that can run code or change the page is refused. The page renders without it, often visibly broken.
- Passive content is more often loaded with a warning. An image, video or audio file over http is lower risk, since it cannot execute code, so some browsers still load it while marking the connection as not fully secure.
- Modern Chrome and Firefox try an automatic upgrade first. Before blocking or warning, the browser retries the same URL over https. If that retry succeeds, the warning never appears at all.
- Either way, the padlock is the signal that moves. A page can look unchanged to a visitor while the address bar quietly drops from a full secure indicator to a reduced one.
How does an audit tell a real case from a false positive?
Homepage loads a chat widget script over plain http
How to check your own site in five minutes
- Open the page in a browser and click the padlock or security icon in the address bar. A note about insecure sub-resources appears there before anywhere else.
- Open the browser's developer console. A blocked or warned sub-resource is logged there with the exact http:// URL it tried to fetch.
- Search the page's served HTML for `src="http://` and `srcset="http://`, which is where most real cases hide, usually inside an old third-party widget, embed or ad tag.
- Check `<link>` tags for `rel="stylesheet"` or an icon pointed at http. A link tag with `rel="canonical"` or `rel="alternate"` is metadata, not a fetch, and does not count.
- Run a free AI visibility check. It reads the served HTML the same way and reports mixed content scoped to the tags that actually fetch something.
Mixed content FAQ
Does mixed content hurt search rankings?
Not as a direct ranking factor. The damage is practical: a blocked script or stylesheet can break layout or functionality, and a downgraded padlock can make a visitor hesitate, both of which can cost conversions and, indirectly, the signals that come from a site visitors trust.
Why does my browser still warn me when my whole site is HTTPS?
Because one sub-resource on the page, often a third-party script, an old embed, or a widget nobody has touched in years, is still hardcoded to an http:// URL. The site-wide HTTPS migration does not rewrite URLs buried inside third-party code.
Is a link to an http:// page also mixed content?
No. The browser fetches nothing until the visitor clicks the link, so nothing is blocked and no warning fires. Only elements that fetch a sub-resource while the page renders, a script, a stylesheet, an image, an iframe, count.
Auditaar scopes its mixed-content check to the elements that actually fetch something, so a plain outbound link never shows up as a false positive, and reports it inside the Trust & Security pillar. Run a free AI visibility check, or read what security headers a website needs.