HLS Streaming: A Complete Guide to HTTP Live Streaming
Last updated: June 28, 2026
Here is what the name gets wrong: HTTP Live Streaming is not how your camera gets online. It is how the video gets to everyone else. HLS is the format almost every player on Earth can already read, which is exactly why people confuse what it does with what it does not. That universality is what made HLS win, and also what made the name misleading. This guide covers what the glossaries skip: a real manifest you can read line by line, the latency math behind why HLS lags and how LL-HLS is narrowing that gap, and the clean border where HLS stops and ingest begins.
What is HLS?
HLS (HTTP Live Streaming) is an HTTP-based adaptive bitrate streaming protocol that chops video into short segments listed in .m3u8 text playlists, so ordinary web servers and CDNs can deliver live and on-demand video to almost any device. That is the whole trick: no special server, no special port, just files served over ordinary HTTP.
Apple created HLS and first released it in 2009. The protocol is documented in RFC 8216, published in August 2017 and authored by Roger Pantos of Apple and William May of MLB Advanced Media, covering protocol version 7. It is an Informational RFC, so HLS is documented in RFC 8216 and maintained by Apple, not an IETF standard. Apple continues to evolve it through the HLS Authoring Specification for Apple Devices, the living source for encoding ladders, segment rules, and low-latency requirements.
Why did HLS win? Because it rides plain HTTP: firewall-friendly, CDN-cacheable, and the most universally supported playback format in existence. That universality came at a cost: latency.
Ingest versus delivery: what HLS actually does
HLS is a delivery and packaging format, not an ingest format. The word “Live” in the name describes delivering live content to viewers, not capturing it from a camera. This is the single most common misconception about HLS.
Picture the real pipeline. A camera feeds an encoder, the encoder pushes the feed to the platform over RTMP (the ingest leg, sometimes SRT or WebRTC instead), and the platform transcodes and packages that feed into HLS segments plus .m3u8 manifests. A CDN delivers those files over HTTP to each viewer’s player. The standard pattern is RTMP in, HLS out.
RTMP carried Flash video for years and is still the most widely supported way for an encoder to reach a platform. But browsers cannot play RTMP today because Flash is gone, which is precisely why you repackage to HLS for the last mile. Two jobs, two protocols.
Reading a real .m3u8 manifest
Every guide names the playlist. Almost none show you one. A playlist is a UTF-8 text file, and HLS uses two tiers: a Master playlist (Apple now calls it the Multivariant playlist) that lists the available quality streams, and Media playlists that list the actual video segments.
The Master playlist does not point at video. It points at other playlists, one per quality rendition.
#EXTM3U #EXT-X-VERSION:7 #EXT-X-STREAM-INF:BANDWIDTH=2000000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2" 720p.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360,CODECS="avc1.4d401e,mp4a.40.2" 360p.m3u8
Reading top to bottom: EXTM3U is the required first line that marks the file as an extended M3U, and EXT-X-VERSION declares the compatibility version. Each EXT-X-STREAM-INF declares one variant stream with its BANDWIDTH, RESOLUTION, and CODECS, and the line directly under it is that rendition’s own Media playlist URL. That list of variants is the entire basis for adaptive bitrate.
Now a Media playlist, which is what one of those variant URLs returns:
#EXTM3U #EXT-X-VERSION:7 #EXT-X-TARGETDURATION:6 #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:6.000, segment0.ts #EXTINF:6.000, segment1.ts #EXT-X-ENDLIST
EXT-X-TARGETDURATION states the maximum segment length, EXTINF gives the exact duration of the next segment, and the URI line names the segment file. EXT-X-ENDLIST marks this as a finished video-on-demand playlist. A live Media playlist omits EXT-X-ENDLIST and keeps appending new segments as a sliding window, dropping old ones from the front.
One note on containers: segments are historically MPEG-2 Transport Stream files ending in .ts, now increasingly fragmented MP4 packaged as CMAF, the format that lets one set of segment files serve both HLS and DASH. CMAF is a format, not a protocol.
How adaptive bitrate works in HLS
That variant list in the Master playlist is the adaptive bitrate menu, what the industry calls the encoding ladder. Each rung is a distinct combination of resolution, bitrate, and codec. The player measures available bandwidth and switches up or down between renditions at segment boundaries without stalling, climbing to a sharper rendition as bandwidth rises and stepping down before the buffer runs dry. You have used this already: it is the “Auto” quality setting on every video player you know. This is adaptive bitrate streaming.
Two rules from Apple’s HLS Authoring Specification make the ladder work. Adjacent bitrate rungs should sit roughly 1.5x to 2x apart, which avoids both visible quality gaps and ladder bloat. And every rendition must be time-aligned, with a keyframe at each segment boundary, so the player can switch seamlessly. The tradeoff: more rungs mean smoother adaptation but more video to encode and store, and because HEVC reaches a given quality at a lower bitrate than H.264, the whole ladder shifts with the codec you choose.
Why HLS is slow, and how LL-HLS fixes it
Classic HLS lags for two reasons, and neither is your hardware. Both are protocol choices.
The first is packaging delay: a 6-second segment costs up to 6 seconds of wait before a player is allowed to request it. The second is the player buffer: classic HLS players hold roughly three segments before playback begins, about 18 seconds of cushion against network jitter. Together those mechanics push glass-to-glass latency to roughly 15 to 30 seconds for standard HLS on default settings, a range that follows from the segment-and-buffer mechanics documented in RFC 8216 and Apple’s authoring guidance. Shortened segments can pull the floor toward 6 seconds.
Low-Latency HLS (LL-HLS), introduced by Apple in 2019 and now part of the HLS Authoring Specification, attacks both causes while keeping the HTTP and CDN model intact. It works through four mechanisms:
- Partial segments, the EXT-X-PART tag. Publish and play a fraction of a segment before the whole segment exists, with the spec targeting roughly 0.2 to 0.5 seconds per part. This is the key lever, because it dismantles the packaging delay.
- Preload hints, the EXT-X-PRELOAD-HINT tag. Tell the player the URL of the next part before it exists, so its request is already in flight the moment the part is ready.
- Blocking playlist reload. The player requests the next playlist version and the server holds the request open until it is ready, replacing wasteful polling.
- Playlist delta updates. The server sends only the changed tail of the playlist instead of the full file each time.
The result is glass-to-glass latency of around 2 to 5 seconds. LL-HLS pairs naturally with chunked CMAF, where each segment is split into chunks as small as a single frame and pushed as it is produced. This is low latency streaming territory.
| Tier | Typical glass-to-glass latency | How |
|---|---|---|
| Standard HLS | 15 to 30 seconds | 6-second segments, roughly 3-segment buffer |
| Tuned HLS | 6 to 10 seconds | 2 to 4-second segments, smaller buffer |
| LL-HLS | 2 to 5 seconds | partial segments plus preload hints plus blocking reload |
| WebRTC | under 1 second | real-time UDP transport (a different protocol) |
The tradeoff is unavoidable: lower latency means a smaller safety buffer, less forgiving of network jitter. You trade resilience for immediacy, and the right point depends on the content.
HLS versus RTMP, DASH, and WebRTC
Four protocols come up constantly, and they do not all do the same job.
| Protocol | Role | Typical latency | Playback support | Best for |
|---|---|---|---|---|
| HLS | Delivery | 6 to 30s; 2 to 5s with LL-HLS | Universal (native on Apple, hls.js elsewhere) | Scalable live and VOD to any device |
| MPEG-DASH | Delivery | Same as HLS; LL-DASH about 2 to 3s | Broad, but not native on Apple or Safari | Codec-agnostic delivery, non-Apple stacks |
| RTMP | Ingest (first mile) | About 1 to 5s contribution | Not playable in browsers | Encoder to platform |
| WebRTC | Real-time delivery and ingest | Under 1 second | Browser-native | Interactive and conferencing |
HLS and DASH are technical twins: both slice video into segments and list them in a manifest delivered over HTTP, so the mechanics are nearly identical. The real split is reach: HLS is Apple-native and universally supported, while DASH is codec-agnostic and open but not native on Apple devices. CMAF resolves much of the rivalry by letting one set of files feed both.
RTMP is the ingest leg, not a viewer format. WebRTC is the genuine low-latency alternative, delivering under a second over real-time UDP transport, and it can ingest too (WHIP, the WebRTC-HTTP Ingestion Protocol, was standardized as RFC 9725 in March 2025). But it trades away simple CDN scaling and broad VOD support, so it is the choice for real-time interaction, not a replacement for one-to-many HLS broadcast.
HLS players: native versus hls.js
HLS playback splits into two worlds. The first is native HLS. Safari on macOS, iOS, and iPadOS plays an .m3u8 straight from a video element’s src attribute, and native apps lean on AVPlayer on Apple platforms and ExoPlayer or Media3 on Android.
The second world is hls.js, the browser workhorse. It is an open-source JavaScript library (the video-dev/hls.js project) that plays HLS in browsers which lack native HLS but support Media Source Extensions: Chrome, Firefox, and Edge on desktop. Under the hood, it fetches the playlist and segments, transmuxes MPEG-2 TS into fragmented MP4, and feeds the result to the video element through the MSE SourceBuffer API. No plugins, no Flash.
The caveat that trips people up: MSE is not available in iOS Safari on the iPhone, so there hls.js cannot run and you fall back to native HLS on the video tag. As of June 2026 some Chrome and Edge builds have begun shipping native HLS support, but hls.js remains the portable answer. The practical pattern: if the browser plays HLS natively, hand it the .m3u8; otherwise instantiate hls.js.
Encryption and DRM: three tiers
Content protection in HLS comes in tiers, and the cleanest distinction is this: encryption means the key travels in or near the manifest, while DRM means the key lives in secure hardware.
The first tier is AES-128 segment encryption, signalled by EXT-X-KEY with METHOD=AES-128. Each whole segment is encrypted with a 128-bit AES key the manifest points to. It defeats casual copying, but the key is a readable network request, so it is not studio-grade protection. The second is SAMPLE-AES, which encrypts individual media samples rather than whole segments, works with fragmented MP4, and leaves the container structure parseable. The third tier is full DRM through FairPlay, Widevine, or PlayReady, all of which manage keys inside a hardware-backed secure environment so the key never reaches the network. Apple FairPlay uses AES-128 in CBC mode (the HLS-native path); Widevine and PlayReady use AES-128 in CTR mode (the DASH and CENC world).
The tradeoff is cost: stronger protection adds licensing fees and integration work, so match the tier to the content’s value.
How WpStream delivers with HLS
WpStream is a WordPress live-streaming and pay-per-view plugin, and it is the publisher of this guide. It maps onto the pipeline described above: broadcasters ingest over RTMP from the encoder of their choice (OBS, vMix, Wirecast, or StreamYard), and WpStream transcodes and packages that feed into adaptive-bitrate HLS, then delivers it across a multi-CDN. Encryption, DRM, and CORS access control protect the stream, and WooCommerce handles pay-per-view or subscription gating on top.
Latency through this path is a few seconds, a different thing from the generic standard-HLS figure quoted earlier. Before you go live, run the WpStream speed tester at https://speedtest.wpstream.live/, since it measures against the actual ingest infrastructure. Stay below the upload rate it reports and test at your real peak time. One plan note: the free plan supports external RTMP and OBS ingest only and up to 50 concurrent viewers (as of June 2026), while browser broadcasting and content protection are paid-tier features. You can compare tiers on the WpStream site.
Key Takeaways
- HLS delivers video over HTTP by slicing it into short segments listed in .m3u8 playlists, which lets any CDN serve live or on-demand video to almost any device.
- RTMP handles ingest from encoder to platform; HLS handles delivery from platform to viewer. Separate jobs, separate protocols.
- LL-HLS uses partial segments and preload hints to reduce glass-to-glass latency to roughly 2 to 5 seconds, compared to 15 to 30 seconds for standard HLS on default settings.
- HLS content protection ranges from AES-128 segment encryption for casual copy prevention to FairPlay, Widevine, or PlayReady DRM for studio-grade key management.
- WpStream ingests over RTMP and packages adaptive-bitrate HLS for delivery across a multi-CDN, with WooCommerce pay-per-view and subscription gating built on top.
HLS FAQ
Is HLS free to use?
The HLS specification is open and documented in RFC 8216, so the protocol itself costs nothing. What you pay for is the transcoding, packaging, and CDN delivery around it, which a platform like WpStream handles for you.
Does HLS work on Android?
Yes. Android apps typically use ExoPlayer or Media3 for HLS, and mobile browsers fall back to hls.js or native support. WpStream’s player handles that selection automatically.
What is the difference between HLS and .m3u8?
HLS is the protocol; .m3u8 is the text playlist file format that HLS uses to list streams and segments. WpStream generates those playlists for you whenever you broadcast.
Can HLS do low latency?
Yes, through LL-HLS, which uses partial segments and preload hints to bring glass-to-glass latency to roughly 2 to 5 seconds. WpStream delivers live streams with a latency of a few seconds.
Is HLS better than RTMP?
They do different jobs: RTMP is for ingest, HLS is for delivery. Most platforms, WpStream included, use RTMP in and HLS out rather than choosing one over the other.
Where HLS goes next
HLS keeps narrowing the latency gap, with LL-HLS and chunked CMAF pulling glass-to-glass toward a handful of seconds, and transports like Media over QUIC hint at what comes next. The name still misleads, though, and the lesson holds: HLS is about delivery, not capture. If you would rather not wire the RTMP-in, HLS-out pipeline yourself, WpStream runs that whole path so you can focus on what you put in front of the camera.