What Is HLS Streaming? HTTP Live Streaming Explained

Press play on almost any video app on your phone, whether it is a news channel, a sports stream, a paid course or a social feed, and there is a good chance the video arrives as HLS. HTTP Live Streaming was created by Apple in 2009 to stream video to the first iPhones over unreliable mobile networks. More than fifteen years later, it is the most widely supported streaming format in the world.

This guide explains how HLS works, what its files look like, why it became dominant, where it falls short, and what you need to publish your own HLS streams.

HLS in one paragraph

HLS breaks a video into short chunks called segments, usually 2 to 6 seconds long, and lists them in a text file called a playlist (with the .m3u8 extension). The same video is encoded at several quality levels, each with its own playlist, and a master playlist lists all of them. The player downloads the master playlist, picks a quality that suits the connection, then downloads segments one after another over normal HTTP. If the connection gets faster or slower, the player switches to a different quality at the next segment. That behaviour is called adaptive bitrate streaming.

Why HLS uses plain HTTP

Before HLS, streaming usually relied on special protocols such as RTMP or RTSP, which needed dedicated streaming servers and often got blocked by firewalls. Apple’s big idea was to use the same HTTP that delivers web pages. That brought major advantages:

• Any web server or CDN can deliver it. Segments are just files. They cache like images.
• It passes through firewalls and proxies because it looks like normal web traffic on ports 80 and 443.
• It scales cheaply. CDNs are built to serve huge numbers of small HTTP files to millions of people.
• It works well on mobile networks, where the connection changes constantly, because each segment is an independent request.

The price for these benefits is latency, which we cover below.

The files that make up an HLS stream

The master (multivariant) playlist

This is the entry point. It lists every available rendition with its bandwidth, resolution and codecs:

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=6000000,AVERAGE-BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2",FRAME-RATE=30
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=3500000,AVERAGE-BANDWIDTH=3000000,RESOLUTION=1280x720,CODECS="avc1.64001f,mp4a.40.2",FRAME-RATE=30
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1600000,AVERAGE-BANDWIDTH=1400000,RESOLUTION=854x480,CODECS="avc1.64001e,mp4a.40.2",FRAME-RATE=30
480p/index.m3u8

Each #EXT-X-STREAM-INF line describes one rendition, and the line after it points to that rendition’s media playlist. BANDWIDTH is the peak bitrate in bits per second, which the player uses to decide what the connection can sustain.

The media playlist

Each rendition has its own playlist that lists its segments in order:

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MAP:URI="init.mp4"
#EXTINF:6.000,
seg0.m4s
#EXTINF:6.000,
seg1.m4s
#EXTINF:4.200,
seg2.m4s
#EXT-X-ENDLIST

#EXT-X-TARGETDURATION is the maximum segment length. #EXTINF gives each segment’s exact duration. #EXT-X-ENDLIST marks the end of an on-demand video. A live playlist has no end tag and is refreshed by the player every few seconds as new segments appear.

You can paste any playlist into our M3U8 analyzer to see these tags explained, and read what is an M3U8 file for a deeper look at the format.

The segments

Segments hold the actual audio and video. HLS originally used MPEG-2 Transport Stream (.ts) files. Since 2016, HLS also supports fragmented MP4 (.m4s or .mp4), which is the basis of CMAF. Fragmented MP4 is now preferred for new deployments because the same files can be shared with DASH and used with all major DRM systems.

How playback works, step by step

1. The player downloads the master playlist.
2. It filters out renditions it cannot decode (using the CODECS attribute) and picks a starting rendition, often a middle one.
3. It downloads that rendition’s media playlist.
4. It downloads the first few segments and starts playing once it has a small buffer.
5. While playing, it measures how fast segments download. If they arrive much faster than real time, it may switch up. If the buffer is shrinking, it switches down.
6. For live streams, it reloads the media playlist regularly to find new segments.

You can watch this happen with our HLS player. Paste a stream URL and the log shows every quality switch.

Where HLS plays

HLS support is close to universal:

• Apple devices: native support in Safari, iOS, iPadOS, tvOS and macOS.
• Android: native support in the platform media player and in ExoPlayer/Media3.
• Desktop browsers: through JavaScript players using Media Source Extensions, including hls.js, Video.js, Shaka Player and commercial players. Chrome has also been adding native HLS playback.
• Smart TVs and streaming devices: Roku, Fire TV, Android TV, Apple TV, Samsung Tizen, LG webOS and most set-top boxes.
• Games consoles and most connected devices.

This reach is the main reason HLS is the default choice for anyone who wants a stream to “just work”.

HLS latency

The biggest criticism of HLS is delay. Classic HLS setups are often 15 to 30 seconds behind real time. The reasons are structural:

• The encoder must finish a whole segment before it can be published.
• Apple’s original guidance recommended the player buffer three segments before starting.
• CDNs and playlist refresh intervals add a little more.

With 6-second segments and a three-segment buffer, you are already at 18 seconds before any network delay. That is fine for films and on-demand lessons, but painful for live sports, auctions, betting or interactive shows where people are chatting with the presenter.

Ways to reduce it:

• Shorter segments, such as 2 seconds, with a matching keyframe interval. This gets you to roughly 6 to 10 seconds.
• Low-Latency HLS (LL-HLS), introduced by Apple in 2019 and now part of the HLS specification. It publishes small “partial segments” and lets players request upcoming parts before they exist. Latency of 2 to 5 seconds is realistic.

Our guide to low-latency streaming compares LL-HLS with LL-DASH and WebRTC.

HLS and security

HLS supports two kinds of protection:

• AES-128 encryption, where segments are encrypted and the key is fetched from a URL. It stops casual downloading but not a determined logged-in user. See AES-128 vs DRM.
• DRM, most commonly FairPlay on Apple devices, and Widevine or PlayReady with CMAF segments. This is what premium services use. See what is multi-DRM.

On top of either, CDNs support signed URLs or tokens so that segments and playlists can only be fetched for a limited time.

HLS vs DASH

MPEG-DASH is the main alternative. It works on the same idea (segments plus a manifest over HTTP) but uses an XML manifest and is an international standard rather than an Apple specification. DASH does not play natively on Apple devices, which is the main reason HLS remains more common. Many services now publish both from the same CMAF files. We compare them in detail in HLS vs DASH.

How to create an HLS stream

For on-demand video

1. Encode your source into a ladder of renditions, such as 1080p, 720p, 480p and 360p. Keep keyframes aligned across renditions. Our encoding settings guide has a ready-made ladder.
2. Package each rendition into segments and generate playlists. FFmpeg can do this directly, and tools such as Shaka Packager, Bento4 and cloud services like AWS MediaConvert do it at scale.
3. Upload the playlists and segments to storage behind a CDN.
4. Embed a player that supports HLS on your site.

A minimal single-rendition FFmpeg example:

ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 21 -g 60 -keyint_min 60 -sc_threshold 0 \
  -c:a aac -b:a 128k -hls_time 6 -hls_playlist_type vod -hls_segment_type fmp4 out/index.m3u8

For live video

Send your camera or encoder output to a media server or cloud service over RTMP, SRT or WebRTC ingest. The server transcodes it into several renditions and publishes a live HLS playlist, which the CDN distributes. Our guide RTMP vs SRT vs WebRTC explains the ingest side, and the bandwidth calculator helps you plan capacity.

Best practices

• Use 2 to 6 second segments, with a keyframe at the start of every segment.
• Include CODECS, RESOLUTION and AVERAGE-BANDWIDTH on every rendition in the master playlist.
• Add #EXT-X-INDEPENDENT-SEGMENTS when every segment starts with a keyframe.
• Prefer fMP4/CMAF segments for new projects.
• Serve playlists with short cache times for live streams and long cache times for VOD segments.
• Set CORS headers on your CDN so web players on other domains can load the stream.
• Test every rendition, not just the top one. A broken 360p playlist will only show up for viewers on bad connections.

Summary

HLS delivers video as short HTTP segments listed in text playlists, with several quality levels the player can switch between. Its reliance on plain HTTP makes it easy to scale through CDNs and lets it play on nearly every device, which is why it dominates streaming. Its main weakness, latency, can be reduced with shorter segments or Low-Latency HLS. If you are publishing video today, HLS is almost certainly part of the answer.