The short answer

A file named .m3u and a file named .m3u8 can contain identical lines. What changed when the second extension appeared is the character encoding: .m3u8 states that the bytes are UTF-8, which is what you need for titles, artist names or channel names outside plain US-ASCII. The .m3u8 extension is also the one HTTP Live Streaming uses, and those playlists add tags of their own. So the honest answer has two parts: the encoding difference applies to every playlist, and the HLS tag difference applies only to streaming playlists.

The one difference that is always true: encoding

The original M3U format never specified an encoding. It was written when a playlist was mostly file paths and short titles in English, so players guessed. Many assumed Latin-1 or Windows-1252, which is why an old .m3u file full of accented characters can open as a row of question marks or garbled symbols.

UTF-8 removes the guess. Every character outside basic ASCII is encoded in more than one byte, and the player is told to expect that. If you open both files in a text editor, they look the same; the difference is in the bytes behind the text, not in the visible structure.

Why the .m3u8 extension exists

Apple developed HTTP Live Streaming, and RFC 8216 documents it. Section 4.1 of that document sets requirements that a plain M3U file was never held to: playlist files must be encoded in UTF-8, must not contain a byte order mark, must not contain UTF-8 control characters apart from carriage return and line feed, and their character sequences must be normalised to Unicode NFC.

The rule about the byte order mark matters more than it sounds. A byte order mark is an invisible marker some editors add at the start of a UTF-8 file. RFC 8216 says clients should fail to parse a playlist that contains one. A file that opens fine in a text editor can therefore fail in a strict player, with nothing visibly wrong.

The registration also settles the extension question: RFC 8216 registers both .m3u8 and .m3u as file extensions, with the media type application/vnd.apple.mpegurl. The convention to use .m3u8 for HLS is exactly that, a convention, not a rule that forbids the older name.

Tags that appear only in HLS playlists

A streaming playlist does more than name files. It tells the player how long each segment is, how often the list refreshes, and which quality levels exist. Those instructions use tags that begin #EXT-X-, and they have no meaning in an ordinary music playlist.

Tag What it does Found in
#EXTM3U Marks the file as an extended M3U playlist. RFC 8216 requires it on the first line. Both
#EXTINF Gives the duration and an optional title for the entry that follows. Both
#EXT-X-TARGETDURATION States the longest segment duration, so the player knows how often to reload. HLS media playlist
#EXT-X-MEDIA-SEQUENCE Numbers the first segment in a live window. HLS media playlist
#EXT-X-STREAM-INF Points to one quality variant and declares its bandwidth. HLS master playlist
#EXT-X-KEY Names the encryption method and where the key lives. HLS, encrypted
#EXT-X-ENDLIST Marks the end of a finished playlist, rather than a live one. HLS, video on demand

A media playlist lists the segments themselves. A master playlist lists other playlists, one per quality level, and lets the player choose. Both are still extended M3U files underneath.

The two files side by side

A music playlist saved as .m3u might contain nothing more than this:

#EXTM3U
#EXTINF:214,First Track
/Users/you/Music/first-track.mp3
#EXTINF:198,Second Track
/Users/you/Music/second-track.mp3

A media playlist from an HLS stream, saved as .m3u8, carries segment durations and reload instructions instead: 

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:1
#EXTINF:9.009,
segment-1.ts
#EXTINF:9.009,
segment-2.ts

A master playlist is shorter, because each entry is another playlist rather than a media file: 

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=1280000
low/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=7680000
high/index.m3u8

Note the duration format. RFC 8216 requires whole-number durations when the playlist declares a compatibility version below 3, and allows decimal durations from version 3 onwards. That is why an older file shows #EXTINF:10, and a newer one shows #EXTINF:9.009,.

The .m3u8 file that is not an HLS playlist

Many .m3u8 files you meet in the wild are ordinary channel lists: a header, a series of #EXTINF lines and stream addresses, with no #EXT-X- tags at all. Those are extended M3U files that happen to be saved as UTF-8. They are valid as playlists, but they are not conforming HLS media playlists, because RFC 8216 requires tags such as #EXT-X-TARGETDURATION in that context.

This is the source of a common confusion. Someone converts a channel list to .m3u8 because a player asked for that extension, and the player still refuses it. The extension was never the missing part.

What actually breaks in practice

  • Garbled titles. A file saved as UTF-8 but opened as Windows-1252 shows the wrong characters for any non-ASCII name.
  • Strict parsers refusing a file. An invisible byte order mark at the start is enough, even when the rest of the file is perfect.
  • Players keyed to the extension. Some apps accept .m3u8 and ignore .m3u when streaming is involved, which is a decision about that app, not about the format.
  • A renamed file that behaves identically. Renaming .m3u to .m3u8 changes the name and nothing else. If the bytes were never UTF-8, the rename fixes nothing.

Which extension should you use

For a local music or video playlist that stays on your own machine, either extension works, and .m3u keeps older players happy. If any title contains characters outside basic ASCII, save as UTF-8 and use .m3u8 so the encoding is unambiguous. For an HLS stream, use .m3u8 and include the #EXT-X- tags the player needs. If you are publishing a stream playlist for other software to read, RFC 8216 is the specification to follow, not a forum post.

How to convert without breaking the file

  1. Open the file in a plain-text editor that shows the encoding, such as Notepad++, VS Code or Sublime Text. Do not use a word processor.
  2. Change the encoding to UTF-8 without a byte order mark and save.
  3. Rename the extension to .m3u8 only if you need it. The rename is optional; the encoding change is the part that matters.
  4. Open the result in a player and confirm that the entries and their titles still appear.

Keep a copy of the original first. Comparing the two files is the fastest way to see whether a character changed during the save.

How to tell which encoding a file already uses

A text editor that shows the current encoding in its status bar will answer this in one look: open the file and read whether it says UTF-8, ANSI, Windows-1252 or Latin-1. If your editor does not show it, open the file and save a copy with a different encoding, then compare the two in a player. Titles that change between the copies were the affected characters.

For a byte-level answer, open the file in a hex viewer and look at the first three bytes. If they are EF BB BF, the file starts with a UTF-8 byte order mark, and RFC 8216 says clients should fail to parse it. Removing those three bytes is safe; removing anything else is not.

One detail catches people out: a playlist containing nothing but basic ASCII is already valid UTF-8. RFC 8216 notes that US-ASCII conforms to its encoding rules. In that case an .m3u file and an .m3u8 file can be byte for byte identical, and the extension is the only thing that differs. That is why renaming sometimes appears to work: the file was never the problem.

Check which one you have

The M3U file inspector opens a .m3u or .m3u8 file in your browser and lists the header, every entry and every attribute, so you can see whether the file carries HLS tags. It does not upload the file or test whether any address is live. For a line-by-line walk through a single example, read anatomy of an M3U file; for the format itself, start with what an M3U file is. For other formats, read M3U vs PLS and M3U vs XSPF.

Where this information comes from

The encoding rules, tag behaviour and extension registration in this guide come from RFC 8216, HTTP Live Streaming (Pantos and May, August 2017), sections 4.1, 4.3 and 9. The M3U format itself has no published specification, so statements about older .m3u files describe what players do in practice rather than a standard.