HLS vs MPEG-DASH: Which Live Streaming Protocol to Use?

HLS vs MPEG-DASH is a choice between reach and control. Use HLS (HTTP Live Streaming) when your viewers include iPhones and Safari, because Apple devices play it natively. Use MPEG-DASH (Dynamic Adaptive Streaming over HTTP) when you control every player, as in Android and smart TV apps. To serve both, package one set of segments with two manifests.

This guide is for developers choosing a delivery format for a live or on-demand streaming product. It compares the two protocols on the points that decide a build: native playback, codecs, content protection and latency. It also covers details that change the answer today: native HLS in desktop Chrome, how iPhones handle DASH, the playlist rule that sets standard HLS latency, and what it takes for one set of segments to serve both manifests. For how HLS itself works, see what HTTP Live Streaming is and how it works.

HLS and MPEG-DASH are both HTTP-based adaptive streaming protocols. The server cuts video into short segments at several bitrates, a manifest lists them, and the player downloads segments over ordinary HTTP and switches bitrate as the network changes. That shared model is how adaptive bitrate streaming picks a rendition. The protocols differ in who defines them, what the manifest looks like and which devices play them without extra code.

What is HLS?

HLS is Apple's HTTP-based adaptive streaming protocol. Apple released it in May 2009, according to Wikipedia's HLS entry, and it is documented in RFC 8216, published by the Internet Engineering Task Force (IETF) in 2017. Its manifests are M3U8 text playlists: a multivariant playlist that lists the renditions, and a media playlist for each rendition that lists its segments. Segments are MPEG-2 transport stream (TS) files or fragmented MP4 (fMP4) files. Apple's HLS Authoring Specification adds the stricter rules that Apple devices expect.

What is MPEG-DASH?

MPEG-DASH is an international standard for HTTP-based adaptive streaming. It was developed by the Moving Picture Experts Group (MPEG) and published as ISO/IEC 23009-1 in April 2012, according to Wikipedia's DASH entry. The MPEG-DASH standard page describes it as a suite of standards for streaming over existing HTTP infrastructure such as servers and content delivery networks (CDNs). Its manifest is the Media Presentation Description (MPD), an XML document, and the same Wikipedia entry notes that DASH is codec-agnostic.

HLS vs DASH compared

The table compares HLS vs DASH on the criteria that usually decide a streaming build, as of 25 September 2026.

Criterion	HLS	MPEG-DASH
Defined by	Apple; RFC 8216, plus Apple's HLS Authoring Specification	MPEG; ISO/IEC 23009-1
Manifest	M3U8 text playlists	MPD, an XML document
Segment format	MPEG-2 TS or fMP4	fMP4 or WebM, among others
Video codecs	On Apple devices: H.264, HEVC, Dolby Vision or AV1	Codec-agnostic; the device's decoders set the limit
Native browser playback	Safari, iPhone Safari, Chrome 142 and later, Chrome for Android	None; needs a JavaScript player
Content protection	FairPlay Streaming on Apple devices; Common Encryption in fMP4	Encrypted segments, played through the browser's Encrypted Media Extensions (EME)
Low-latency mode	Low-Latency HLS (LL-HLS) with partial segments	Low-latency DASH with Common Media Application Format (CMAF) chunks

Sources for each row are linked in the sections below. Most DASH vs HLS decisions turn on the native playback row, because it decides whether an Apple viewer needs any extra code.

One encode, two manifests: the same fMP4 segments can be listed in an M3U8 playlist for HLS players and in an MPD for DASH players.

Which browsers and devices play HLS and DASH natively?

Native HLS playback now reaches beyond Apple. According to caniuse's HLS table, read 25 September 2026, Safari on macOS and iOS, desktop Chrome from version 142 and Chrome for Android play an M3U8 URL set directly on a video element. Firefox and Edge do not. Everywhere else, HLS plays through a JavaScript library built on Media Source Extensions (MSE), the browser API that lets a script feed media segments to a video element.

Native support is not the same as reliable support. The hls.js documentation notes that Chrome 147 reports HLS support but may fail to play certain streams natively, so it recommends trying hls.js first and falling back to native playback.

No browser plays an MPD from a plain video tag. MPEG-DASH on the web always runs through an MSE player such as dash.js, maintained by the DASH Industry Forum (DASH-IF). For Android apps, Wikipedia's DASH entry notes that DASH is available through ExoPlayer.

iPhones are the hard case for DASH. caniuse's MSE table lists full MSE support only on iPadOS 13 and later, not on iPhone. Safari offers ManagedMediaSource instead, which MDN marks as limited availability and experimental. hls.js documents support for Safari on iOS 17.1 and later through it. A DASH player on an iPhone depends on that same API, while HLS needs no library there at all.

DASH vs HLS: Where each one breaks?

DASH vs HLS failures show up in different places: HLS breaks on latency at default settings, and DASH breaks on Apple devices.

HLS: latency at standard settings. Apple's authoring specification says target durations SHOULD be 6 seconds (requirement 7.5). RFC 8216, section 6.3.3, says a live client SHOULD NOT start playback less than three target durations from the end of the playlist. With 6-second segments, a standard HLS player therefore starts at least 18 seconds behind the newest segment, before encoding and delivery delay. LL-HLS shortens this with partial segments. The current HLS draft, draft-pantos-hls-rfc8216bis-22 (May 2026), says the low-latency hold-back SHOULD be at least three part durations, so 1-second parts give a hold-back of at least 3 seconds. For the setup differences, see HLS vs LL-HLS.

HLS: container rules on Apple devices. Apple's specification allows TS or fMP4 for H.264 but requires fMP4 for HEVC and AV1 (requirements 1.2, 1.5 and 1.39). A TS-only pipeline cannot use the newer codecs on Apple devices.

DASH: Apple devices and player code. Every DASH viewer on the web needs a JavaScript player, and on iPhones that player depends on ManagedMediaSource. A product that ships DASH therefore still needs HLS for Apple devices.

DASH: latency is the same arithmetic. DASH has no lower latency by design. The dash.js low-latency guide works through 8-second segments: a player that joins 3 seconds into a new segment and starts from the last complete one ends up 11 seconds behind live. With 1-second CMAF chunks, it can start inside the segment still being written and sit about 3 seconds behind. dash.js has supported CMAF low-latency streaming since version 2.6.8.

DASH: codec freedom stops at the decoder. A codec-agnostic manifest does not make a device decode VP9 or AV1. The player can only choose among renditions the device supports.

MPEG-DASH vs HLS: Which should you use?

MPEG-DASH vs HLS comes down to who your viewers are and who controls the player. Use this rule by use case:

1. Audience includes iPhones, iPads or Safari, and you want one format: use HLS. It plays natively on Apple devices and, with hls.js, in every browser that has MSE.
2. You ship your own apps on Android, smart TVs or set-top boxes, or need a codec outside Apple's HLS list, such as VP9: use DASH for those players, and keep HLS for Apple devices.
3. You need both: package once as fMP4 and write two manifests (see the packaging section below).
4. Viewers must talk back in under a second, such as co-hosts or live bidding: neither protocol fits at standard settings; use Web Real-Time Communication (WebRTC) for those participants, as covered in WebRTC vs HLS for live streaming.

Both are delivery protocols. Ingest protocols such as the Real-Time Messaging Protocol (RTMP), Secure Reliable Transport (SRT) and the WebRTC-HTTP Ingestion Protocol (WHIP) carry the stream from the encoder to the server; HLS and DASH carry it from the server to viewers.

How one set of segments serves both HLS and MPEG-DASH

The DASH video format has two parts, an MPD and the media segments it lists, and HLS has the same shape with M3U8 playlists. HLS accepts fMP4 segments (RFC 8216, section 3.3), and fMP4 is also a DASH segment format, so one set of fMP4 files can sit behind both manifests. MPEG's Common Media Application Format standard (ISO/IEC 23000-19) was written for this case. Its 2017 white paper says CMAF fragments are encoded independently of the delivery protocol, so segments can be delivered once to CDN edge servers and served from cache to many players.

For the shared segments to also play on Apple devices, these rules from Apple's authoring specification apply to every rendition:

• Segment length: target durations SHOULD be 6 seconds (requirement 7.5), and a segment MUST NOT exceed the target duration by more than 0.5 seconds (7.7).
• Keyframes: key frames SHOULD be present every 2 seconds (1.13), so each 6-second segment can start on one.
• Audio and video in step: audio and video playlists MUST use the same target duration and contain the same duration of content (8.2 and 8.3).
• Encryption: video encrypted with Common Encryption MUST use a 1:9 encrypt:skip pattern (13.7). The CMAF white paper describes Common Encryption as letting one encrypted presentation be protected by different DRM systems, so check that each DRM system your DASH players use accepts that pattern.

The packaging tool or media server then writes an M3U8 playlist set and an MPD that point at the same files, as the diagram above shows.

Choosing an HLS player and a DASH player for the web

A web page needs an HLS player for browsers without native support and a DASH player for every browser. The two examples below adapt the official quick starts.

HLS with hls.js, trying the library first and falling back to native playback, as its documentation recommends:

<video id="video" controls></video>
<script src="https://cdn.jsdelivr.net/npm/hls.js@1"></script>
<script>
  const video = document.getElementById("video");
  const src = "https://example.com/live/master.m3u8";
  if (Hls.isSupported()) {
    const hls = new Hls();
    hls.loadSource(src);
    hls.attachMedia(video);
  } else if (video.canPlayType("application/vnd.apple.mpegurl")) {
    video.src = src;
  }
</script>

DASH with dash.js:

<video id="player" controls></video>
<script src="https://cdn.dashjs.org/latest/modern/umd/dash.all.min.js"></script>
<script>
  const player = dashjs.MediaPlayer().create();
  player.initialize(document.getElementById("player"),
    "https://example.com/live/manifest.mpd", true);
</script>

The third argument to initialize() is autoPlay, per the dash.js type definitions. Pin a specific release in production instead of latest or @1, so a new version cannot change playback without a test.

Where HLS and DASH sit in an interactive live streaming build

An interactive live app usually has two paths. Hosts and co-hosts talk over WebRTC. A server then composites the room into one stream and packages it for the large audience, and that packaging step is where HLS or DASH is chosen. The viewer's player has to match that output.

In VideoSDK, the audience path is HLS. The Start HLS guide (updated 4 September 2026) calls startHls() with a config that sets the layout, theme, mode and a quality of "low" (SD), "med" (HD, the default) or "high" (FHD). The interactive livestream overview (updated 10 July 2026) says the stream is delivered as an M3U8 playlist that adapts resolution to the viewer's network. The docs do not describe a DASH output.

For playback, the Setup HLS Player guide (updated 4 September 2026) listens for the hls-state-changed event, waits for HLS_PLAYABLE, and passes playbackHlsUrl to hls.js, with the same Hls.isSupported() check and native fallback shown above.

The hosts' WebRTC codec is a separate choice from the HLS output. The JavaScript SDK's custom video track guide (updated 11 September 2026) supports VP8 (the default), H264, VP9 and AV1, and says multiStream, its simulcast setting, is not supported for VP9 and AV1.

Glossary

Multivariant playlist (master playlist): The top-level HLS playlist that lists each rendition's bitrate, resolution and codecs, and points to one media playlist per rendition.

MPD (Media Presentation Description): The XML manifest of an MPEG-DASH stream, describing its periods, adaptation sets and segments.

fMP4 (fragmented MP4): An MP4 file split into movie fragments, each with its own index, so a player can fetch and play it piece by piece.

CMAF (Common Media Application Format): An MPEG format for fMP4 segments and chunks that both HLS and DASH manifests can reference.

Target duration: The maximum segment length an HLS media playlist declares, in whole seconds, which players use to decide how far behind live to start.

MSE (Media Source Extensions): The browser API that lets JavaScript players such as hls.js and dash.js append media segments to a video element.

ManagedMediaSource: A variant of MSE in which the browser can evict buffered media; Safari supports it, and web players use it on iPhones.

Key takeaways

• HLS vs MPEG-DASH is a reach-versus-control choice: HLS plays natively on Apple devices and, as of 25 September 2026, in desktop Chrome 142 and later, while MPEG-DASH needs a player library in every browser.
• On Apple devices, HLS accepts H.264, HEVC, Dolby Vision and AV1, so codec support alone rarely forces DASH.
• Latency comes from segment duration and hold-back, not the protocol name: 6-second HLS segments put a standard player at least 18 seconds behind the newest segment, and both protocols have chunked low-latency modes.
• Packaging once as fMP4 lets the same segments serve an M3U8 playlist and an MPD.

If your audience includes Apple devices, start with HLS and add DASH only for players you control. To see how an interactive live stream becomes HLS output in VideoSDK, start with the interactive livestream HLS guide.

Frequently asked questions

Which MPEG-DASH player should you use in a browser?

Use dash.js, the open-source player maintained by the DASH Industry Forum, unless you already license a commercial player. It plays MPEG-DASH in any browser that supports Media Source Extensions and plays protected content through Encrypted Media Extensions. Load it, create a player with dashjs.MediaPlayer().create(), and call initialize() with your video element and MPD URL.

Does the MPEG-DASH protocol work on iPhone?

Not natively. iPhone Safari cannot play an MPD from a video tag, and caniuse lists full Media Source Extensions support only on iPadOS, not iPhone. A web DASH player on iPhone depends on Safari's ManagedMediaSource, which MDN marks as limited availability. HLS plays natively on iPhone, which makes it the practical format for iPhone viewers.

Is DASH lower latency than HLS?

Not by design. Both protocols deliver segments over HTTP, and latency depends on segment duration and how far behind live the player starts. With 6-second segments, a standard HLS player starts at least 18 seconds behind the newest segment, and DASH follows the same arithmetic. Both have low-latency modes: LL-HLS partial segments and low-latency DASH with CMAF chunks.