Modern browsers (Chrome, Firefox, Safari, Edge) refuse to load HTTP audio streams on HTTPS websites. If your radio player is embedded on an HTTPS page and your stream is HTTP-only, listeners will see a silent player or a “mixed content blocked” warning in the browser console.
This page explains how HTTPS works for streaming, how CloudRadio handles it for you, and how to fix mixed-content errors when you embed an external stream.
CloudRadio One stations are HTTPS by default
If you broadcast through a CloudRadio One station, you don’t need to do anything. Your HLS stream and your built-in web player are served over HTTPS automatically, with valid certificates managed for you. Embedding the player on any HTTPS website works out of the box.
Hosted Shoutcast/Icecast radios
Hosted Shoutcast and Icecast radios on CloudRadio also expose an HTTPS-compatible player and embed widget. The underlying source/listener URLs may be HTTP for legacy compatibility, but the listener-facing player and widgets you embed on websites use HTTPS.
If you’ve copied an http://...:port/mount URL into a custom player on an HTTPS site, switch to the embeddable web player or to the HTTPS stream URL shown in your dashboard.
What is mixed content?
A page loaded over https:// is only fully secure if everything on it (scripts, images, audio streams) is also loaded over https://. When a page mixes secure and insecure resources, browsers block the insecure ones and surface a warning. This is called mixed content.
For radio embeds, the most common case is:
-
Your website is HTTPS (
https://yourstation.com) -
Your audio stream URL is HTTP (
http://1.2.3.4:8000/live) - The browser blocks the audio, the player shows nothing or “stream unavailable”
This behavior shipped in Chrome 80 in 2020 and is now the default in every modern browser.
How to check if your stream is the problem
- Open your station website in Chrome.
- Right-click the page and choose Inspect → Console.
- Look for messages like “Mixed Content: The page… was loaded over HTTPS, but requested an insecure…”.
If you see one, your player is trying to load an HTTP stream on an HTTPS page.
Fix it
Pick the option that matches your setup:
You’re using the CloudRadio web player
Open the player settings in Studio and confirm you’re using the HTTPS player URL. If you embedded the JavaScript snippet from the Players page, you’re already on HTTPS.
You broadcast on an external host
If your stream is hosted somewhere else (your own server, a third-party Shoutcast host, etc.) and only exposes HTTP:
- Ask your provider whether they support HTTPS streaming. Most modern hosts do.
- If they don’t, consider migrating your station to CloudRadio. Both CloudRadio One and classic Shoutcast/Icecast hosting include HTTPS-ready endpoints and players.
You embed a custom HTML5 player
Replace any http:// URLs with their https:// equivalents in your <audio> or <source> tags. If the upstream stream is genuinely HTTP-only, you cannot make it work on an HTTPS page — you must move the stream to an HTTPS-capable host.
Why HTTPS matters for radio
Beyond the technical “browser will block it” reason:
- Trust: listeners see a padlock and feel safe interacting with the page (newsletter signup, donations, purchases).
- SEO: Google ranks HTTPS pages higher than equivalent HTTP pages.
- Performance: HTTP/2 and HTTP/3, which are faster than HTTP/1.1, are HTTPS-only in browsers.
- Privacy: HTTPS prevents intermediaries (ISPs, public WiFi, ad-injection middleboxes) from tampering with your audio or website.
- Future browser features: geolocation, push notifications, AMP, and many JavaScript APIs require HTTPS.
You don’t need a paid certificate. Let’s Encrypt issues free, browser-trusted certificates, and most hosting providers automate the setup.