RadioMap24 field guide
How internet radio works
A practical explanation of internet radio, from a station encoder and stream URL to browser playback, HLS playlists, buffering and common failures.
- Published
- Updated
- Length
- 1,693 words
- Evidence
- 5 reviewed sources
What a listener actually opens
Internet radio is audio delivered as network data rather than as a signal received by a conventional radio aerial. A station creates audio, encodes it into a streamable format, and publishes one or more addresses that a player can request. The address may point straight to a continuous audio response, to a playlist, or to a station page that reveals a player address. A directory such as RadioMap24 can help a listener discover that address, but discovery and audio delivery are separate jobs. The audio ultimately travels from the station or its delivery provider to the listener’s device.
In a browser, the ordinary building block is the HTML audio element and its related HTMLMediaElement interface. A page gives the element a media URL, then a person chooses Play. The browser negotiates the connection, receives bytes, decodes a format it supports, fills a small buffer, and sends decoded samples to the device’s audio output. The visible play, pause, volume and mute controls are commands to that browser media element. They do not change the programme at the broadcaster; they control only the local listener’s playback session.
That distinction explains a useful privacy and cost property of a direct player. When a site does not proxy audio, it does not receive the programme bytes between station and listener. The listener’s browser makes the media request directly to the stream host after a deliberate action. A catalogue can still be static: it can ship station names, locations and stream descriptors as files, while the live audio connection is made only when a visitor selects a station. Whether a particular station permits access from a place or device remains a decision of that station and its delivery setup.
Sources for this section: MDN Web Docs, MDN Web Docs
From studio sound to a stream URL
A broadcaster normally begins with an audio programme: live microphones, a studio console, automation software, a remote contribution, or a recorded schedule. An encoder converts that programme into compressed digital audio suitable for distribution. Compression reduces the number of bits that must cross the network, but it also chooses a codec, bitrate, channel layout and sampling settings. The output is sent to a streaming origin or a distribution service. Some stations publish several outputs so that older receivers, low-bandwidth listeners and modern players can each use a compatible option.
The stream URL is not a quality guarantee. It is simply the address a client uses to ask for media. Before sound is heard, a domain name may need to resolve, a secure connection may need to be established, the server may need capacity, and the browser must recognise the response format. A station can replace its player, move providers or change encoders without keeping every historic URL working. For that reason, a radio directory should present a failed connection as a delivery problem, not as proof that the station has stopped broadcasting or that a listener’s device is at fault.
Live streams are often described as if they were one endless file, but their delivery methods differ. Some servers hold an HTTP response open and send audio as it is produced. Others publish short pieces of media and a changing index of those pieces. Both approaches can provide continuous listening when the player, network and codec agree. The practical result for a listener is similar: the player accumulates enough audio to start safely, then continues receiving data while the programme is live. The amount held ahead of playback is one reason that switching stations is not always instantaneous.
Sources for this section: MDN Web Docs, MDN Web Docs
HLS playlists and segments
HTTP Live Streaming, usually called HLS, is one common way to distribute live media over ordinary web infrastructure. RFC 8216 describes a presentation as a playlist URI. A media playlist is a UTF-8 text file containing tags and the addresses of media segments; played in sequence, those segments make up the presentation. For a live station, the playlist is refreshed so the client can discover newer segments. This arrangement lets the media use familiar HTTP requests and allows caches to deliver many requests without every listener reaching the encoder directly.
A master playlist can point to variants of the same programme. Variants may differ in bandwidth requirements, media format or, for broader media presentations, video characteristics. A client can choose an appropriate variant and can change choice as network conditions change. That is useful, but it does not remove every interruption. Switching is still constrained by the station’s playlist design, available variants, the browser’s implementation and the listener’s connection. A station may offer only one rendition, or a browser may not support the required combination of transport and codec.
Segmented delivery also affects delay. A player ordinarily needs a playlist, one or more segments, and enough decoded material to avoid immediate underruns. Longer segments and a larger buffer can make playback resilient to small network changes, but they can add delay from the live studio clock. Shorter segments can reduce part of that delay, while increasing request frequency and making timing less forgiving. There is no single number that describes ‘internet-radio latency’. The encoder, origin, CDN, playlist window, player buffering policy, codec and local network each contribute.
Sources for this section: RFC Editor, MDN Web Docs
Why playback starts quickly sometimes and slowly other times
When a listener selects a station, the fastest responsible sequence is to update the interface immediately and ask the browser media element to play as soon as it has the selected descriptor. Work that is not needed to begin audio, such as rendering technical metadata or loading a large catalogue shard, should not sit in front of that request. Even then, the time until sound begins can be governed by the remote station. DNS lookup, TLS negotiation, redirects, server response time, an HLS playlist fetch, segment availability and initial buffering may all be outside the directory’s control.
The browser can reject a play request for reasons that are designed to protect the listener, especially where playback was not initiated by a user gesture. It can also fail because the stream response is unavailable, the content type or codec cannot be decoded, a certificate is invalid, or the source changes while the request is in progress. The correct response is to keep the selected station visible, state that connection failed or is unavailable, and let the listener choose another stream. Quietly substituting a different station would be misleading.
Rapid A-to-B-to-C station changes need cancellation discipline. A page should stop the previous media element, discard stale load events, and allow only the latest choice to update the player state. Otherwise a slow response from station A can appear after the listener has already selected station C. The media interface distinguishes commands such as play and pause from events such as playing, waiting, error and ended. Using those events for status produces a more honest player than treating a click as proof that the broadcaster’s stream has already become audible.
Sources for this section: MDN Web Docs, RFC Editor
HTTPS, cross-origin rules and compatibility
A modern catalogue is commonly served over HTTPS, so secure station URLs are the most reliable candidates for browser playback. A page delivered securely may be restricted from loading insecure active media in ways that vary with browser policy and media type. Directories therefore benefit from recording the exact published stream URL and from identifying links that are not suitable for secure browser playback. That is a technical eligibility check, not a judgement about the station’s editorial quality or legitimacy. A legacy stream can be useful in a dedicated receiver while still being unsuitable for a web page.
Cross-origin rules are often discussed as though they block every external audio stream. The situation is more specific. A browser media element can make a media request to another origin under the element’s own loading rules, while JavaScript access to some media-derived data can require an appropriate CORS response. MDN documents the CORS model separately from the audio element. RadioMap24 therefore treats direct station delivery as a product boundary: it does not fetch or re-serve audio through its own server merely to work around origin or mixed-content constraints, and it does not promise that every published URL will work in every browser.
Codec support is another compatibility boundary. A URL ending in a familiar extension is not enough to establish that a device can decode its response. Browser support changes over time and differs by operating system, browser engine and installed media components. HLS support may be native in one environment and require a compatible path in another; other streaming formats can have their own constraints. Testing from the actual target browser is more useful than guessing from a station name. A user-facing player should expose a clear retry or alternative action when playback cannot begin.
Sources for this section: MDN Web Docs, MDN Web Docs, MDN Web Docs, MDN Web Docs
A practical listening checklist
For a listener, the practical steps are simple: choose a station, give the browser permission to play, and allow a short connection period before deciding that it failed. If it buffers, try another station or network before changing browser settings. If a stream opens but has no sound, check the device volume and mute state as well as the page control. A live stream can be delayed from the studio, so comparing it with an FM receiver may reveal a difference even when both are working normally. A directory should make these states legible without pretending to diagnose a remote station conclusively.
For a site builder, the useful principle is to keep catalogue discovery, player state and media delivery distinct. Use a small local descriptor to initiate the selected stream promptly. Keep only one authoritative audio element for pause, mute and volume. Load nonessential details after playback has been requested. Treat remote streams as independent services that may redirect, stall, change formats or decline a connection. Those choices improve perceived speed without adding an audio proxy, an avoidable server bill, or a second party in the media path.
In short, internet radio is a chain rather than a single technology: programme production, encoding, HTTP delivery, a browser media element, device decoding and local output all have to work together. HLS represents the programme with playlists and media segments; direct streams use a different delivery shape but face the same network and codec realities. A map can make the world’s stations easier to find, yet it cannot make a remote encoder respond faster than it can. Clear status, direct listener choice and respectful failure handling are the durable parts of a good radio experience.
Sources for this section: RFC Editor, MDN Web Docs, MDN Web Docs
Evidence and further reading
Sources
These sources were checked for this guide. Linked publishers remain responsible for their own documents and later revisions.
- RFC 8216: HTTP Live StreamingRFC EditorReviewed
- The audio elementMDN Web DocsReviewed
- HTMLMediaElementMDN Web DocsReviewed
- Cross-Origin Resource Sharing (CORS)MDN Web DocsReviewed
- Mixed contentMDN Web DocsReviewed