HLS vs DASH: Which Streaming Protocol Should You Use?

If you are building anything that streams video, you will quickly hit this question: HLS or DASH? Both split video into small segments delivered over HTTP. Both support adaptive bitrate, live and on-demand, DRM and multiple audio tracks. Both are used by the biggest services in the world. So what actually differs, and which should you pick?

The honest answer for most projects in 2026 is “both, from the same files”. But the details matter, especially if you are starting small. This guide lays out the differences, then gives a clear recommendation for common situations.

The one-minute summary

• HLS (HTTP Live Streaming) was created by Apple. It plays natively on every Apple device and almost everything else. Text-based .m3u8 playlists.
• DASH (Dynamic Adaptive Streaming over HTTP) is an international MPEG standard. It plays on Android, smart TVs and in browsers through JavaScript players, but not natively on Apple devices. XML .mpd manifests.
• With CMAF fragmented MP4 segments, you can publish both from one set of media files.

If you can only pick one today, pick HLS, because it reaches more devices without extra work. If you use DRM across Android, browsers and Apple, plan for both.

Side-by-side comparison

Device support: the deciding factor

Device reach decides more HLS vs DASH debates than any technical detail.

Apple devices, which account for a large share of mobile viewing in many markets and dominate in some, play HLS natively and have not supported DASH natively. In Safari on macOS and iOS, a <video> tag can load an .m3u8 URL directly. For DASH, you would need a JavaScript player using the Managed Media Source API, which only arrived with iOS 17.1 and is still less common.

Everywhere else, both work. Android’s media stack handles both. Desktop browsers play both using JavaScript players. Smart TV platforms generally handle both, although some European broadcast TV standards, such as HbbTV, specifically require DASH.

So: HLS covers everything with one format. DASH covers everything except Apple.

Manifests: text vs XML

HLS playlists are simple line-based text files. They are easy to read, easy to generate with a script, and easy to debug by eye. A master playlist lists renditions, and each rendition has its own media playlist. You can explore one with our M3U8 analyzer.

DASH uses a single XML manifest that describes everything: periods, adaptation sets, representations and segment addressing. It is more verbose but also more expressive. Multi-period content, rich metadata, and precise segment timelines are natural in DASH. For a detailed walkthrough, see what is MPEG-DASH.

In practice, you rarely write either by hand. Packagers generate them. The practical difference is debugging: HLS problems are usually easy to spot in a text editor, while DASH problems sometimes need a validator or a detailed look at timing attributes.

Codecs

DASH is codec-agnostic by design, and services that adopted VP9 and AV1 early often used DASH for them. HLS historically centred on H.264 and AAC, then added HEVC in 2017, and AV1 support on newer Apple hardware. Today both formats can carry H.264, HEVC and AV1 in fMP4 segments. The real limit is the viewer’s device, not the protocol. See H.264 vs H.265 vs AV1 and test your own device with the codec support checker.

DRM

This is where “both” becomes the natural answer.

• FairPlay (Apple) works with HLS only.
• Widevine and PlayReady are traditionally delivered with DASH, and can also be delivered with HLS using CMAF segments.

A typical premium service therefore serves:

• HLS with FairPlay to Apple devices.
• DASH with Widevine to Chrome, Firefox and Android.
• DASH with PlayReady to Edge, Xbox and many TVs.

With CMAF segments encrypted using the cbcs scheme, all three share one set of encrypted files. Only the manifests differ. We explain this in what is multi-DRM and Widevine vs FairPlay vs PlayReady.

Latency

With classic settings, both protocols sit 10 to 30 seconds behind live, mostly because of segment duration and player buffering. Both have low-latency modes:

• LL-HLS publishes partial segments (#EXT-X-PART), uses preload hints and blocking playlist reloads.
• LL-DASH uses chunked CMAF delivered with HTTP chunked transfer encoding, so the player receives each chunk as soon as it is encoded.

Both reach about 2 to 5 seconds in production. If you need sub-second latency for interaction, neither is the right tool, and you should look at WebRTC. Our guide to low-latency streaming compares the options.

Ads and monetisation

Both support server-side ad insertion (SSAI), where ads are stitched into the stream so they play like content. HLS uses discontinuity tags and, more recently, HLS Interstitials. DASH uses multiple periods and in-band events. Both can carry SCTE-35 ad markers from broadcast workflows. Ad tech vendors support both, so this rarely decides the question.

Cost and complexity

If you publish only HLS, you package and store one set of playlists. Adding DASH with CMAF adds only a manifest per title, because the segments are shared. Storage and CDN costs barely change.

If you still use MPEG-TS segments for HLS, adding DASH means a second set of fMP4 segments, roughly doubling storage for the packaged output. That is the main reason to migrate HLS to fMP4/CMAF before adding DASH.

Many video platforms and cloud services (such as AWS MediaPackage and similar) can also generate HLS or DASH on the fly from a single stored source, which removes the storage question entirely.

Recommendations by situation

Small site, marketing videos, lessons without DRM Use HLS only. It plays everywhere with hls.js as a fallback on desktop browsers that lack native support.

Online course or membership platform with DRM Use CMAF segments with cbcs encryption, HLS manifests for Apple devices (FairPlay), and DASH manifests for everything else (Widevine, PlayReady). Or use HLS with all three DRMs if your player supports it.

Streaming service targeting TVs, especially in Europe Support both. Some TV platforms require DASH, and Apple TV requires HLS.

Live sports or events with low latency LL-HLS for Apple and broad reach, and consider LL-DASH for Android and TV if your vendor supports it. Keep segment and part durations consistent across both.

Interactive live video (auctions, betting, video calls) Neither. Use WebRTC for the interactive audience, and optionally HLS for large passive audiences.

Testing both

Once you have a stream, check it in real players:

• Paste an .m3u8 URL into the HLS player.
• Paste an .mpd URL into the DASH player.

Both tools show every rendition and log errors, so you can confirm that each quality level plays and switches correctly.

Player support in practice

The protocols are only as good as the players that use them. The main open-source web players support both:

• hls.js: HLS only, very widely used, excellent LL-HLS support.
• dash.js: DASH only, the DASH-IF reference player, strong LL-DASH support.
• Shaka Player (Google): both HLS and DASH, strong DRM support, used by many large services.
• Video.js: both, through its VHS engine, with a large plugin ecosystem.

On mobile, AVPlayer on iOS plays HLS natively, while Media3/ExoPlayer on Android plays both. Commercial players such as Bitmovin, THEOplayer and JW Player support both formats with DRM across web, mobile and TV.

If you pick Shaka Player or Video.js on the web, switching between HLS and DASH later is mostly a configuration change, which reduces the risk of choosing wrong.

Migration paths

• HLS-only today, DASH later: move HLS segments to fMP4/CMAF first. Then adding DASH is just generating an MPD for the same files.
• DASH-only today, adding Apple devices: generate HLS playlists for your CMAF segments, and add FairPlay with cbcs encryption if you use DRM.
• TS-based HLS and separate DASH: consolidate on CMAF to halve packaged storage and improve CDN cache hit ratios.

Summary

HLS and DASH are more alike than different. HLS wins on native device reach, especially Apple. DASH wins on openness and flexibility, and is required on some TV platforms. With CMAF you do not have to choose: encode once, package once, and publish both manifests. If you are just starting, launch with HLS, move to fMP4 segments early, and add DASH when DRM or TV platforms call for it.