Relative vs Absolute Paths in M3U Files, and Why Your Playlist Breaks When You Move It
Short answer: An absolute path encodes the full location of a file from the root of your filesystem. A relative path encodes the location relative to the playlist file itself. Absolute paths break when anything in that chain moves. Relative paths survive, as long as the playlist and the music travel together.
What an M3U file actually is
An M3U playlist is a plain text file. Open one in a text editor and you will see something like this:
#EXTM3U
#EXTINF:214,Artist Name - Song Title
/home/bret/Music/Artist Name/Album/01 Song Title.flac
#EXTINF:187,Artist Name - Second Track
/home/bret/Music/Artist Name/Album/02 Second Track.flac
The lines starting with # are metadata. Everything else is a path telling your player where to find the audio. Those paths are what break.
Absolute paths
An absolute path starts from the root of the filesystem and spells out every step to the file.
On Linux and macOS that looks like:
/home/bret/Music/Artist/Album/track.flac
On Windows it looks like:
C:\Users\Bret\Music\Artist\Album\track.flac
The path is self-contained. Your player reads it, walks from the root, and finds the file. Simple. The problem is that every element in that chain is load-bearing. Move the music to a different drive, rename a parent folder, or open the playlist on a different machine, and the path resolves to nothing. Your player reports the file as missing, and it is right, just not where the playlist said it would be.
The other problem with absolute paths is that they are machine-specific. /home/bret/ means nothing on a computer where the home directory is /home/alice/ or C:\Users\alice\. A playlist built with absolute paths on one machine will not play on another without editing every single line.
Relative paths
A relative path does not start from the root. It starts from the location of the playlist file itself and describes how to get to each track from there.
If your playlist lives at /home/bret/Music/playlists/summer.m3u and a track lives at /home/bret/Music/Artist/Album/track.flac, the relative path from the playlist to the track is:
../Artist/Album/track.flac
The .. means "go up one folder." So the player reads the playlist, notes that the playlist is in /playlists/, goes up one level to /Music/, then navigates down to Artist/Album/track.flac.
The advantage is portability. As long as the playlist and the music maintain the same relationship to each other, the relative path still works. Move the entire /Music/ folder to a different drive, copy it to a NAS, or hand it to a friend, and the playlist travels with it intact.
The limitation is that everything has to share a common root. If your tracks are scattered across multiple drives, there is no single relative path that can describe all of them from one playlist location. Each track's path would have to resolve from the same starting point.
How to tell which type your playlist uses
Open the M3U in a text editor and look at a track line. If it starts with a drive letter (C:\) or a forward slash (/), it is absolute. If it starts with ../ or a folder name with no leading slash, it is relative.
A few edge cases worth knowing:
- Windows sometimes uses
file:///C:/Users/...URLs in playlist files. These are absolute, just URI-encoded. - Some players write bare filenames with no path at all, which implies the file is in the same folder as the playlist. That is technically relative, and very fragile.
- Mixed playlists, some absolute paths and some relative, are possible if you assembled tracks from different sources. They tend to behave unpredictably.
Converting between the two
There is no standard command-line tool that does this cleanly across platforms, but the logic is straightforward.
Absolute to relative: For each track path, find the common prefix between the playlist's folder and the track's folder. Strip that prefix from both, count the remaining folders in the playlist path to know how many ../ steps to prepend to the track path.
Relative to absolute: Resolve each relative path against the playlist's current folder location. The result is the absolute path.
In practice, most people either do a targeted find-and-replace when they know exactly what prefix changed (covered in detail in How to fix broken file paths in an M3U playlist), or they rebuild the playlist from scratch using a tool that exports in the format they need.
Which format to aim for
For local music collections, relative paths are almost always the better default.
They make the playlist portable. You can copy your music folder to an external drive, a NAS, or a new machine and expect the playlist to work without editing. They also do not expose anything about your home directory or username, which is a minor but real privacy consideration when sharing playlists with others.
The only time absolute paths are less annoying is when your tracks genuinely live in multiple unrelated locations and you never move anything. In that case, relative paths are not an option anyway, and absolute paths are what you are stuck with.
How Emthree handles this
When Emthree exports a playlist, it writes relative paths. That choice is deliberate, for the portability reasons above.
There is one guard worth understanding: Emthree will block the export if the selected tracks and the playlist file do not share a common root folder. This matters when tracks are spread across multiple drives or disconnected volumes. Relative paths that cannot resolve are worse than no paths at all, so rather than silently write a broken file, Emthree stops and tells you. The fix is to make sure all the tracks you are exporting live under one common parent folder.
If you are rebuilding a playlist to fix broken paths, the workflow is: scan your current library in Emthree, add the tracks you want, and export. The resulting M3U uses relative paths anchored to where the files actually are right now, which means it should keep working as long as you keep the playlist and the music together.
Emthree runs in the browser, no install needed, and does not upload your files or library data anywhere.