A radio player on your station website gives visitors a simple way to listen without searching for your stream elsewhere. A good player is easy to find, works on phones as well as computers, and makes it clear when the station is live.
You usually do not need to build a player from scratch. Your streaming provider may supply an embed code, or your website platform may offer a radio-player feature. The main job is choosing a player that works with your stream and making the listening experience clear.
Choose a player that fits your stream
Start by checking what your streaming provider gives you. It may offer a website widget, a player page, or a direct stream URL. A hosted player is often the simplest option because the provider manages compatibility and updates. A standalone player can give you more control over the look of your site, but you may need help from your web designer to set it up and maintain it.
Ask your provider which stream formats the player supports. Many stations use a continuous Icecast or SHOUTcast stream, while others provide HLS. Some players can handle more than one format and switch to a compatible option for different browsers. HLS playback may be native in some browsers and handled by a player library in others; the details vary by device. Apple documents HLS support across its platforms, and the hls.js project explains how browser playback support differs.
If you already have a website, try the player on a copy or preview page before placing it on your homepage. Check that it loads over HTTPS, plays your actual station stream, and does not interfere with the rest of the page.
Put the player where listeners can find it
Place the player near the top of your homepage or in a clearly marked “Listen Live” area. Keep the main action obvious: listeners should be able to start and stop playback without hunting through menus.
Include useful station information beside the player, such as your station name, current show, presenter, and a link to the schedule. If you show track details, make sure they update reliably. A player that says “Live” but displays old song information can make listeners doubt that the station is actually on air.
On a long page, consider keeping a small player available as visitors scroll. Make sure it can be paused or closed easily, and avoid playing audio on multiple pages at once.
Set expectations about autoplay
Do not rely on sound starting automatically when someone opens your site. Browsers commonly block audio autoplay until the visitor interacts with the page. The rules vary, and a setting that works on one device may fail on another. MDN’s autoplay guide explains why audible playback may be blocked and recommends handling that outcome.
Give visitors a clear Play button and start the stream only after they tap or click it. If autoplay is blocked, show an understandable message or leave the player ready to start. Never make listeners search for a hidden control to stop unexpected audio.
If your player is inside an embedded frame, autoplay permissions may also depend on how the site owner configured that frame. Test the real published page, not just the player by itself.
Make mobile listening easy
Most listeners will encounter your station on a phone at some point. Test the player on both iPhone and Android, using Wi-Fi and a mobile connection. Check that:
- The Play and Pause controls are easy to tap.
- The player fits the screen without covering important content.
- Playback continues when the screen is locked, where the browser and device allow it.
- The stream behaves sensibly when the listener switches apps, takes a call, or loses connectivity.
Lock-screen controls and now-playing information depend on the browser, operating system, and player implementation. The Media Session API can let supported browsers expose playback controls and metadata to device media controls, but support is not universal. Treat lock-screen behavior as something to test on your main listener devices, not a feature you can promise for every phone.
Give listeners a useful fallback
If the embedded player does not work, visitors should still have a way to listen. Add a link to your station’s dedicated listening page or mobile app, if you have one. You can also provide a short troubleshooting note: check the device volume, try another browser, or reload the page.
Do not expose a raw stream URL as the only fallback unless you know it opens in the players your audience uses. A direct URL may open a separate app, download a file, or behave differently from one device to another.
Check your stream and website together
Before announcing the player, test the full experience from the public website:
- Open the page in a private or incognito browser window, where you are less likely to benefit from saved permissions or cached files.
- Press Play and confirm that the station audio starts promptly.
- Listen for several minutes to check for dropouts or silence.
- Pause and resume playback, then refresh the page and try again.
- Repeat on a phone and on another desktop browser.
- Confirm that the player stops cleanly and that the page does not start duplicate audio after navigation.
If listeners report that the player is silent, first confirm that the station stream itself is online. Then check the website embed, HTTPS configuration, and whether the browser is blocking playback until the listener presses Play.
Keep rights and accessibility in mind
Only stream content you have permission to broadcast. Your website player makes the stream easier to reach; it does not change the rights attached to music, programmes, or other content.
Use descriptive labels for controls, maintain enough contrast, and make sure the player can be operated with a keyboard as well as a touchscreen. Avoid making information available only through animation or color.
A simple rule of thumb
Use the player supplied by your radio-streaming provider if it meets your needs. Focus on making the Play button visible, setting a clear expectation that listeners may need to press it, and testing the experience on real phones and browsers. Let the provider or your web developer handle the format fallback behind the scenes.