You tap a video, and it starts playing in a second. You walk into another room, the Wi-Fi weakens, and the picture quietly drops to a softer quality instead of freezing. Walk back, and it sharpens again. No spinner, no interruption. That unremarkable smoothness is HLS streaming doing its work, and it powers most of the video you watch every day.

Here is what HLS is, in plain terms, and why it replaced the old way of serving video files.

The old way: one big file

Originally, web video was a single file on a server. Your player downloaded it progressively: bytes arrived in order, and playback chased the download. It worked, until conditions varied. A big file on a slow connection meant eternal buffering. A small file on a fast connection meant everyone got needlessly blurry video. One file, one quality, no flexibility.

What HLS does instead

HLS, HTTP Live Streaming, was introduced by Apple and became the standard way to serve on-demand and live video over plain HTTP. It splits one video into many small segments, a few seconds each, and encodes them at multiple quality levels: for example 1080p, 720p, 480p, and 360p versions of the same content.

Alongside the segments sits a small text file called a playlist, with the .m3u8 extension, that lists the available qualities and where their segments live. The player reads the playlist, measures the current download speed, and pulls segments from the quality level the connection can sustain, switching up or down as conditions change.

Why this changes everything

Fast startup

The player only needs the first few seconds of one modest quality level before it can begin. No giant file header to fetch, no full download to negotiate. Tap, buffer, play.

Graceful degradation

When bandwidth drops, HLS steps down a rung instead of stalling. Viewers experience slightly softer video rather than a frozen screen, which is the difference between staying and leaving.

Per-viewer quality without per-viewer files

There is exactly one set of segments on the server, and every viewer's player assembles its own path through the ladder. The server stays a dumb static file host, which is why HLS scales beautifully through CDNs.

It rides ordinary HTTP

No special streaming server protocol, no firewall trouble, no exotic infrastructure. Segments are regular files, so any web server, object storage bucket, or CDN in the world can deliver HLS video.

Where you meet HLS every day

Nearly every major video platform serves on-demand video with HLS or its cousin DASH. Video-focused sharing sites use it too: platforms like s.pub transcode uploads into HLS renditions, so a clip shared to a friend on mobile data starts fast and plays smoothly without the sender doing anything technical. Live streams, from sports to phone cameras, run the same architecture with a growing playlist instead of a fixed one.

The trade-offs, honestly

HLS is not free lunch. Segments add a few seconds of latency in live use, which ultra-low-latency protocols then trade quality to reduce. Storage grows with every rung of the ladder you encode. And a broken playlist or a mis-encoded rung produces errors that are more confusing than a file that simply fails to download.

For on-demand web video, though, the trade is overwhelmingly worth it, which is why the industry made HLS the default.

Try it yourself

If you want to see the machinery, it is surprisingly accessible. FFmpeg turns any video into an HLS ladder with one command, producing a master playlist and segmented renditions. Point hls.js, the standard open-source player library, at the playlist in a plain HTML page, and you have built the same delivery architecture the big platforms use, on any static host.

And the next time a video starts instantly on your phone in an elevator, you will know exactly why: not magic, just a few thousand small files and a playlist, quietly adapting to you.