Icecast vs SHOUTcast: which should a radio station use?

Almost every online radio station in the world is delivered by one of two pieces of software. SHOUTcast came first, in 1998, out of Nullsoft and Winamp. Icecast followed as the open-source answer to it, and has been maintained by the Xiph.Org Foundation ever since.

Twenty-five years later the practical differences are smaller than the arguments about them, and for most people running a station the decision has already been made by whoever hosts it.

What a streaming server does

It sits between you and your listeners and does one job: accept a single incoming audio connection from a source, and fan it out to however many listeners request it.

That is genuinely all. It does not schedule, it does not store music, it does not decide what plays next. Those belong to automation, which connects to the streaming server as a source like any other. Confusing the two is the most common misunderstanding in online radio, and it is why people ask which of Icecast and SHOUTcast has better playlist support. Neither does. Neither has any.

The differences that are real

Mount points. Icecast serves many streams from one server, each at its own path — /live, /hq, /talk. SHOUTcast historically served one stream per port, so a second stream meant a second port. Modern SHOUTcast supports multiple streams per server, but the path-based model is still cleaner and it is why Icecast dominates multi-station hosting.

Formats. Icecast handles MP3, AAC, Ogg Vorbis and Opus. SHOUTcast handles MP3 and AAC. Since most stations should stream MP3 anyway, this is a smaller difference in practice than in specification.

Licensing. Icecast is GPL, free, and can be installed and modified by anyone. SHOUTcast is proprietary, with commercial terms that have changed several times — including a period when the free tier was withdrawn and directory listing became a paid feature. That history is why most independent hosting is Icecast: not because of a technical advantage, but because nobody wants their delivery layer to depend on somebody else's licensing decisions.

HTTPS. Both need a reverse proxy in front of them to serve TLS properly. Icecast's path-based model makes that straightforward — one certificate, one hostname, many mounts. This matters more than it sounds, because a browser on an HTTPS page will refuse to play an HTTP stream, and that is most website players.

The directory. SHOUTcast's built-in directory was once a genuine source of listeners. Discovery has moved to aggregators — TuneIn, Radio Garden, myTuner, Online Radio Box — which take a stream URL regardless of what serves it.

The difference that actually affects you

Not the server. The source protocol — how your encoder authenticates and starts sending.

Icecast expects an HTTP-style request with a username and password and a mount point. SHOUTcast historically expected a password on a port with no username at all. This is why your encoder asks you to choose "Icecast 2" or "SHOUTcast" before it asks anything else, and why choosing wrong produces an authentication failure that looks like a bad password.

It is also the origin of the single most common setup error in online radio: leaving the username as source. SHOUTcast had no username, so encoders defaulted the field to Icecast's server-wide account, and a great many people have retyped a correct password several times without touching the field that was actually wrong.

Which should you use?

If you are choosing hosting, you are choosing between providers, not servers, and Icecast-based hosting is the larger and more open market.

If you are running your own server, Icecast for anything new: free, actively maintained, path-based mounts, wide format support, easier to put behind TLS.

If you already have SHOUTcast and it works, there is no urgent reason to migrate. Your listeners cannot tell.

Where the decision genuinely disappears is on a managed platform, because the streaming server stops being something you operate. RadioHost Studio accepts live sources over the Icecast source protocol and delivers to listeners over HTTPS — you configure an encoder, not a server.

Neither of these is your automation

Worth repeating, because it is where money gets wasted: a streaming server with no source connected serves nothing.

Something has to decide what plays at 03:00 on a Tuesday, pull it from a library, obey rotation rules so the same track does not come round twice an hour, drop the news bulletin in on the hour, and hand over cleanly when a presenter connects. That is automation, and it is a separate system that happens to connect to a streaming server the same way a human DJ's laptop does.

Frequently asked questions

Is Icecast better than SHOUTcast?

For new deployments, yes on balance — open licensing, multiple mounts per server, broader format support, easier TLS. The audio quality is identical at the same codec and bitrate; listeners cannot tell which one they are hearing.

Can I use a SHOUTcast encoder with an Icecast server?

Only if the encoder can be switched to the Icecast source protocol, which nearly all of them can. The protocols are different, so the setting must match the server — this is not something the server can guess.

Do I need to install Icecast to run an internet radio station?

Not on a hosted platform. You install a streaming server only if you are operating the delivery infrastructure yourself, which also means operating the bandwidth, the TLS certificates, the monitoring and the failover.

What is a mount point?

The path a stream lives at on an Icecast server — /live in https://stream.example.com/live. One server can host many mounts, which is how a provider serves hundreds of stations from one hostname.

Why does my encoder fail to authenticate?

In order of likelihood: the username is still source; the protocol is set to SHOUTcast against an Icecast server; the mount is missing its leading slash; the bitrate is above what the account allows.