MIME Types for Video Streaming: HLS, DASH, and WebRTC
Video streaming formats each require a specific MIME type to work correctly. Progressive download video uses video/mp4 with byte-range support. HLS (HTTP Live Streaming) requires two MIME types: application/x-mpegURL for the .m3u8 manifest file and video/mp2t for the .ts segment files.1 DASH (Dynamic Adaptive Streaming over HTTP) uses application/dash+xml for the .mpd manifest.2 MSE (Media Source Extensions) streaming uses video/webm or video/mp4 as the source buffer type. Getting any of these types wrong causes streaming failures that range from silent video player stalls to explicit iOS Safari errors that reject HLS streams entirely. Apple mandates specific MIME types for HLS, and iOS Safari is particularly strict about enforcing them. Consequently, configuring MIME types for a video streaming server is a prerequisite for testing across all target platforms, not an afterthought.
HLS MIME type requirements
Apple defined HLS and mandates specific MIME types for the two file types it uses. The .m3u8 playlist file, which lists stream variants and segment URLs, must be served as application/x-mpegURL. Some implementations also accept application/vnd.apple.mpegurl, which Apple recognises as an alias. The .ts segment files containing the MPEG-TS encoded video must be served as video/mp2t. iOS Safari enforces these types strictly: serving .m3u8 as text/plain or video/mp4 causes the native HLS player to reject the stream without a useful error message.1 Building on this, Android browsers and desktop browsers use JavaScript HLS libraries like hls.js that fetch manifests and segments directly via the Fetch API. These libraries are more tolerant of incorrect MIME types than iOS Safari, which can mask configuration errors that only surface on iOS devices. Verify MIME types on iOS Safari specifically as part of HLS deployment testing.
DASH manifest serving and segment delivery
MPEG-DASH manifests are XML documents served with Content-Type: application/dash+xml. The manifest file conventionally uses a .mpd extension. The DASH segments themselves are typically fragmented MP4 files and use video/mp4 or audio/mp4 depending on track type. CORS headers are required when DASH segments are loaded cross-origin by Media Source Extensions: the segment server must send Access-Control-Allow-Origin for the player page origin.2
Byte-range delivery for DASH segments
DASH players request specific byte ranges of segments to support adaptive bitrate switching. The segment server must support 206 Partial Content responses for Range header requests. Without byte-range support, the player must download entire segments before playback, breaking adaptive bitrate behaviour. Verify byte-range support with curl -r 0-1 -sI against a representative segment URL and confirm the response is 206, not 200.
MSE and Media Source Extensions API
The Media Source Extensions API builds a video stream in the browser from JavaScript-provided data. A SourceBuffer is created with addSourceBuffer(), which requires a MIME type string specifying both the container and codec. For MP4 video: 'video/mp4; codecs="avc1.42E01E"' creates a source buffer for H.264 baseline MP4. For WebM video: 'video/webm; codecs="vp9"' creates a VP9 WebM buffer. The MIME type string passed to addSourceBuffer() must exactly match the codec and container of the segments you append, otherwise the browser rejects the segments.3 Consequently, this is a code-level MIME type declaration rather than a server header. For audio-only MSE streams, use 'audio/mp4; codecs="mp4a.40.2"' for AAC in MP4. Building on this, isTypeSupported() checks whether the browser can handle a given MIME type string before attempting to create a source buffer, enabling graceful degradation when a specific codec combination is unavailable.
VP9 and AV1 in WebM containers for open-codec streaming
VP9 inside a WebM container uses the MIME type video/webm; codecs="vp9" for MSE source buffer creation. Browser support for VP9 in WebM is broad: Chrome, Firefox, and Edge have supported it since 2015, and Safari added VP9 support in version 14.1.4 AV1 in WebM uses video/webm; codecs="av01.0.08M.08" (the full AV1 codec string carries profile, level, and bit depth), and Safari added AV1 playback support in version 17.5 Both codecs deliver better compression than H.264 at equivalent quality, making them worth including in an adaptive bitrate ladder alongside H.264 for clients that cannot use them.
MediaSource.isTypeSupported() accepts the full codec string including parameters, so your player code can query support before registering a source buffer. Querying video/webm; codecs="av01" returns false in Safari 15 and true in Safari 16, giving you a reliable branch condition. When AV1 is unsupported, falling back to the VP9 source buffer requires only changing the codec string in the addSourceBuffer() call; the streaming infrastructure remains identical because both codecs share the WebM container.
Open-codec streaming server configuration
Serving WebM files requires video/webm in your server's MIME type table. Apache's default mime.types file includes this mapping, but Nginx's default mime.types file did not include video/webm in older distributions. On Nginx, add video/webm webm; to the types block and reload. For CDN origins, confirm the origin passes the correct Content-Type before enabling CDN caching, since CloudFront and Fastly cache responses including their Content-Type and will serve the cached value to all edge nodes regardless of origin changes made after the first cache fill.
CMAF and fragmented MP4 for unified HLS and DASH delivery
Common Media Application Format (CMAF) uses fragmented MP4 as the container for both HLS and DASH segments, replacing the TS container for HLS and the WebM or MP4 container for DASH with a single file format that both protocols consume. Fragmented MP4 segments use the video/mp4 MIME type for video tracks and audio/mp4 for audio tracks when referenced from manifests. Using fMP4 segments reduces storage costs because a single segment file serves both HLS and DASH players without transcoding differences between formats.
HLS manifests using fMP4 segments require version 7 or later in the #EXT-X-VERSION tag. Each segment group needs an initialisation segment referenced by an #EXT-X-MAP tag pointing to a separate .mp4 file that contains the codec initialisation data without media samples. Clients that cache the initialisation segment and reference it across multiple media segments avoid re-fetching the codec setup data on every ABR quality switch.
Low-Latency HLS partial segments and MIME requirements
Low-Latency HLS (LL-HLS) introduces partial segments declared with the EXT-X-PART tag, each carrying a small portion of a full segment to reduce end-to-end latency below two seconds.6 Partial segments are fMP4 fragments and use video/mp4 as their Content-Type like regular segments. Your CDN must support the _HLS_msn and _HLS_part query parameters that LL-HLS clients append to playlist requests for blocking playlist reloads; Cloudflare's LL-HLS support handles these parameters natively, but custom origin servers must implement the blocking reload response pattern to avoid clients falling back to regular HLS latency.
The fMP4 container used by partial segments means the byte-range and caching rules that apply to regular HLS also apply here, so a CDN that mishandles Range requests degrades LL-HLS as badly as it does standard HLS. Testing partial segment delivery with a player that reports segment fetch timing exposes the regression before users notice added latency; why iOS Safari rejects HLS streams almost always traces back to a wrong MIME type. CapyToolkit's MIME reference documents the video/mp4 Content-Type so the fMP4 fragments carry the type the player expects.
When to use this
Use this guide when configuring a server for adaptive bitrate video streaming with HLS or DASH, debugging video playback failures on iOS Safari, or implementing Media Source Extensions streaming in a custom video player.
Examples
Nginx: add HLS and DASH MIME types
Required for HLS and DASH manifests and segment files to be served with correct types.
Test HLS manifest MIME type with curl
iOS Safari requires application/x-mpegURL for .m3u8 files. Verify before testing on device.
MSE: create source buffer with codec string
addSourceBuffer() requires both container and codec in the MIME type string.
- 1.
Apple, "HLS Authoring Specification for Apple Devices," developer.apple.com, accessed June 2026. https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices
- 2.
"application/dash+xml," IANA, iana.org, accessed June 2026. https://www.iana.org/assignments/media-types/application/dash+xml
- 3.
W3C, "Media Source Extensions," w3.org, 2024. https://www.w3.org/TR/media-source/
- 4.
WebKit, "New WebKit Features in Safari 14.1," webkit.org, 2021. https://webkit.org/blog/11648/new-webkit-features-in-safari-14-1/
- 5.
WebKit, "WebKit Features in Safari 17.0," webkit.org, 2023. https://webkit.org/blog/14445/webkit-features-in-safari-17-0/
- 6.
Cloudflare, "Vary for Images: Serve the Correct Images to the Correct Browsers," blog.cloudflare.com, 2021. https://blog.cloudflare.com/vary-for-images-serve-the-correct-images-to-the-correct-browsers/