Two answers to the same problem
Both HLS (HTTP Live Streaming) and DASH (Dynamic Adaptive Streaming over HTTP) solve the problem described in adaptive bitrate: deliver video as a series of small files over ordinary web servers, and let the player choose among several quality versions. Neither needs a special streaming server; both work with regular HTTP delivery and content delivery networks, which is a large part of why they spread.
Where they differ is in who created them, how they describe the available video, and which devices support them natively.
Origins
HLS was introduced by Apple and is closely associated with its devices and software. Its specification has since been published openly, and it is supported well beyond Apple products.
DASH was developed through the MPEG standards body and published as an international standard. It was designed as a vendor-neutral alternative. Being a standard does not by itself mean every device supports it equally, however, and in practice adoption has varied by platform.
How they describe the video
Each protocol uses a manifest, a small text document the player reads first.
- HLS uses playlists, historically with the .m3u8 extension. A top-level playlist lists the available versions, and each version has its own playlist listing its segments in order.
- DASH uses a Media Presentation Description, an XML file with the extension .mpd. It describes the versions and how segment addresses are formed, sometimes by a template rather than a long explicit list.
For the viewer none of this is visible. For engineers, the differences affect how flexible the description is and how easy it is to generate and cache.
Segment formats and the role of CMAF
Early HLS typically used MPEG transport stream segments, while DASH typically used fragmented MP4. This used to mean a service wanting both needed two sets of media files, doubling storage and caching.
HLS later added support for fragmented MP4, and a common packaging format called CMAF was defined to be usable by both. With CMAF, a service can store one set of media segments and publish two small manifests, one for each protocol. That reduces storage and improves cache efficiency, which matters at scale, as discussed under streaming costs. It also relates to container formats more generally, since the segment wrapper determines what a player can parse.
Encrypted content adds a wrinkle. Different DRM systems favour particular encryption modes, so shared files only work when the encryption approach suits the target devices. This is covered in the discussion of DRM protection.
Codecs
HLS and DASH both carry video that has been compressed by a codec; they do not define the compression itself. DASH is generally described as codec-agnostic, and HLS can carry several widely used codecs, though what a given player will actually decode depends on the device. A stream using the H.264 codec has very broad support, while the HEVC codec, the VP9 codec and the AV1 codec depend more on platform and hardware. So protocol and codec support are two separate checks.
Device and browser support
This is where practical differences are sharpest, and where the details change over time.
- Apple devices and Safari have long played HLS natively.
- Many other browsers do not play either protocol directly in a plain video element; web players commonly use JavaScript libraries that fetch the segments and feed them to the browser. Such libraries commonly handle both protocols.
- Many smart televisions, set-top boxes and Android devices support one or both through their built-in players or approved player libraries.
Support lists are changeable, so anyone planning a deployment should check current documentation for the devices they target rather than rely on a general rule. Connected TVs in particular can be a mix of older and newer hardware, which makes broad compatibility a real planning issue.
Latency
Both protocols were first designed for reliability and scale rather than minimum delay, so classic live streaming with either tends to run well behind real time. Both have since developed low-latency variants that use smaller parts of segments and tighter delivery. The topic is covered in stream latency. Neither protocol is meant for the interactive, sub-second use cases that WebRTC calls address.
Features that differ in practice
- Ad insertion and timed metadata. Both support marking points in a stream for ads or events, in different ways. Details matter for services using server-side ad insertion.
- Multiple audio and subtitle tracks. Both can offer alternative languages, and both can reference subtitle or caption files in several forms, with differences in which formats are well supported.
- Trick play and thumbnails. Seek previews and similar extras are handled in different, often vendor-specific, ways.
So which one?
For most small publishers the answer is that the choice is made by a platform or hosting service rather than by them. A platform will usually produce whatever each device needs and hide the protocol entirely.
For teams building their own delivery, a common approach is to package once with a shared segment format and publish both manifests, then let each player pick whichever it handles best. The decision tends to follow the audience’s devices, DRM needs and the engineering team’s tools, not an intrinsic superiority of one protocol. A fair summary is that they are more alike than different, and that the differences show up mainly in compatibility, tooling and edge features.