m3u vs m3u8: the file extension does not tell you the format

file                    named   entries   URL paths ending .m3u8   lines beginning #EXT-X-
playlist_01              .m3u       308                      303                        0
playlist_02             .m3u8     1,895                    1,621                        0
iptv-org-index-sample    .m3u         6                        6                        0

Three files we keep for parser work: two real playlists and a six-entry test fixture. A curated sample, not a random draw from the wild. Hold that in mind while reading every number below. The one named .m3u8 is a channel list of 1,895 rows, each a name and a URL, with no HLS tag anywhere in it. The one named .m3u is also a channel list, and on 303 of its 308 rows the URL path ends .m3u8. Sort the two by their own extensions and you have them backward. Sort them by the extensions of the URLs inside and you call both files HLS, 98.4 percent of one and 85.5 percent of the other, which is wrong twice over.

The extension is a naming convention. It travels with the file, whoever wrote or served it chose it, and nothing enforces it. A parser that trusts it will be wrong on real input. The wrongness is quiet.

RFC 8216 accepts both extensions for the same file#

The document that defines HLS is explicit about this. It says the opposite of the folklore. It is Informational rather than Standards Track, and a revision that would obsolete it, draft-pantos-hls-rfc8216bis, sits in the RFC Editor queue renaming the Master Playlist to the Multivariant Playlist. The rule below survives that rename. Section 4:

Each Playlist file MUST be identifiable either by the path component of its URI or by HTTP Content-Type. In the first case, the path MUST end with either .m3u8 or .m3u. In the second, the HTTP Content-Type MUST be application/vnd.apple.mpegurl or audio/mpegurl. Clients SHOULD refuse to parse Playlists that are not so identified.

Read the two halves. A conformant HLS playlist may be served at a path ending .m3u, one of the two spellings the document names. And the identification is an either/or: a playlist identified by its Content-Type has satisfied the requirement with any path at all, including no extension. So the specification people cite for ".m3u8 means HLS" permits .m3u for HLS and permits a path that says nothing.

The encoding half of the folklore fares no better. The 8 in .m3u8 is widely explained as UTF-8, and section 4.1 does require UTF-8, of every playlist, at either extension: "Playlist files MUST be encoded in UTF-8. They MUST NOT contain any Byte Order Mark (BOM); clients SHOULD fail to parse Playlists that contain a BOM or do not parse as UTF-8." The requirement attaches to the playlist, not to the spelling of its name. All three of our files decode as UTF-8 with zero replacement characters, none carries a BOM, and the one named .m3u has non-ASCII in 24 of its display names, so the extensions tell you nothing here either.

What the specification does use to classify a playlist is its contents. Section 4.1: "A Playlist is a Media Playlist if all URI lines in the Playlist identify Media Segments. A Playlist is a Master Playlist if all URI lines in the Playlist identify Media Playlists." The type is a property of where the URI lines point. The filename is not in that sentence.

The two files have their extensions the wrong way round#

Not one line in any of the three begins #EXT-X-. Not one, across 2,209 entries, and I did not expect that from a file named .m3u8. RFC 8216 inherits exactly two tags from the earlier M3U format, #EXTM3U and #EXTINF, and every tag it defines beyond those two carries the EXT-X- prefix, so the absence is about as close to proof as a corpus gets: these are channel lists built on the two inherited tags plus a directive layer of their own.

The URL suffixes inside the larger file are where the extension story comes apart. Of its 1,895 rows, 1,621 point at a path ending .m3u8. The rest are a spread: 133 rows whose path carries no extension at all, 15 whose last path segment ends in a colon and a port number that Path.GetExtension mistakes for an extension, then 75 ending .php, 17 .mpd, 14 .htm, 7 .ts, 6 .m3u, 3 .2ts, and one row each ending .smil, .dash, .mp4 and .wmv. Seventeen rows end .mpd and one .dash, both naming MPEG-DASH manifests, which are XML and not M3U at all. Six point at another M3U. Two hundred and forty carry a suffix that names no media format.

Across all three files, 1,930 of 2,209 URL paths end .m3u8 and 7 end .ts, which at face value reads as 87.4 percent HLS and 0.3 percent MPEG-TS. Nothing in the files supports that, because none of them was fetched. What the transport turns out to be is a separate subject.

One more shape from the same file, because it matters later. Its #EXTM3U line is 6,294 bytes long, and all but seven of those bytes are an x-tvg-url attribute holding 101 comma-separated program guide addresses. RFC 8216 gives the tag's format as the bare string #EXTM3U, forbids whitespace "except for elements in which it is explicitly specified", and says a playlist violating its rules is invalid and clients MUST fail to parse it. The first line of that file is detectably outside the specification, in a way no HLS playlist would produce. That is a signal, and we do not use it.

Feed an HLS manifest to a channel-list parser and you get three different failures#

Here is a live media playlist, built for this article with a reserved example host and shortened to three segments:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:26401
#EXTINF:10.000,
https://example.com/seg26401.ts
#EXTINF:10.000,
https://example.com/seg26402.ts
#EXTINF:10.000,
https://example.com/seg26403.ts

I ran that through the shipped parser instead of tracing it by hand. Three channels, zero diagnostics.

Line 1 is skipped, because the parser only looks for #EXTINF: and steps over every other # line as an unrecognized directive. Lines 2, 3 and 4 go the same way: #EXT-X-VERSION, #EXT-X-TARGETDURATION and #EXT-X-MEDIA-SEQUENCE are all just hashes to us. Each #EXTINF:10.000, line parses cleanly, since the duration scanner takes 10, the leftover .000 lands harmlessly in the attribute region, and the title after the comma is empty. An empty title becomes the literal string Unnamed channel. Each following line is an absolute HTTPS URL, so it is accepted, and a channel is emitted.

Three channels called Unnamed channel, each pointing at one ten-second fragment of a single stream. No error, no warning, no counter. The import reports success.

Change one thing and the shape changes completely. HLS permits a segment URI to be relative to its manifest (section 4.1) and permits a live server to drop segments off the front as the stream advances (section 6.2.2), and many servers do both, so the lines read seg26401.ts where a full URL stood. Those fail the absolute-URI test, and the same file yields zero channels and three diagnostics reading Skipped non-absolute http(s) URL. A master playlist with absolute rendition URIs fails a third way: it has no #EXTINF lines at all, only #EXT-X-STREAM-INF before each rendition URL, so every URL arrives with no pending header and produces URL without preceding EXTINF (skipped).

Three inputs that are all the same thing, three unrelated outcomes, and not one of them says "this is an HLS manifest." The worst of the three is the one that succeeds. A user who imported a media playlist with absolute segment URIs gets a source that looks populated, and the failure surfaces only when they try to play a row.

The first #EXT-X- line tells you what the file is#

Each of those files announces itself in its first four lines. The test is cheap, it is not the extension, and nothing in our client or our services performs it: read the head of the body and look for a line whose first seven characters are #EXT-X-. Any hit means HLS in practice, since every tag the specification defines past the two it inherited carries that prefix. Two hits are decisive about which kind:

• #EXT-X-TARGETDURATION means a media playlist, a list of segments. Section 4.3.3.1 makes it REQUIRED in one, so its absence carries weight too.
• #EXT-X-STREAM-INF means a master playlist, a list of renditions.

The specification reserves no prefix and keeps no tag registry, so this is a strong convention and not a guarantee: a channel list could carry a stray #EXT-X- line and be misread by the procedure I am recommending. None of ours does.

With no #EXT-X- anywhere, three corroborating shapes back up a channel list. A duration of -1, which all 2,209 of our entries carry, sits outside RFC 8216 grammar, because neither the decimal-integer form nor the decimal-floating-point one takes a minus. Attributes on the #EXTM3U line, as in the 6,294-byte header above. And tvg- attributes between the duration and the comma, a convention with no specification behind it.

Both tags conventionally sit near the top of the file they belong to. RFC 8216 mandates a position for #EXTM3U alone, so a bounded read is a heuristic.

Content-Type is a third opinion and we never asked for it#

RFC 8216 offers Content-Type as the alternative to the path, which sounds like the reliable half until you notice what the either/or permits: a server that identified its playlist by the path may then send whatever header it likes.

We wrote a guard for that. It rejects plainly wrong MIME families before a body is read: HTML, JSON, images, video, fonts, multipart and WebAssembly. Unknown and generic types pass through to the body check, text/plain being the named example. It then carves two exceptions out of its own blanket audio/* rejection: audio/x-mpegurl, on the stated grounds that content delivery networks and static hosting commonly serve playlists as that type, and audio/mpegurl, one of the two types the specification names and which the blanket rule would otherwise refuse. The guard is unit tested and has no production caller. It had one until the thin-catalog change deleted the server-side fetcher that used it.

What does run is a body sniff, and it runs on your device. It skips an optional UTF-8 BOM and any leading whitespace, then accepts the file if the next seven bytes are #EXTM3U or #EXTINF. Executed against the shipped guard, it accepts an HLS master playlist, an HLS media playlist, a channel list with no header line, and a BOM-prefixed file. It rejects an HTML error page and a JSON error body, which is the class of input the Content-Type guard was written for. It also rejects a file whose first line is an ordinary # comment, and RFC 8216 would refuse that one too since it requires #EXTM3U first, so we land in the right place by accident.

Which copy runs matters, and I had it in the wrong place until I walked the call graph. The catalog service carries a twin with a binary layer on top, rejecting null bytes and six magic sequences covering PDF, Windows executables, ELF binaries and three ZIP variants. That layer says whether the file is a disguised binary, never whether it is HLS. And nothing in production reaches it: the only caller of the server twin's content check is an integration test. The check that runs on a real upload is the client's, at CloudSyncUploadService.cs:28, six lines before the plaintext is encrypted, so the bytes a server could sniff are ciphertext by the time they leave your machine.

That sniff reads at most 8,192 bytes, a bound chosen to cap a security check with no thought given to classifying a format. Barely enough. In the 308-row file the first line is 7 bytes and 29 complete #EXTINF lines fit the window, 28 of them with their URL. In the 1,895-row file the first line alone eats 6,294 of the 8,192, leaving 1,898 bytes holding 9 complete #EXTINF lines, 8 of them with their URL. A master playlist fits whole and a media playlist puts #EXT-X-TARGETDURATION in its opening lines, so the window works because of where HLS tags sit. Eight kilobytes is not a principled fraction of a file to read.

The BOM behavior is the part I keep looking at. RFC 8216 says clients SHOULD fail to parse a playlist containing a byte order mark, and the first thing our sniff does is step over one and carry on. Notepad and PowerShell's Out-File write a BOM, and refusing those files would cost a user a working import to satisfy a rule with no practical consequence for us, so we deviate knowingly. It stays a deviation, and a reader building against the specification should not copy it from us.

Register a playlist by URL instead of uploading it and there is no body to sniff, because that registration stores an address as account metadata and fetches nothing. What is left is the extension, and our check runs backward: it fires only when the path already has one, so a URL ending .txt is refused and a URL ending /playlist is accepted unexamined. The rule inspects the URLs that told you something and waves the silent ones through. Cheap typo catcher, useless format check.

The extension in a stream URL is a request, not a description#

Everything above is about the playlist file. The same problem repeats one level down, on the URLs inside it, where it is easier to demonstrate because we write them.

Portal software of the Xtream Codes family builds a live URL as {portal}/live/{user}/{pass}/{streamId}.{ext}, and the extension is the client asking the server which container to send. The same channel is 1234.ts or 1234.m3u8 depending on what you type. Its playlist export endpoint takes the same choice as a query parameter, and the two vocabularies do not match: the path spells it .m3u8, while the community documentation for that API gives the query values as ts, hls and rtmp, defaulting to ts. Our own doc comment at XtreamM3uPlusExportUri.cs:5 writes output=ts|m3u8, a value that documentation does not list, so we ship the confusion in a source file. Nothing about the channel changes, and the extension is only ever a request.

Our repository contains two builders for that URL and they disagree. The one that runs on the device hardcodes .ts. The other appends .m3u8 and has no caller outside its own test. Meanwhile every Xtream source carries a persisted setting for exactly this, surfaced on non-aggregate sources as a two-way control labeled "Stream format", options "MPEG-TS" and "HLS (m3u8)", hint "Container requested from the Xtream portal". Search the desktop client for that field and you find the API contract, the view-model row and the settings dialog, nowhere else. The URL builder does not read it. The playback path does not read it.

So a user can open source settings, switch to HLS, save, reopen the dialog and see HLS selected, and the device will go on requesting .ts for every channel. The value round-trips and changes nothing. What surprised us is that this one is ours, shipped, and nobody noticed: the control was built alongside the persisted field and the builder was never wired to it, so the setting reports a state it does not have, which is worse than not offering it. It turned up while I was gathering evidence for this page, never from a support report, which tells you how visible it is from outside.

The classifiers we do run on those URLs disagree with each other too, in a smaller way. The playback watchdog decides hls or ts by testing whether the whole URI contains the substring .m3u8, so a token in a query string counts. The Stream Information dialog reports a container by uppercasing the extension of the URL path, so a get.php endpoint would show PHP, a .mpd row MPD, and the 15 rows whose path ends in a multicast group and port something shaped like 1:1234. Run both over the 1,895-row file and they disagree on 6 rows, every one carrying .m3u8 inside a query instead of at the end of a path. Six rows is not a crisis, and the watchdog's verdict is telemetry that no threshold reads, so nothing acts on it. It is still two functions in one app answering the same question differently, and neither asks the demuxer, the only component that knows.

The limit is that we hold three curated files. Playlist bytes are read on your device, against the address you point it at, and we curate program guide addresses and never the guide data. So I can tell you what these 2,209 entries look like and what our parser does with a manifest. I cannot tell you how often a .m3u8 URL in the wild returns a channel list, because measuring that would mean pulling playlist bodies from addresses users gave us.

To see what a file actually holds, the Windows and Xbox apps parse it locally and list what came out; a free account is enough to try it against a source you already have.

For anyone writing the parser instead, the rule is narrower than "sniff the body". Decide what the file is from the first tag that can only belong to one format, and make that decision produce a message. The extension and the Content-Type are hints that cost nothing to check and prove nothing when they agree. Ours produces two diagnostics that name the wrong problem and one import that succeeds while being entirely wrong, and it is the third that costs you a support thread.