HLS vs DASH: Key Differences, Latency, and How to Choose

HLS and DASH are the two protocols that deliver most of the video on the internet. Both run over HTTP. Both use adaptive bitrate streaming to adjust quality on the fly. But they were built by different organizations with different priorities — and those differences have real consequences for iOS compatibility, DRM coverage, codec support, and how low your latency can go.

If you’re building a live streaming platform, OTT service, or any product that delivers video at scale, you’ll need to pick a protocol — or support both. This guide covers every dimension that matters: how each protocol works, where they differ technically, and how to make the right call for your specific use case.

What Is Adaptive Bitrate Streaming?

Before comparing the two protocols, it helps to understand what they share.

Both HLS and DASH are adaptive bitrate streaming protocols. The video is encoded at multiple quality levels — called renditions — and the player automatically selects the best one based on the viewer’s available bandwidth. If the connection drops, the player switches to a lower rendition mid-stream. If it recovers, it switches back up.

The result is fewer buffering events and consistent playback across unstable connections. A viewer on a 4K TV with fiber gets the highest rendition. A viewer on mobile LTE gets a lower one. Neither experiences a loading spinner.

The core ABR mechanism is nearly identical in both HLS and DASH. What differs is everything around it: how segments are packaged, what manifest files look like, which devices support each natively, which DRM systems are compatible, and how low the latency floor goes.

What Is HLS (HTTP Live Streaming)?

HLS (HTTP Live Streaming) is a streaming protocol developed by Apple Inc. and released in 2009. It was formalized as RFC 8216 by the IETF in 2017. Apple built HLS to deliver video over standard HTTP web servers — no proprietary streaming server, no special firewall rules, no Real-Time Streaming Protocol connections.

HLS works by breaking the video into small segments and writing a playlist file that references them. That playlist — an .m3u8 file — is plain text. It lists each segment URL, duration, and encryption metadata. The player downloads the playlist first, fetches segments in order, and switches between quality renditions based on throughput. For live streams, the playlist updates continuously as new segments become available.

How HLS works step by step

1. The encoder produces a video stream or processes a file
2. The packager breaks the output into segments — 6 seconds each by default
3. Segments are written as .ts (MPEG-2 Transport Stream) or .mp4 (fragmented MP4) files
4. The packager generates a .m3u8 playlist referencing each segment
5. A master playlist references multiple sub-playlists, one per quality rendition
6. The player downloads the master playlist, selects a rendition, and starts fetching segments
7. For live streams, the playlist refreshes periodically and the player fetches the newest segments

HLS technical specs:
– Manifest format: .m3u8 (plain text M3U playlist)
– Segment container: .ts (legacy) or fragmented .mp4 (modern)
– Default segment length: ~6 seconds
– Codec support: H.264 and H.265 (HEVC) only
– Native support: iOS 3.0+, macOS, Safari — no JavaScript library required
– Standard latency: 15–30 seconds

For a deeper look at how the protocol is structured, see our full guide on how HLS streaming works.

Who uses HLS? Twitch, Apple TV+, ESPN+, and most CDN-based streaming platforms. It’s the default for any app targeting iOS because Apple requires it.

What Is MPEG-DASH?

MPEG-DASH (Dynamic Adaptive Streaming over HTTP) is an international open standard published by the MPEG consortium as ISO/IEC 23009-1. Work on the standard began in 2010 and the first edition was published in 2012. Unlike HLS — which Apple controls — DASH was designed by a consortium that includes Google, Netflix, Microsoft, Samsung, and Adobe.

DASH works on the same principle as HLS: segment the video, generate a manifest, let the player fetch segments and switch quality. But the implementation details differ at every level.

Instead of a .m3u8 text playlist, DASH uses an .mpd file — Media Presentation Description — written in XML. Instead of .ts segments, DASH uses .m4s (MPEG-4 Segment) files. Segment lengths are shorter by default (2–4 seconds is standard), which enables faster quality switching and lower latency.

The most significant technical difference: DASH is codec-agnostic. It doesn’t care whether the video is encoded with H.264, H.265, VP9, or AV1. This gives developers more freedom to choose codecs based on compression efficiency and licensing costs rather than protocol constraints.

How MPEG-DASH works step by step

1. The encoder produces a stream or processes a file
2. The packager breaks it into segments — typically 2–4 seconds each
3. Segments are saved as .m4s (fragmented MP4) files
4. An .mpd manifest is generated in XML, describing all renditions, segment URLs, duration, DRM information, and timeline structure
5. The player downloads and parses the .mpd, selects a rendition, and fetches segments
6. For live streams, the .mpd is updated with new segment references as they’re generated

MPEG-DASH technical specs:
– Manifest format: .mpd (XML-based Media Presentation Description)
– Segment container: .m4s (fragmented MP4)
– Default segment length: 2–4 seconds
– Codec support: Codec-agnostic — H.264, H.265, VP9, AV1, and any codec the player supports
– Native support: Chrome, Firefox, Android — NOT supported natively on iOS or Safari
– Standard latency: 10–20 seconds

Read more about the DASH video format and how it fits into modern streaming architecture.

Who uses DASH? Netflix, YouTube (on non-Apple devices), Amazon Prime Video, and Hulu. YouTube specifically uses DASH to deliver VP9 and AV1-encoded content to Chrome and Android users.

HLS vs DASH: Key Differences

Here’s a direct technical comparison across the dimensions that matter for your architecture:

The single most consequential practical difference: HLS works natively on Apple devices; DASH does not. Safari on iOS doesn’t support Media Source Extensions for DASH. Any app or website targeting iPhone users must support HLS — there’s no workaround at the browser level.

Latency: Standard, LL-HLS, and LL-DASH

Standard HLS was never built for low latency. With 6-second segments plus playlist refresh cycles, end-to-end glass-to-glass latency of 15–30 seconds is common. That’s fine for VOD or pre-recorded content, but unacceptable for live sports where viewers can check social media and see the score before the stream shows the play.

Both protocols now have official low-latency extensions:

LL-HLS (Low-Latency HLS)

Released by Apple in 2019, LL-HLS uses “partial segments” — sub-segments that are exposed to the player before the full 6-second segment finishes writing — along with playlist delta updates that only report new content instead of re-transmitting the full playlist. The result: 2–4 seconds of end-to-end latency with a compatible CDN and player.

LL-DASH (Low-Latency DASH)

LL-DASH uses HTTP chunked transfer encoding to stream segment data to the player while it’s still being generated. Each chunk is transferred as soon as it’s ready, without waiting for the full segment. This achieves 2–3 seconds of latency.

In practice, LL-HLS and LL-DASH deliver roughly equivalent latency. The choice between them comes down to the same factor as the base protocols: device support.

Latency in context

For most live streaming scenarios — sports, concerts, news, live events — LL-HLS or LL-DASH gets latency to a point where viewers aren’t dramatically behind real time. If you need sub-second latency for live auctions, real-time gaming, or interactive broadcasts where the viewer participates, neither HLS nor DASH is the right tool. That’s WebRTC territory.

For a full comparison of these approaches: WebRTC vs HLS for live streaming.

For a complete breakdown of latency trade-offs and when they matter: ultra low latency video streaming.

Browser and Device Support

Device compatibility is where HLS and DASH diverge most sharply — and why the “HLS vs DASH” question often reduces to “does your app need to run on iOS?”

What “via JS library” means: Neither HLS nor DASH has universal native browser support (except Safari for HLS). On desktop browsers, you need a JavaScript player library that uses Media Source Extensions (MSE) to feed video data to the HTML5 <video> element.

The iOS constraint: Apple restricts MSE functionality on iOS entirely, which means no JavaScript player library can play DASH on an iPhone or iPad in any browser — including Chrome for iOS, which runs on Apple’s WebKit engine. This is a platform policy, not a technology limitation someone can engineer around.

Market share reality: Safari accounts for roughly 18–20% of global browser share. On mobile, Safari dominates in high-purchasing-power markets including the US, UK, Australia, and Japan. If you ship DASH-only and a viewer opens your app on an iPhone, they see a broken player. This is why most production streaming systems default to HLS or serve both.

DRM: FairPlay, Widevine, and PlayReady

If your content needs copy protection, protocol choice shapes your DRM options — and your DRM requirements shape which protocols you have to support.

HLS content for Apple devices must use FairPlay — Apple’s proprietary DRM, supported exclusively on Apple hardware and Safari. DASH content uses Widevine (Google’s DRM) and PlayReady (Microsoft’s), standardized through the Common Encryption (CENC) framework.

Reaching all platforms with protected content requires multi-DRM: FairPlay for Apple, Widevine for Google’s ecosystem, PlayReady for Microsoft and Windows devices. CMAF (described below) makes this manageable by sharing the same encoded segments across all three DRM systems.

For more on how multi-DRM architecture works: DRM for video.

CMAF: How the Industry Resolved the HLS vs DASH Debate

CMAF — Common Media Application Format, published as ISO/IEC 23000-19 — is the reason the HLS vs DASH choice is less critical than it was five years ago.

CMAF defines a common segment format based on fragmented MP4. The key: if HLS and DASH both use the same underlying segment format, you can produce one set of encoded segments and serve them with two different manifests — an .m3u8 for HLS clients and an .mpd for DASH clients.

Before CMAF:
– HLS: encode → package as .ts segments → write .m3u8 → push to CDN
– DASH: encode → package as .m4s segments → write .mpd → push to CDN
– Two encode jobs, two segment sets in storage, two CDN origins, double the cost

With CMAF:
– Encode once → package as CMAF/fMP4 segments → write both .m3u8 and .mpd
– One segment set, two manifests, both protocols covered

Apple added fragmented MP4 support to HLS in 2016 — the first step toward CMAF compatibility. By 2019, Netflix, YouTube, and most major CDNs had moved to CMAF as their default packaging format. CMAF also enables LL-HLS and LL-DASH to share the same chunked segments, so you get low-latency delivery on both protocols from a single video transcoding pipeline.

The practical result: if you’re building a streaming system today, you don’t have to choose between HLS and DASH. CMAF lets you output both from one encode. The player on an iPhone requests the .m3u8. The player in Chrome requests the .mpd. Both get the same underlying video segments.

That covers the technical landscape. The next question is how to apply it — and that depends on what you’re building.

How to Choose: HLS vs DASH by Use Case

Building for iOS or a cross-platform mobile app: HLS is required. Apple devices will not play DASH regardless of what JavaScript player you use.

Building a VOD platform targeting only desktop browsers and Android: DASH gives you codec flexibility — including AV1, which delivers 30–50% better compression than H.264 — and shorter default segments for faster quality switching. You’ll need a JS player library in every browser and you’ll miss native iOS support.

Need to reach every device: Use CMAF to serve both HLS and DASH from one encode. Netflix, Disney+, and most major OTT platforms do exactly this. The overhead is minimal — one extra manifest file — and coverage is complete.

Need sub-1-second latency: Neither HLS nor DASH gets you there. Both LL-HLS and LL-DASH floor out around 2 seconds. For interactive use cases — live auctions, real-time Q&A, broadcast-quality video calls — look at WebRTC.

Can You Use Both HLS and DASH? Yes — Here’s How

Supporting both protocols doesn’t require double the infrastructure. With CMAF packaging, you encode once and generate two manifests. Here’s what the pipeline looks like:

1. Ingest: Accept RTMP or SRT input from your encoder or broadcast source
2. Transcode: Encode into multiple renditions (360p, 720p, 1080p, 4K) in a single video encoding pass — one job, all renditions
3. Package: Wrap segments as CMAF/fMP4 chunks with short chunk durations for low-latency support
4. Manifest generation: Write both an .m3u8 (for HLS clients) and an .mpd (for DASH clients) pointing to the same segments
5. Deliver: Push to CDN for video streaming — each player requests whichever manifest it supports

Apple devices request the .m3u8. Chrome, Android, and smart TVs request the .mpd. Both pull the same CMAF segments from the same CDN cache — no separate storage, no separate transcoding.

Here’s a simplified FFmpeg command that generates both HLS and DASH output in a single pass:

ffmpeg -i input.mp4 \
  -c:v libx264 \
  -map 0:v -map 0:v -map 0:v \
  -b:v:0 5000k -b:v:1 2500k -b:v:2 1000k \
  -c:a aac -b:a 128k \
  -f dash \
  -hls_playlist 1 \
  -use_template 1 \
  -use_timeline 1 \
  -seg_duration 4 \
  output.mpd

The -hls_playlist 1 flag tells FFmpeg to generate an .m3u8 file alongside the .mpd from the same packaging run. Both manifests reference the same fMP4 segment files.

How to Implement HLS and DASH Streaming

Building a production-grade CMAF pipeline from scratch — with multi-bitrate transcoding, CDN delivery, DRM integration, and player compatibility across devices — is typically months of engineering work. You need encoding at scale, segment storage, CDN origin configuration, and ongoing compatibility maintenance as player libraries and devices change.

LiveAPI’s live streaming API handles this infrastructure for you. Send a live video signal via RTMP or SRT, and LiveAPI handles adaptive bitrate transcoding and HLS delivery through CDN partnerships with Akamai, Cloudflare, and Fastly — up to 4K quality.

const sdk = require('api')('@liveapi/v1.0#5pfjhgkzh9rzt4');

sdk.post('/videos', {
    input_url: 'rtmp://your-ingest-endpoint/stream-key'
})
.then(res => {
    console.log(res.data.hls_url); // Ready-to-use .m3u8 URL
})
.catch(err => console.error(err));

The response includes a ready-to-use HLS URL (.m3u8) you can drop into any compatible player. You can pass it to your video hosting API workflow or serve it through the embeddable HTML5 player. LiveAPI outputs adaptive bitrate HLS with multiple quality renditions, so viewers get automatic quality switching without you building any of the transcoding logic.

For teams building streaming features into a product — rather than building streaming infrastructure as the product — this cuts setup from months to hours.

Essential Tools for HLS and DASH Delivery

Beyond the protocol, a complete delivery stack needs a few more pieces.

JavaScript Player Libraries

No desktop browser plays HLS or DASH natively except Safari for HLS. You need a JavaScript player library that uses MSE to handle playback.

For most web streaming projects, hls.js handles HLS on non-Safari browsers while Safari handles it natively. If you need both HLS and DASH from a single player, Shaka Player (Google’s open-source player) is the most complete option.

CDN Delivery

Both HLS and DASH run on any standard HTTP CDN. But LL-HLS has specific CDN requirements: it uses HTTP/2 push or partial segment caching that not every CDN supports correctly. Before choosing a CDN for a low-latency live setup, verify it supports LL-HLS blocking origin requests and LL-DASH chunked transfer forwarding.

Encoding and Packaging

Multi-bitrate encoding is the most compute-intensive step. For HLS and DASH delivery, you need:

• Multiple renditions: Typically 3–6 per stream (360p, 720p, 1080p, 4K with appropriate bitrates)
• Keyframe alignment: All renditions must have aligned keyframes at the same intervals for clean ABR switching — every 2–4 seconds for DASH, every 2–6 seconds for HLS
• Codec selection: H.264 for maximum compatibility; H.265 for ~40% better compression with slightly less support; AV1 for best compression but higher encode cost and DASH-only for wide delivery

Getting streaming bit rates right for each rendition — matched to your audience’s typical connection profile — has more impact on perceived quality than which protocol you choose.

HLS vs DASH FAQ

What is the main difference between HLS and DASH?
HLS was developed by Apple and runs natively on iOS and Safari. DASH is an open international standard with codec flexibility but no native Apple device support. HLS uses .m3u8 text playlists; DASH uses .mpd XML manifests. Both use adaptive bitrate streaming over HTTP.

Which is better for live streaming: HLS or DASH?
For a global live audience, use HLS or both via CMAF. LL-HLS and LL-DASH both achieve 2–4 seconds of latency — comparable performance. The deciding factor is your device matrix: if you need iOS, you need HLS.

Does DASH work on iPhone?
No. Safari on iOS doesn’t expose the Media Source Extensions API, which means no JavaScript player library can play DASH in mobile Safari. iPhone and iPad users require HLS. There’s no browser-level workaround.

What is CMAF and how does it relate to HLS and DASH?
CMAF (Common Media Application Format) is a packaging standard that lets you encode video once and serve it via both HLS (.m3u8) and DASH (.mpd) manifests. Both manifests reference the same fragmented MP4 segments. This is now the standard approach at Netflix, YouTube, and most major streaming platforms.

What latency can I expect from HLS vs DASH?
Standard HLS: 15–30 seconds. Standard DASH: 10–20 seconds. LL-HLS: 2–4 seconds. LL-DASH: 2–3 seconds. For sub-second latency, WebRTC is the right technology — neither HLS nor DASH achieves it.

Does YouTube use HLS or DASH?
YouTube uses DASH for most browsers, delivering VP9 and AV1-encoded streams. On iOS and Safari, it falls back to HLS. This is a textbook CMAF dual-manifest setup: one encode, both protocols, every device covered.

Does Netflix use HLS or DASH?
Netflix uses CMAF with both HLS and DASH manifests referencing the same segments. Apple devices get HLS; Android and most smart TVs get DASH. One packaging pipeline covers the full device matrix.

What DRM does HLS use vs DASH?
HLS uses FairPlay for Apple devices (Widevine is also supported on modern HLS for non-Apple platforms). DASH supports Widevine and PlayReady via the CENC standard. Full cross-platform content protection requires multi-DRM: FairPlay for Apple, Widevine for Google’s ecosystem, PlayReady for Microsoft.

Can I use hls.js for DASH streaming?
No. hls.js is HLS-only. For DASH, use dash.js (the DASH Industry Forum’s reference player) or Shaka Player, which supports both HLS and DASH and is generally the better choice when you need both from a single player library.

What codecs does DASH support that HLS doesn’t?
DASH is codec-agnostic and supports H.264, H.265, VP9, AV1, and any codec the player can decode. HLS is limited to H.264 and H.265. If you want to deliver AV1-encoded content — roughly 30–50% better compression than H.264 — you need DASH or a CMAF pipeline with DASH output for non-Apple devices.

The Bottom Line on HLS vs DASH

The core decision comes down to a short checklist:

• Your audience includes iOS/Safari users → Use HLS. There’s no alternative for native Apple device support.
• You need to reach every device → Use CMAF to serve both HLS and DASH. One encode, two manifests, full coverage.
• Apple-free VOD with AV1 or VP9 → Use DASH. Better compression, shorter segments, full desktop and Android coverage.
• Live events with latency requirements → LL-HLS or LL-DASH. Both floor at about 2 seconds.
• Sub-second interactive latency → Neither. Use WebRTC.

With CMAF, the HLS vs DASH debate has largely collapsed for new projects. You pick the right segment format, generate both manifests, and let each device request what it supports.

If you want to ship HLS delivery without building transcoding pipelines, CDN infrastructure, or multi-bitrate encoding from scratch, get started with LiveAPI — it handles the full stack from RTMP/SRT ingest to adaptive bitrate HLS output across a global CDN, and you can push your first live stream in minutes.