#EXT-X-PLAYLIST-TYPE Explained: VOD, EVENT, and Live Playlist Semantics

An HLS media playlist is a text file listing segments in order. What #EXT-X-PLAYLIST-TYPE declares is what the server promises to do with that file over time — whether it will change, how it will change, and what a player or caching layer can safely assume. Omitting the tag entirely is also a declaration, and it means something specific.

The three playlist states

HLS media playlists operate in one of three distinct modes. The tag determines which:

• No #EXT-X-PLAYLIST-TYPE tag — a live, sliding-window stream. The server appends new segments and removes old ones as the window advances. Players re-poll the manifest every #EXT-X-TARGETDURATION seconds and should never cache the manifest URL. This is the default for broadcast streams.
• PLAYLIST-TYPE:EVENT — an append-only stream. The server may add new segments but must never remove or alter any segment already in the playlist. The full history since the event started remains available for DVR-style seeking. Players re-poll the manifest until #EXT-X-ENDLIST appears.
• PLAYLIST-TYPE:VOD — a static, complete playlist. The server will never modify it. All segments are present, the file ends with #EXT-X-ENDLIST, and the manifest URL is safe to cache indefinitely. This is the expected state for on-demand video.

VOD playlists and caching

A PLAYLIST-TYPE:VOD manifest is immutable by definition. A player that fetches it once has everything it needs — it will never need to re-request the manifest URL because nothing about it will change. CDN edge servers can cache it with long TTLs. A download tool can fetch all segments in a single pass without re-checking the playlist.

This is the normal state for a pre-recorded video served as HLS — a lecture, a film, a podcast episode. The /convert page on this site is built around this assumption: it fetches the playlist once, reads the complete segment list, and downloads everything sequentially. For a proper VOD playlist, this works perfectly every time. The interaction between PLAYLIST-TYPE:VOD and segment containers is covered in MPEG-TS vs. fragmented MP4 in HLS.

EVENT playlists and DVR

The EVENT type is designed for live events with a rewind requirement — a sports broadcast, a conference stream, a webinar where late viewers need to catch up from the beginning. Every segment that has been published stays in the playlist. The manifest grows over time, but the viewer can seek back to any published segment.

Players re-poll an EVENT playlist just as they would a plain live stream, because new segments are still being appended. The difference is that the player knows old segments will not disappear, so it can build a DVR scrubber that reaches all the way to the start. The low-latency aspects of this — how the polling interval is derived and how partial segments interact with the EVENT type — are covered in low-latency HLS explained.

When the live event ends, the server adds #EXT-X-ENDLIST to the playlist. At that moment, the EVENT playlist transitions to being functionally identical to a VOD playlist: static, complete, and safe to cache. Many streaming platforms keep the archived event available as-is at the same URL without re-processing it.

What a download tool sees in each case

For a tool that fetches and saves HLS content, the playlist type changes what the fetch strategy needs to be:

• VOD: Fetch the manifest once, download all listed segments, done. No polling required.
• EVENT (ongoing): The manifest needs to be re-fetched periodically to discover newly appended segments. A tool that fetches the manifest only once will miss everything added after its initial request.
• EVENT (ended / #EXT-X-ENDLIST present): Same as VOD. The full segment list is in the manifest; re-polling adds nothing.
• No type tag (live): Continuous polling is required. Old segments roll off and become unavailable, so a recording tool must keep up in near-real-time or accept gaps. This is the case the /play?broadcast=1 route handles — see live HLS vs. VOD recording for the implications.

Why the tag is optional and often absent

#EXT-X-PLAYLIST-TYPE has been part of the HLS specification since early versions, but many encoder and packaging pipelines omit it even when the playlist is effectively static. A VOD asset encoded and packaged offline often lacks the tag because the encoder never set it — the playlist still ends with #EXT-X-ENDLIST, which is the reliable indicator that no more segments are coming. Players use the presence of #EXT-X-ENDLIST as the practical live-vs-VOD check, not the PLAYLIST-TYPE tag.

The Stream Video Downloader extension detects this by inspecting the playlist text after fetching it: if #EXT-X-ENDLIST is present the stream is treated as on-demand regardless of whether a PLAYLIST-TYPE tag exists; if it is absent the extension marks the stream as live and the popup shows the broadcast indicator.