If your podcast host isn’t hosting its audio on a secure server (that uses
https://at the beginning) then be aware that any embedded audio player will fail in October this year: Google Chrome will block non-HTTPS audio in embedded players once Chrome gets to v86.
This is part of Google’s plan to crack down on so-called “mixed content.” The goal is to prohibit secure web pages (beginning with
https://) from loading insecure subresources like images, video, stylesheets, and… audio.
This is a big deal for podcasters, especially when you consider the importance of embedded audio players on podcast websites and directory pages like Apple Podcasts and Google Podcasts.
But I am curious…
Secure vs. insecure
I wanted to understand how many podcast episodes use HTTP vs HTTPS, so I looked at the
<enclosure> tags for roughly 20 million podcast episodes available in Apple Podcasts.
Here’s what I found:
- 10,961,960 file locations begin with
- 8,750,360 file locations begins with
At first blush, that seems like an awful lot of podcast episodes that could stop working in Google Chrome — nearly 44%!
Good news and bad news
First, the good news: not all audio files beginning with
http:// will immediately stop working in embedded audio players. According to Google:
In Chrome 80, mixed audio and video resources will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://
In other words, if your audio file is available at both an
http:// location and a corresponding
https:// location, you’re probably fine for now. If Chrome can successfully reach the secure version of your audio file, your embedded players should keep working. Some popular podcast hosting platforms serve audio at both insecure and secure addresses.
Now for the bad news: A significant number of podcast episodes are only available over insecure HTTP connections. To test this, I pulled a random sample of 500,000 episodes that begin with
http://, and tried to reach them at their corresponding
Roughly 70,000 of the 500,000 episodes beginning with
https:// were unreachable at their corresponding
Here’s an overview of my ~20 million episodes, grouped by estimated likelihood of problems:
I estimate more than one million podcast episodes are at risk of not playing in embedded players in Google Chrome.
A real-world example
The play buttons simply didn’t work.
The browser console tells us why:
Chrome 80 tried to automatically upgrade the HTTP request to HTTPS. But the podcast audio file wasn’t available over HTTPS. So the request failed, rendering the play buttons non-functional.
That’s crummy for everybody.
So what do I do?
Don’t panic. The vast majority of podcast episodes are available over HTTPS, even if their canonical locations don’t begin with
https://. If your audio files are hosted on a modern, reputable hosting provider, you’re probably fine.
However, if your podcast episodes are among the estimated 1 million+ that aren’t available over HTTPS, now is the time to get your house in order.
If your podcast uses a DIY or home-grown hosting solution, make sure your episodes are available over HTTPS. You might consider switching to a dedicated podcast hosting provider that supports HTTPS for both feeds and audio (Apple maintains a list of recommended partners here).
According to Edison Research, “searching the internet” is the most commonly cited method of podcast discovery.
If a listener searches the web and finds your show, they’re very likely to see an embedded audio player.
Make sure your embedded players continue to work.