HLS Test Stream URLs: Free M3U8 Links That Actually Work

Not every public URL is a useful one. A good hls test stream comes from an organisation that runs the delivery infrastructure itself and has a reason to keep it online for years, which is why this list is Apple, Akamai, Mux and a handful of player vendors rather than whatever a search turned up last week. Those URLs move rarely. That matters more than it sounds when you are trying to work out whether a bug is in your code or in the stream you happened to grab.

The second thing to look for is what the manifest actually declares. A single-rendition file tells you almost nothing about how your player handles adaptive bitrate, because there is nothing to adapt to. Multi-rendition streams are where the interesting failures live: the switch between quality levels, the gaps in a discontinuous timeline, the metadata a player is supposed to surface and usually does not.

So pick deliberately. Testing basic playback, take any of them. Testing the ladder, take one that advertises several renditions. Testing subtitles, DRM signalling or timed metadata, take the stream built for that, because a generic one will pass and teach you nothing.

No browser except Safari plays HLS natively, so on the open web the job falls to hls.js, the open source library that fetches the manifest, buffers segments through Media Source Extensions and hands them to a plain<video> element. It is what this site’s own player uses. Point it at any URL above and you are exercising the same path a real viewer would take.

Two failures come up constantly and neither is a bug in the library. The first is CORS: a browser will refuse a segment whose server sends noAccess-Control-Allow-Originheader, and every stream on this page sends one, which is precisely why they are useful as a control. The second is mixed content. A page served over https cannot load a plain http segment, so anhttp:// URL that works fine in VLC will fail silently in a tab.

When something does break, the useful move is to look at the manifest rather than the player. Ouranalyzer that reads what a stream declares about its renditions and metadatareads what a stream declares about its renditions, codecs and segment timing, and thechecker that validates whether the server responds at alltells you whether the URL responds at all. Between them you can usually separate a dead server from a manifest your player will not accept, which are two very different problems that look identical from the outside.

These streams exist to give developers a control. Once playback works against a known-good URL, whatever breaks afterwards is yours, and that is a far shorter list to search. If you are building on the open source side, ourbrowser player, which handles adaptive bitrate playback across platformsruns the same hls.js path you would ship, so it is a reasonable place to sanity-check a URL before wiring it into anything.

Working with real playlists rather than single streams? Theeditor for managing large media playlistsand the rest of theM3U toolinghandle files with tens of thousands of entries without loading them onto a server.