How to Add a Radio Player to Your Website (Embed Code + 5 Methods)

Your radio station's website exists for one primary reason: to get people listening. The single most important element on it is the live player. Not the schedule, not the DJ bios, not the blog: the play button. If a visitor can't start listening within seconds of landing, you've lost them.

Getting a reliable, good-looking player onto a website is still one of the most common frustrations station owners have. The player needs to work in every browser, keep playing as visitors move between pages, show what's playing, and look like it belongs on your site.

This guide walks through five approaches, from simplest to most complete, so you can pick the one that fits your station's technical comfort and budget. Before you start, check that your stream URL works in a browser at all with the free radio stream tester.

Why the live player is your most important feature

Most visitors arrive because they want to tune in now. They heard about you from a friend, found you through a search or clicked a social link, and the first thing they look for is a way to listen.

A good player turns visitors into listeners, keeps them on your site while they browse, and shows now-playing information that makes the station feel live. If it is buried on a subpage, breaks on mobile or stops every time someone clicks a link, you lose listeners at the moment they were most interested.

Two browser rules every player has to live with

Whichever method you choose, two browser rules apply. Most "my player doesn't work" reports come down to one of them.

HTTPS pages need an HTTPS stream. Your website is (or should be) on HTTPS. When an HTTPS page asks for audio over plain HTTP, browsers treat it as mixed content. MDN describes what happens: "<audio>/<video>/<img> HTTP requests on HTTPS pages are auto-upgraded to HTTPS (blocked if host is an IP address)^[1]". In practice, if your stream server has no HTTPS address, or you use a bare IP address like http://203.0.113.5:8000/stream, the stream will not play on your secure site. Ask your stream host for the HTTPS URL.

Browsers decide when sound can start. Chrome's autoplay policy: Muted autoplay always allowed; with sound only after user interaction, MEI threshold (desktop), or installed PWA^[2]. Other browsers are similar. So a player cannot reliably start with sound the moment the page loads; it starts when the listener presses play. Any player that promises otherwise is either muted or relying on the visitor having interacted with your site before.

If something isn't working, our radio player troubleshooting guide goes through each symptom.

Option 1: Embeddable players from your streaming provider

If you stream through a service like Radio.co, SHOUTcast, Icecast or AzuraCast, your provider often offers an embeddable player widget, typically a small HTML snippet you paste into your site.

How it works: You copy an <iframe> or JavaScript embed code from your provider's dashboard and paste it into your page's HTML. The player loads inside that embed and connects to your stream.

Pros: - Simple to set up: copy, paste, done - Maintained by your provider, so it stays compatible with their servers - Often includes basic now-playing info

Cons: - Limited styling: it looks how the provider designed it, not how your site looks - Usually lives in an iframe, which can feel disconnected from the page - Stops when the visitor moves to another page, because each page load restarts the embed - Mobile behaviour varies by provider

A fine starting point if you need something working today. You will probably outgrow it once the styling and the stop-on-navigation behaviour start to bother them.

Option 2: WordPress plugins

If your site runs on WordPress, there are radio player plugins and radio themes that give you more control, such as Pro.Radio and general audio player plugins.

How it works: You install the plugin, enter your stream URL in its settings and configure the appearance. The plugin generates a player inside your theme.

Pros: - More styling flexibility than a basic embed - Some themes and plugins keep playback going across pages using AJAX navigation - Can tie in with other WordPress features like schedules or playlists

Cons: - Quality varies a lot; some plugins are poorly maintained or abandoned - Playback across pages often depends on theme compatibility and can break with caching or other plugins - Premium plugins and themes cost money and still need configuration and updates - Mobile behaviour depends on the plugin

A reasonable middle ground if you're committed to WordPress and comfortable troubleshooting plugin conflicts. Test on several devices, and keep backups before major updates. Comparing the whole picture? Read WordPress vs RadioSiteMaker.

Option 3: Custom HTML5 audio player

If you have a developer (or enjoy coding), building your own player around the HTML5 <audio> element gives you complete control.

How it works: You write HTML, CSS and JavaScript for the interface; the browser's <audio> element plays the stream.

A minimal version:

<audio id="stream" src="https://your-stream-url.example/live" preload="none"></audio>
<button type="button" onclick="document.getElementById('stream').play()">Play</button>

From there you add a pause button, volume, now-playing metadata, artwork and responsive styling.

Pros: - Complete design freedom - No third-party dependencies - Full control over how metadata is fetched and shown

Cons: - Requires real development skills (JavaScript, CSS, browser audio behaviour) - You own cross-browser testing, mobile testing and maintenance - Now-playing data usually needs a small server-side proxy, because many stream servers don't send the CORS headers a browser needs to read their status pages - HLS streams need a library such as hls.js outside Safari - Keeping playback going across page loads means rebuilding your site as a single-page app or loading pages without full reloads, which is a substantial piece of work

This makes sense for stations with a developer on hand. For most independent stations, the build and maintenance time outweighs the benefit.

Option 4: A managed platform with a built-in player

The fourth approach is a website platform built for radio, where the player is part of the site rather than bolted on.

How it works: You enter your stream URL during setup, and the player appears on every page, keeps playing as visitors navigate, and shows now-playing information.

Pros: - No code or plugins - The player is designed with the rest of the site, in your colours - Keeps playing across pages by default - Now-playing metadata, artwork and volume built in

Cons: - Less freedom than a fully custom build - You use the platform's player designs (good platforms let you choose a style and match your branding)

Here is RadioSiteMaker's full-size player on a live demo station. Press play, then click through to another page: the audio carries on.

Option 5: A free now-playing widget for any website

If you want to keep your current website but replace a plain or broken player, the free now-playing widget gives you RadioSiteMaker's player as one line of embed code. You enter your HTTPS stream URL, choose a theme and player size, and copy the <iframe> code into WordPress, Squarespace, Wix or any page you control.

How it works: Audio goes straight from your stream host to the listener. RadioSiteMaker only looks up the current track title, artist and artwork, using the same lookup our station sites use.

Pros: - Free, and works with whatever stream host you use - Shows now-playing information without you building a metadata proxy - Matches one of the station-site themes or your own colours

Cons: - It is an embed, so like Option 1 it restarts when a visitor loads another page of your site - Needs an HTTPS stream URL - Track titles only appear if your encoder or host provides them

A good fix for an existing site; if you want playback that survives navigation, you need Option 4 or a substantial custom build.

Key features your player must have

Whatever approach you choose, check for these:

Playback that survives navigation. The stream should keep playing as visitors move between pages. If the audio stops every time someone clicks "Schedule" or "About", the experience is broken.

Now-playing metadata. Current song, artist and artwork make the station feel live and give people a reason to stay.

Volume control. Some embeds skip it. Listeners shouldn't have to change their system volume.

A layout that works on phones. Check the player on a small screen: is the play button big enough to tap, and does the bar cover anything important?

A visible play button. Typically a fixed bar at the top or bottom of every page. Don't make people hunt for it.

Stream compatibility: what format do you need?

Your player has to support the format your stream uses:

• Icecast / SHOUTcast (MP3 or AAC): the most common setups for independent radio, supported by virtually every player.
• HLS (.m3u8): used by some platforms and CDNs. Safari plays it natively; other browsers need a JavaScript library such as hls.js, and the HLS host must allow cross-origin requests.
• Radio.co, AzuraCast and other hosted platforms: these usually provide standard MP3 or AAC stream URLs.
• Direct MP3/AAC URLs: a URL that returns audio, playable by the basic <audio> element.

Not sure what you have? Paste it into the stream tester, which tells you the format and whether a browser can play it.

The easier way: RadioSiteMaker

With RadioSiteMaker you paste your stream URL into the setup wizard, and the live player appears on every page of your site. It keeps playing while listeners browse, pulls now-playing information and artwork from your stream host (Icecast, SHOUTcast, AzuraCast, Radio.co, RadioKing, Live365 and others, or the title inside the stream itself), and works on desktop and mobile. It supports Icecast, SHOUTcast, HLS and direct MP3/AAC streams.

No code, no plugins, no WordPress to maintain. One plan, $99/year + tax, with the player, schedule, DJ profiles, podcasts, blog, events and more included, and a 7-day free trial with no card required.

Frequently Asked Questions

Can I use my existing SHOUTcast or Icecast stream with a website player?

Yes. SHOUTcast and Icecast streams are standard MP3 or AAC audio that works with embeds, WordPress plugins, custom HTML5 players and managed platforms like RadioSiteMaker. On an HTTPS website you need the HTTPS version of the stream URL; ask your host for it if you only have an http:// address.

Why does my player stop when I click to another page on my site?

Each normal page load replaces the whole document, including the audio element, so playback stops. The fix is a site that changes pages without a full reload, either a single-page app, AJAX navigation, or a platform that does this for you. Embeds and widgets inside a normal website can't avoid it. Our troubleshooting guide explains the options.

Do I need a separate streaming service, or can my website host the stream?

They are two separate things. The stream comes from a streaming server or service (Icecast, SHOUTcast, Radio.co, AzuraCast, RadioHost Studio and so on) that encodes and delivers your audio. The website's player connects to that stream. You need both, but they don't have to come from the same company.

How do I display the currently playing song on my website?

The title and artist come from your stream host's status API (for example Icecast's status-json.xsl or AzuraCast's now-playing API) or from the metadata inside the stream. A player has to fetch it every few seconds, and browsers often can't read those endpoints directly because of CORS, so it is usually done server-side. Managed platforms and the free now-playing widget handle this for you.

Why won't my player start playing on its own?

Browsers block autoplay with sound until the visitor has interacted with the page, for example by clicking play. No website can override this. Make the play button obvious instead of relying on autoplay.

Will a live player slow down my website?

A well-built player adds little: the stream only loads when the listener presses play, and the interface is light HTML, CSS and JavaScript. Heavy plugins and multiple iframes can affect page speed, so test your pages after adding any player.