The short answer

Use M3U if you want the simplest thing that works: one address per line, read in order, understood by almost every player. Use PLS when you are working with a stream that already publishes a PLS file, or when you need titled entries and durations in a format that older Windows players read. Neither format stores media. Both store locations and, optionally, labels.

Structural difference

The difference is not cosmetic. In an M3U file, an entry is identified by where it appears in the file: the line after an #EXTINF tag is the address that tag describes. In a PLS file, the number is written into the key itself, so File2 and Title2 belong together because both end in 2.

M3U PLS
Style Line-by-line list INI file with numbered keys
Header #EXTM3U, optional in practice [playlist], required
How entries link By position in the file By shared number: File2 with Title2
Title After the comma in #EXTINF TitleN
Duration Before the comma in #EXTINF, in seconds LengthN, in seconds; -1 for a stream
Entry count Implied by the file NumberOfEntries
Version None Version=2
Media type No registered type for the playlist itself audio/x-scpls

PLS keys and the section name are case-sensitive, and the format is documented by reverse engineering rather than by a published specification. That last point explains most of the inconsistent behaviour you see between players.

The same two tracks in both formats

As M3U:

#EXTM3U
#EXTINF:180,Opening song
Music/Opening.mp3
#EXTINF:240,Second song
Music/Second.mp3

As PLS:

[playlist]
File1=Music/Opening.mp3
Title1=Opening song
Length1=180
File2=Music/Second.mp3
Title2=Second song
Length2=240
NumberOfEntries=2
Version=2

Note Length1=180 above. A duration of -1 is the conventional way to say the length is unknown, which is what an internet radio stream does: it has no end. A stream entry therefore looks like File1 pointing at a station address with Length1=-1.

Where PLS still appears

PLS was developed for the museArc player and later adopted by SHOUTcast and Icecast, the two systems behind a large share of internet radio. That history is why a radio station's download link is often a small .pls file instead of a stream address: the file contains the address, and the player opens the stream from it. The downloaded file is not the audio.

For local music, PLS is far less common than it once was. Extended M3U gained the same title and duration metadata, so there is usually no reason to choose PLS for a new local playlist.

What breaks in practice

  • A missing NumberOfEntries. Some players ignore the key, others will not load the file without it.
  • Numbering gaps. Renumbering by hand and leaving a gap, such as File1 followed by File3, can truncate the list in a player that counts entries.
  • Case changes. Writing [Playlist] or file1= is not the same as [playlist] and File1=.
  • Titles in the wrong encoding. The VideoLAN wiki notes that a TitleN containing accented or non-Latin characters may not display, and recommends saving the file as UTF-8 when it does.
  • A missing final line break. Some parsers ignore the last line of a file that does not end with one.

What a player actually uses

Only one field is essential: the address. A PLS file with nothing but a [playlist] section and a File1 line is enough to start a stream, which is exactly the shape of the small PLS files radio stations publish.

TitleN is a display label. Changing it changes what the player shows and nothing else; changing FileN changes what plays while the visible title stays the same. That distinction matters when a station renames a channel but keeps the same stream address.

LengthN is advisory. It tells the player how long the track runs, in seconds, and a value of -1 means the length is unknown. Sources that document the format report two behaviours worth knowing: a length shorter than the actual track is ignored, and -1 is ignored too. Do not treat the field as a duration control; it is a hint for the interface.

NumberOfEntries is the one field that behaves inconsistently. VLC requires it, and other players do not. That is why a PLS file can open in one application and appear empty in another with no visible difference between the two attempts.

Symptom and cause

What you see Likely cause
The player opens the file and shows nothing NumberOfEntries missing or lower than the real count
Only the first few entries appear Numbering gap, or NumberOfEntries set to the wrong number
No entries load at all, file looks correct [Playlist] or file1= capitalised differently
Titles show as question marks Encoding mismatch; save the file as UTF-8
The last entry is ignored No line break after the final line
A local track will not play after moving the folder Relative path no longer resolves from the playlist's new location

Writing one by hand

Write [playlist] on the first line, then for each entry a FileN line with a sequential number starting at 1, followed by optional TitleN and LengthN lines carrying the same number. Close with NumberOfEntries set to the last number you used, and Version=2. End the file with a line break. Then open it in the player you intend to use, rather than assuming it will behave the same everywhere.

Which should you use

If a station or service gives you a PLS file, use it as given; converting it usually gains nothing and can lose the title data. If you are writing a playlist by hand for your own files, M3U is shorter to type and easier to read. If you need duration metadata and your player is old enough to predate extended M3U, PLS is the safer choice.

Why it looks like a Windows INI file

A survey of playlist formats by Lars Gonze describes PLS as using the same syntax as a Windows .ini file, and suggests the choice was probably made because the Windows API already provided a way to read that structure. That explains two of the format's habits at once: the bracketed section name, and the flat key-value pairs that are read by name rather than by position.

It also explains why formatting is so fragile. An INI reader looks up NumberOfEntries as a string key. It has no notion of an entry existing because a line follows another line, which is how M3U works. Every link between fields has to be written out in the key name itself.

For a modern application, that is an awkward way to store a list, and it is a fair summary of why PLS stayed in its niche. It persists where the surrounding infrastructure was built around it, which in practice means internet radio.

Converting between them

Converting is mechanical, but do it in a text editor rather than by renaming, because the contents differ. From M3U to PLS: take the address on each line, give it the next number as FileN, move the title from after the #EXTINF comma into TitleN, and put the duration into LengthN. Then set NumberOfEntries to the final count and add Version=2. Going the other way, write #EXTM3U, then for each number write #EXTINF with its duration and title, followed by the address.

Keep a copy of the original before converting. If a player refuses the result, comparing the two files will usually show the mistake: a skipped number, a case change or a title that lost its characters.

Checking the result

The M3U file inspector reads .m3u and .m3u8 files in your browser and lists each line, so it is the quickest way to confirm an M3U file after converting from PLS. It does not open PLS files, and it does not test whether any address is live. For the difference between the two M3U extensions, read M3U vs M3U8; for the XML alternative, read M3U vs XSPF.

Where this information comes from

The PLS structure and key names are described in the VideoLAN wiki entry for PLS and in the Wikipedia article on the format; the reverse-engineering point comes from Lars Gonze's survey of playlist formats. Field behaviour such as Length=-1 is reported by those sources, not by a specification, because PLS has none.