M3U8 vs M3U: what actually differs

The short answer

M3U8 vs M3U comes down to one thing, and it is not what most comparisons lead with. Both serve the same purpose. The difference is thecharacter encoding. An M3U8 playlist is UTF-8. An M3U playlist is whatever the machine that wrote it happened to use, and that is the entire technical distinction.

Everything else people believe separates the two is either a consequence of that, or a convention that grew up around the extensions and was never part of any specification. The syntax is identical. The tags are identical. A parser that reads one reads the other.

The 8 in M3U8 is an encoding, not a feature

The original format arrived with Winamp in the late 1990s and said nothing about how its bytes should be interpreted. That was a reasonable omission at the time. The filenames were ASCII, the playlist never left the machine that made it, and the question did not arise.

It arises constantly now. A playlist is a text file passed between operating systems, servers and players written in different decades, and every one of them has to decide what the bytes mean. Without a declared encoding they guess, and they do not all guess alike.

The 8 in M3U8 is the 8 in UTF-8. It is a promise about the bytes and nothing more. It adds no tag, permits no feature and changes no behaviour beyond that.

Where the difference actually bites

If every name in your playlist is unaccented English, you will never notice which one you have. The distinction only becomes visible when a name is not.

A channel called Télé Monde written by one program and read by another that assumed a different code page comes out as Télé Monde. The playlist still works. The addresses are intact and everything plays. The names are simply wrong, in a way that looks like corruption and is really two programs disagreeing about an alphabet.

Arabic, Cyrillic, Greek, Chinese and Hebrew names fail more completely, often arriving as rows of question marks with nothing recoverable. This is the single practical reason the newer extension exists, and it is why a playlist that will be read by software you do not control should be M3U8 whatever you call it.

What the extension came to imply

Here is where the tidy answer stops being the useful one. When Apple published HTTP Live Streaming it used this format for its manifests and gave them the M3U8 extension. HLS became the ordinary way video reaches a browser, and the extension picked up the association by sheer volume.

So in practice the two names now carry a working expectation that no specification supports. An M3U file is usually a flat list of whole media files, local tracks or channel addresses, meant to be played top to bottom. An M3U8 file is usually a streaming manifest: a list of short segments, or a list of other manifests at different qualities, meant to be reassembled by a player as it goes.

Usually. Not always, and not by rule. Plenty of ordinary playlists are named M3U8 while containing no segments at all, and they are perfectly valid. Judge by the tags inside rather than the name.

Renaming one to the other

Renaming is not converting, and the difference matters. Changing the extension alters the filename and leaves every byte inside untouched, so a file saved in some other encoding is still in that encoding after you rename it. You have relabelled the problem.

Going the other way is usually harmless, because most players do not treat the extension as a promise they will hold you to, and a UTF-8 file is a perfectly good playlist regardless of what it is called. The exception is software that inspects the name to decide which parser to use, and there is more of that about than you would hope.

A real conversion means re-encoding the contents and saving them as UTF-8, which any decent text editor will do from a save dialog. If the names looked wrong before, that is what fixes them.

How to tell whether you have M3U8 or M3U

Not from the filename. That is the point of everything above: the extension records what somebody intended, not what the bytes are, and the two part company routinely.

A text editor is the quickest check. Most show the encoding of the open document in the status bar, and several will offer to reopen it as something else, which is the fastest way to confirm a suspicion about mangled names. On macOS or Linux the command line answers directly:

$ file -I playlist.m3u
playlist.m3u: text/plain; charset=iso-8859-1

$ file -I playlist.m3u8
playlist.m3u8: text/plain; charset=utf-8

A charset of utf-8 means the contents are what an M3U8 file is supposed to contain, whatever the file happens to be called. A charset ofiso-8859-1, windows-1252 or unknown-8bit means it is not, and that names outside plain English are at risk the moment the file travels.

One result deserves care. A file containing only unaccented English is reported asus-ascii, and that is not a problem: ASCII is a subset of UTF-8, so the bytes are already valid either way. It becomes a problem only when someone later adds a name that is not, using an editor that saves in something else.

M3U8 or M3U when you save a playlist

Save as UTF-8, and use the newer extension. There is no case where M3U is technically better, and the failure it invites is silent: names that look fine on the machine that wrote them and wrong everywhere else.

The one caution worth keeping is a byte order mark. Some editors write three invisible bytes at the start of a UTF-8 file to announce the encoding, which is legal, and some strict parsers then fail to recognise the opening #EXTM3U line because those bytes sit in front of it. If a playlist is rejected as malformed and looks correct in an editor, save it again as UTF-8 without a byte order mark. That is the whole of the fix, and it accounts for a surprising share of playlists that appear broken for no reason.