HLS vs DASH: which streaming protocol to use

The short answer

HLS vs DASH is a narrower question than it looks. Much narrower. Both cut video into short segments, both publish a manifest listing them, both let the player switch quality as the connection moves, and both run over ordinary HTTP with no special server. Architecturally the two are near identical twins.

The differences are real but narrow. One reaches more devices. The other bends in more directions. And if you are choosing today rather than in 2016, the honest answer is that the choice matters far less than it used to, for a reason covered near the end.

What the DASH protocol is

DASH stands for Dynamic Adaptive Streaming over HTTP. HLS came from Apple. DASH came from a standards body, published as an international standard in 2012 with a deliberately open remit, and the difference in parentage explains most of what follows.

That origin shows. The manifest is XML rather than the plain text list HLS uses, and it is called an MPD, for Media Presentation Description. It is more capable. It is also far less readable. An HLS manifest can be understood at a glance in a text editor. An MPD generally cannot, and that difference in legibility accounts for a good deal of the affection engineers have for the older format.

The important design decision is that DASH is codec-agnostic. The specification does not say which video codec you must use. It describes how to advertise and fetch segments and leaves the contents to you.

Where they actually differ

Six differences worth knowing, and no others that will change a decision:

Device reach decides most arguments

This settles it in practice. It is not close. HLS works natively on Apple devices. Safari, iPhone, iPad and Apple TV play it without help. DASH does not, and no amount of engineering makes Safari play an MPD natively.

So the reach picture looks like this:

• HLS: native on Apple, native on Android, native on nearly every smart television and set-top box.
• DASH: native on Android, supported in Chrome, Firefox and Edge through JavaScript, absent on Apple.
• Both need a JavaScript library on desktop browsers other than Safari.

For anyone shipping to the general public, that asymmetry ends the discussion. You can reach everybody with HLS alone. You cannot with DASH alone.

Codecs and DRM

Here DASH earns its reputation, and it is worth being precise about how far that goes. Being codec-agnostic meant it could carry newer, more efficient codecs while HLS was still tied to a narrower set, and for a large catalogue a few percent of bandwidth is real money.

That gap has closed. HLS accepts a much wider range of codecs than it once did, and the argument now lands mostly with organisations operating at a scale where small efficiencies compound.

Content protection is sharper. DASH has more native support for a variety of DRM systems, through a common encryption scheme that lets one set of files serve several DRM providers. HLS is tied to Apple's own FairPlay. If you are licensing studio content you will meet this immediately, and it is usually the reason a large service ends up shipping both.

If none of that applies to you, neither does this section.

Why there are two of them at all

Worth a paragraph, because the answer explains the shape of everything above.

HLS came first, in 2009, and it came from one company solving one problem: getting video onto the iPhone over a mobile connection that kept changing quality. It was not designed by committee and it was not designed to be universal. It was designed to work, quickly, on hardware Apple controlled, and that focus is why the manifest is a text file you can read rather than a schema you have to parse.

The rest of the industry then faced an awkward position. The dominant streaming format was a proprietary specification from a competitor, published as an informational document rather than a standard, and evolving at whatever pace suited its author. DASH was the answer: an open standard, developed through a formal process, deliberately free of any one vendor's assumptions. Codec-agnosticism was not a technical whim. It was the point.

Both won something, and neither won outright. DASH became the standard everything except Apple could agree on. HLS kept the devices, because Apple never adopted DASH and nobody could make it. The result is a decade of publishers shipping both, which is exactly the outcome a standard was supposed to prevent, and the reason CMAF was eventually necessary.

HLS vs DASH vs CMAF, and why the choice shrank

The framing of this whole comparison is dated. CMAF is why.

The old problem was duplication, and it was expensive. HLS wanted transport stream segments, DASH wanted fragmented MP4, so serving both meant encoding, storing and distributing every video twice. Double the storage bill, double the cache footprint, and two pipelines to keep in step.

CMAF is a common segment format, and it is not a third protocol. It is an agreement about what the pieces look like, so one set of fragmented MP4 segments can be described by an .m3u8 manifest and by an .mpd manifest at the same time. Same bytes on disk. Same cache entries. Two manifests, which are small text files, pointing at them.

So the modern answer to the question is usually neither:

• Encode once, into CMAF-compatible fragmented MP4.
• Publish an HLS manifest describing those segments.
• Publish a DASH manifest describing the same segments.
• Serve whichever the requesting device can use.

The cost of supporting both used to be an entire second copy of your library. Now it is a second manifest, and manifests are measured in kilobytes.

The two manifests, side by side

Abstractions argue in circles. Files do not. So here they are.

A media playlist, listing three segments:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXTINF:4.000,
segment0.m4s
#EXTINF:4.000,
segment1.m4s
#EXT-X-ENDLIST

The same idea as an MPD:

<MPD mediaPresentationDuration="PT8S" type="static">
  <Period>
    <AdaptationSet mimeType="video/mp4">
      <Representation id="720p" bandwidth="2400000">
        <SegmentTemplate media="segment$Number$.m4s"
                         duration="4" startNumber="0"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

The philosophy is right there. HLS enumerates: every segment gets a line, the file grows with the content, and you can read down it and see exactly what exists. DASH describes a rule: SegmentTemplate says the names follow a pattern and the player can work out the addresses itself, so the manifest stays a fixed size whether the video runs eight seconds or eight hours.

Both cost you something in practice. An HLS manifest for a long recording gets genuinely large, which matters when a player refetches it. A templated MPD tells you what the addresses should be rather than what exists, so a missing segment is not visible in the manifest at all. You discover it when playback stops.

There is a structural difference worth naming too. DASH has a Period, which HLS has no direct equivalent of. It exists so one presentation can splice together separate stretches of content with different properties, and it is the machinery advertising insertion is usually built on.

Latency, and the low-latency versions

Both are late by design. A player wants a few segments buffered before it starts, segments are several seconds each, and the arithmetic lands a viewer somewhere between fifteen and thirty seconds behind the live edge on an ordinary setup.

Both grew a low-latency mode, and they took different routes to it:

• Low-Latency HLS publishes partial segments before the whole segment exists, so a player can begin on a fragment of one.
• Low-Latency DASH leans on chunked HTTP transfer, streaming a segment to the player while the encoder is still producing it.

Both get to a couple of seconds. Both give up the property that made these protocols easy in the first place, because a plain file server is no longer sufficient and the delivery network has to cooperate. That is the trade, and it is the same trade in both cases: you buy latency with infrastructure.

Telling which one a stream uses

Usually the address settles it:

• A URL ending .m3u8 is HLS.
• A URL ending .mpd is DASH.
• An extensionless URL is either, and the response Content-Type tells you: application/vnd.apple.mpegurl for one, application/dash+xml for the other.

Open the file and it is unmistakable. One starts with #EXTM3U. The other opens with an XML declaration and an <MPD> element. There is no ambiguous middle case, because the two formats share no syntax at all despite describing almost exactly the same thing.

Four things people get wrong

• That one is newer. DASH is younger by three years. Both are older than most of the services built on them, and neither is legacy.
• That DASH gives better quality. It does not. Quality comes from the encoder and the bitrate ladder. The protocol carries bytes and has no opinion about how good they look.
• That you must pick one. Large services ship both, and since CMAF that costs a second manifest rather than a second library of files.
• That the protocol causes buffering. Almost never. A stream that stalls instead of softening usually has one rendition in its manifest, so the player has nothing to step down to. That is a publishing decision, and it happens identically under either protocol.

The last one accounts for a striking share of complaints. People blame the format. The manifest names the cause, and counting its renditions takes ten seconds.

Which to use

For most people the answer is HLS. The reasoning takes one line: it reaches every device, and it is the format nearly everything you will encounter already speaks.

More precisely:

• Publishing to a general audience: HLS. Apple support alone decides it.
• Licensed content needing Widevine or PlayReady: DASH, or both.
• Operating at scale where codec efficiency is a budget line: both, over CMAF.
• Testing, debugging or learning: HLS, because you can read the manifest.

One practical note for anyone playing streams rather than publishing them. Whichever protocol a stream uses, a browser will only fetch it if the server sends the header permitting a page from another origin to read the response. That rule applies to an .mpd exactly as it applies to an .m3u8, it is the source's decision rather than the player's, and it is the most common reason a stream that is demonstrably alive refuses to play on a web page.