Choosing between HLS and DASH is one of the first decisions in any OTT delivery pipeline. The good news is that with CMAF, you no longer have to choose between them for your media segments. The bad news is that the manifest format still matters, and the choice affects DRM integration, player selection, device compatibility, and operational complexity. This guide walks through the practical differences.
Format origins and current state
HLS was created by Apple and originally used MPEG-TS segments with M3U8 playlists. It has evolved significantly. Modern HLS supports fragmented MP4 segments (fMP4), low-latency extensions, and most of the features that DASH has had for longer.
DASH was developed as an open standard (ISO/IEC 23009-1). It uses MPD (Media Presentation Description) manifests and has always used fragmented MP4 segments. DASH was designed to be more flexible than HLS, supporting features like multi-period content, more granular adaptation sets, and explicit codec and content protection descriptions.
In 2025 and beyond, the practical differences are smaller than they used to be. Both formats support fMP4 segments, both support adaptive bitrate switching, and both handle multi-audio and subtitle tracks. The remaining differences are in manifest structure, DRM signaling, live edge handling, and device compatibility.
Manifest structure compared
HLS M3U8 uses a hierarchical playlist structure. A master playlist lists the available variants (quality levels). Each variant playlist lists the segments for that quality level with their duration and URL.
The format is text-based and line-oriented. It is easy to read, easy to parse manually, and easy to manipulate with simple text tools. This simplicity is both a strength (easy debugging) and a limitation (less expressive than XML for complex scenarios).
DASH MPD uses XML. An MPD describes periods (time intervals), adaptation sets (groups of related streams like video, audio, subtitles), and representations (individual quality levels within an adaptation set). Each representation contains segment information.
MPD is more verbose than M3U8 but more expressive. It can describe complex content structures (multiple periods with different content, multiple audio languages with different codecs) more precisely. The tradeoff is that parsing and debugging MPD is harder than M3U8.
DRM integration differences
HLS with FairPlay is required for Apple devices. The license server URL and certificate are specified in the variant playlist or provided by the player through Apple’s FairPlay Streaming API. FairPlay is the only DRM system Apple supports for HLS on its devices.
DASH with Widevine is the standard for Android, Chrome, and most smart TV platforms. The MPD includes ContentProtection elements that specify the DRM system, the license server URL (often), and initialization data. Players like Shaka Player and dash.js parse these and handle the EME (Encrypted Media Extensions) workflow.
Cross-DRM with CMAF: if you use CMAF segments, you can encrypt content once with a common encryption scheme (CENC or CBCS) and serve it via both HLS and DASH manifests. The segments are identical; only the manifest and the DRM signaling differ. This is the standard approach for services that need to support both FairPlay (Apple) and Widevine (everything else).
Latency characteristics
Standard HLS and DASH have similar latency in standard configurations: typically 15-30 seconds from live edge, depending on segment duration and buffer depth.
Low-Latency HLS (LL-HLS) uses partial segments and blocking playlist requests to reduce latency to 2-4 seconds. The CDN needs to support chunked transfer encoding, and the player needs to handle partial segments.
Low-Latency DASH (LL-DASH) achieves similar latency through chunked segments and availability time offsets in the MPD. The mechanisms are different from LL-HLS, but the end result is comparable.
Which is more mature for low latency? Both work, but LL-HLS has broader player and CDN support as of now, partly because Apple mandated LL-HLS support for App Store submissions targeting Apple devices. LL-DASH is well supported by Shaka Player and dash.js but may require more CDN configuration.
When to use which
Use HLS when:
- You need to support Apple devices (mandatory)
- Your service is primarily consumer-facing and device compatibility is the top priority
- You want simpler manifest debugging during development
Use DASH when:
- You are building primarily for Android, smart TVs, or web browsers
- You need advanced manifest features (multi-period, complex adaptation sets)
- You want fine-grained control over DRM signaling
Use both when:
- Your device matrix includes Apple devices AND Android/smart TV devices (this is most services)
- Use CMAF segments to share encoded media between both formats
In practice, “use both” is the most common answer. The cost of generating two manifest formats from the same encoded source is low compared to the cost of not supporting a major device family.
Operational considerations
Monitoring: track manifest fetch errors and latency separately for HLS and DASH endpoints. A CDN issue might affect one format but not the other if they are served from different origin paths.
Testing: validate playback for both formats on each target device. A device that works with HLS might have DASH-specific issues, or vice versa. Do not assume that if one format works, the other will too.
Migration: if you are moving from one format to another (or adding support for a second format), run both in parallel for a transition period. Use feature flags or device-based routing to gradually shift traffic.