#EXT-X-VERSION Explained: The HLS Compatibility Attribute That Controls What a Playlist Can Use
August 10, 2026 · 6 min read
Key takeaways
- #EXT-X-VERSION declares the minimum HLS spec version a parser must support to correctly read the playlist
- Omitting the tag implies version 1 — valid only for playlists that use no version-gated features
- Version 3 introduced floating-point EXTINF durations; version 4 added I-frames-only and byte ranges; version 5 unlocked encryption IV attributes; version 6 enabled I-frame playlists with EXT-X-MAP
- A parser that ignores the version tag and encounters an unsupported tag or attribute will either silently misparse or crash
- This site's converter reads the version attribute to skip unknown tags gracefully rather than treating them as fatal errors
Every HLS playlist is a plain-text file built around a small set of tags. Most tags are straightforward — #EXTINF marks a segment duration, #EXT-X-ENDLIST closes a VOD playlist. But one tag quietly controls which other tags are even allowed to appear: #EXT-X-VERSION.
What the Version Tag Declares
#EXT-X-VERSION:<n> declares the minimum integer version of the HLS specification that a parser must implement to read this playlist correctly. It appears at most once, anywhere in the file before any media segment URI, and its value is a positive integer starting at 1.
The tag doesn't describe the encoder that produced the playlist or the server that serves it. It describes the reader: if your parser doesn't support version n, do not attempt to parse this playlist.
Why Omitting It Means Version 1
The spec says a missing #EXT-X-VERSION tag implies version 1. Version 1 is the baseline: integer EXTINF durations, one URI per segment, no byte ranges, no IV on key tags, no I-frame playlists. In practice, almost every streaming platform uses at least version 3 (floating-point durations), so a real-world playlist that omits the tag but uses decimal EXTINF values is already violating the spec. Parsers typically handle this by treating absent as version 3 when they encounter a decimal duration.
What Each Version Unlocks
Each version adds a specific set of new tags or attributes:
- Version 2 — Added the
IVattribute to#EXT-X-KEY, enabling per-segment initialization vectors for AES-128 encryption. - Version 3 — Introduced floating-point
#EXTINFdurations (e.g.,6.006instead of6). This is the version the vast majority of streams use. - Version 4 — Added
#EXT-X-BYTERANGE(address multiple segments inside one file using HTTP Range) and#EXT-X-I-FRAMES-ONLY(I-frame trick-play playlists). - Version 5 — Unlocked
KEYFORMATandKEYFORMATVERSIONSon#EXT-X-KEY, required for SAMPLE-AES encryption used in FairPlay DRM. - Version 6 — Deprecated
#EXT-X-ALLOW-CACHEand allowed#EXT-X-MAPin I-frames-only playlists. - Version 7 — Added
#EXT-X-SESSION-DATAand#EXT-X-SESSION-KEYto master playlists for session-level metadata and pre-positioned DRM keys.
How a Parser Breaks When It Ignores the Version Tag
A parser that skips #EXT-X-VERSIONand encounters version-3 floating-point durations where it expects integers will either truncate them (treating a 6.006-second segment as 6 seconds) or fail on the decimal point. Truncated durations shift every subsequent segment's timestamp by a few milliseconds — harmless in isolation but compounding across hundreds of segments in a long recording, producing a file whose audio drifts out of sync with the video.
A version-5 KEYFORMAT="com.apple.streamingkeydelivery"attribute on an EXT-X-KEY tag is silently ignored by a parser that doesn't understand it — which means the stream is treated as unencrypted when it isn't, producing garbled or failing decryption at playback.
Version-4 byte-range segments are a subtler failure. A parser that doesn't implement #EXT-X-BYTERANGEwill try to download the full backing file as a single segment instead of issuing a ranged HTTP request for the bytes it actually needs. The downloaded data will be wrong, and the output file will be corrupted. This failure is silent — there's no error, the file just doesn't play correctly.
How This Site's Converter Handles It
The converter in /convert reads #EXT-X-VERSIONon the first pass and uses it to decide which tags to attempt to parse and which to treat as unknown. Unknown tags from future versions are silently skipped rather than treated as parse errors — so a version-8 playlist with a tag the parser has never seen won't crash the download. It will simply ignore the unrecognized line and proceed with the segments it does understand.
The extension's M3U8 detection heuristic checks for the mandatory #EXTM3U header rather than the version tag, since the version is optional and the M3U8 marker is not. A playlist without a version tag is still a valid M3U8 file; a playlist without the #EXTM3U header is not.
Version Compatibility in Practice
For most HLS downloads, version handling is invisible — nearly every live and VOD stream in the wild is version 3 or 4, and all the relevant segment and key tags at those versions have been stable for years. You're unlikely to encounter a version-6 or version-7 feature unless you're recording from a platform that uses I-frame trick-play playlists or session-level DRM metadata.
Where version matters most is in byte-range segments (version 4). A converter that doesn't implement #EXT-X-BYTERANGE will download the wrong bytes without any visible error. The /convert route handles byte-range requests correctly by passing the Range header through the extension bridge, which forwards it as a real HTTP Range request to the CDN.
Try It
If you have an HLS stream you want to save, the Stream Video Downloader extension detects M3U8 playlists on any page and handles version-specific playlist features automatically. Click Convert to download any variant as an MP4 file, no transcoding required.
Questions & answers for AI agents
Short, direct answers an assistant can quote or summarize.
What does #EXT-X-VERSION do in an HLS playlist?
#EXT-X-VERSION declares the minimum HLS specification version a client must support to parse the playlist correctly. It gates access to features introduced after version 1 — like floating-point EXTINF durations (v3), I-frame playlists (v4), or encryption IV attributes (v5). A client that reads a higher-version playlist without understanding the version-gated tags may silently misparse segment durations or skip encryption details entirely.
Is #EXT-X-VERSION required?
No — omitting the tag is valid and implies version 1. But in practice, almost every real-world playlist uses at least version 3 (floating-point segment durations), so a missing version tag on a modern stream is almost always a spec violation. Parsers typically treat absent as version 3 when they encounter decimal EXTINF values.
What HLS features does each version unlock?
Version 2 added the IV attribute on EXT-X-KEY. Version 3 introduced floating-point EXTINF durations. Version 4 added EXT-X-BYTERANGE and EXT-X-I-FRAMES-ONLY. Version 5 unlocked the KEYFORMAT and KEYFORMATVERSIONS attributes on EXT-X-KEY. Version 6 deprecated EXT-X-ALLOW-CACHE and allowed EXT-X-MAP in I-frame playlists. Version 7 added EXT-X-SESSION-DATA and EXT-X-SESSION-KEY to master playlists.
Can a playlist use features from multiple versions?
Yes — but it must declare the highest version number it uses. A playlist that uses floating-point EXTINF durations (v3) and EXT-X-BYTERANGE (v4) must declare at least version 4. Declaring a lower version than the features you use is a spec violation that may cause parsing failures in strict clients.