Images and API calls blocked as mixed content after moving to HTTPS
The padlock is missing or the page is marked not fully secure. Images fail to appear, styling is partly missing, or data never loads, while the page itself returns a normal successful response.
- Any stack
- Webflow
- Bubble
- Replit
- DNS & SSL
Root cause, in plain English
Once a page is served over HTTPS, browsers refuse to load scripts, stylesheets and data from plain HTTP on the same page, and downgrade or block insecure images. Any URL still written with the insecure scheme keeps working when you test the site over HTTP and is blocked the moment the same page is served securely — so the failure appears at the switch, not when the URL was written.
How to fix it
Open the console on the affected page and list every blocked resource. The browser names each offending URL, which turns this into a finite checklist rather than a search.
Find and update hard-coded insecure URLs in your own content, templates and settings, including ones stored in the database rather than in code.
Point third-party embeds and integrations at their secure addresses; if a provider genuinely cannot serve securely, replace it rather than weakening the page.
Redirect insecure requests to the secure address at the edge, so old links and bookmarks land on a working page instead of one that half loads.
Re-check the pages that matter most after the change — checkout, sign-in and any page with third-party embeds are where a single blocked script does the most damage.
How Nightlamp detects this automatically
- Browser journey
- Visual snapshot
- SSL expiry
Blocking happens in the browser, so a browser_journey is what surfaces it: the page returns a healthy status while the resources inside it are refused, and only a real browser run notices the difference. A visual_snapshot catches the missing images and broken styling that follow, and an ssl check watches the certificate itself so an expiry is never mistaken for this.
Catch this before your customers do
Nightlamp runs these checks continuously against your live app and sends a plain-English diagnosis — not a wall of logs — the moment this pattern shows up.
Related patterns
Frequently asked questions
- Why do images sometimes still appear but scripts never do?
- Browsers treat active content more strictly than passive content. A script or stylesheet from an insecure address can rewrite the whole page, so it is blocked outright, while images are more often upgraded or allowed with a warning.
- The page returns 200. Why is my monitor happy?
- Because the document really did load successfully. The blocked resources are separate requests the browser refuses after the fact, so any check that only reads the status code of the page will keep reporting it as healthy.
- Can I fix this by turning off the browser warning?
- The blocking is enforced by every visitor's browser, not by a setting on your side, so there is nothing to switch off. The URLs have to be corrected — which is also the outcome you want, since the alternative is loading part of your page over an unprotected connection.
Newsletter
Get new incident patterns as we publish them
One email when new failure patterns, fixes, and monitoring recipes for no-code and AI-built apps land. No fluff, unsubscribe any time.
Double opt-in. One-click unsubscribe. No spam, ever.