Import Music Tags from a Text Table with Mp3tag

By Mp3Juice · September 14, 2026 · 7 min read

At a glance

Mp3tag imports music tags from text tables using Convert → Text File - Tag, requiring a format string that maps each column to a tag field. Files are matched either by sequential order or by filename/path included in the text. Proper preparation and testing ensure correct tag assignment and Unicode handling.

In this guide

What the import does
Prepare the table
Map columns to fields
Choose row matching
Three-file example
Check before batch editing
Next step

To import music tags from a text table with Mp3tag, use Convert → Text File - Tag and describe each row with a format string such as %artist%,%album%,%track%,%title%. Mp3tag does not automatically understand an arbitrary spreadsheet or CSV. You tell it which part of each line belongs to which tag field, and you make sure each row matches the intended audio file, either by order or by filename or path matching.

What the import does

Mp3tag’s text import reads a text file line by line and applies extracted values to selected files. In the documented structure, each line represents one file. The format string connects the line structure to tag fields. If a column is useful, map it to a field name. If a column is only an index, export ID, or other value you do not want to write, map it to %dummy%.

This feature is powerful but literal. A table that looks obvious to a person can still be ambiguous to software. A comma-separated line may contain artist, album, track, and title, but Mp3tag needs a matching format string that says which comma-delimited segment is which. Likewise, row one is not automatically the correct row for track one unless the selected file order, filename matching, or path matching makes that true.

Use this workflow when you have a reliable text source, such as a cleaned export, a manually prepared table, or metadata copied from a track list. If you need to review visible fields after importing, it can also help to set up the panel you use most often. See Customize the Mp3tag Tag Panel for a related workflow.

Prepare the table

Before opening the converter, make the text table boring and predictable. A safer table has one row per selected file, the same delimiter in every row, and no surprise extra columns. If your data started in a spreadsheet, inspect the exported text before importing. Do not assume that a file ending in .csv is automatically suitable for every collection.

Decide these points first:

Which fields will be written. Common examples are %artist%, %album%, %track%, and %title%.
Which columns will be ignored. Use %dummy% for values such as source row numbers or catalog notes that you do not want in tags.
Which delimiter separates columns. Commas are common, but only use them when the rows you are importing remain unambiguous.
How rows will match files. Choose sequential order, filename matching with %_filename_ext%, or full path matching with %_path%.

Unicode deserves special attention. Names such as “Björk”, “Sigur Rós”, “Zoë Keating”, or “Ágætis byrjun” should be checked in the text file before import and again in Mp3tag after import. A useful small test is to import three copied files and look for replacement characters, missing accents, or broken punctuation. If the characters look wrong in the plain text file before you import, fix the text file first rather than repairing a large batch afterward.

Map columns to fields

The format string must resemble the structure of each line. If your row is:

12,The Example Band,North Window,01,First Light

then a matching format string could be:

%dummy%,%artist%,%album%,%track%,%title%

Here, 12 is read and ignored because it is mapped to %dummy%. The next four values are written to the artist, album, track, and title fields. If your source line uses visible punctuation rather than a simple table, include that punctuation in the format string. For a line shaped like:

01. The Example Band - [North Window #01] First Light

the format string must follow the same pattern:

%dummy%. %artist% - [%album% #%track%] %title%

Choose field names for the tags you actually intend to write. Avoid overloading a field just because a column exists. If a source table has mood, review note, or original URL columns and those are not part of your tagging plan, do not squeeze them into unrelated fields. Either remove those columns from the import file or map them to %dummy% if they remain in the row structure.

Keep a copy of the original text file. Text import is a bulk edit, and the source table is your record of what you asked Mp3tag to write. If a result looks wrong later, the saved text makes it much easier to compare the imported value with the planned value.

Choose row matching

There are two practical matching approaches described for this import: sequential position, and matching by file name or full path. Pick one deliberately.

Sequential order

With sequential order, the first line in the text file is applied to the first selected file, the second line to the second selected file, and so on. This is fast when you control both orders. It is risky when the file list is sorted differently from the table, when bonus tracks are present, or when duplicate-looking entries make the order hard to verify.

Before using sequential order, compare the visible Mp3tag file list with your text rows. Check the first item, the last item, and several middle items. Record what you checked: for example, “row 1 matches file 1, row 12 matches file 12, row 24 matches file 24.” If the pattern is not consistent, stop and use a more explicit match.

Filename or path matching

Mp3tag can use %_filename_ext% for matching by file name with extension, or %_path% for matching by the absolute file path. These are useful when your text table contains the file identity as a column. For example, if the table includes 01-first-light.mp3, include %_filename_ext% in the format string so the row is tied to that file name rather than only to its position.

Use %_path% when file names repeat in different folders and the table contains the full path. Use %_filename_ext% when file names are unique within the selected set and the table contains those exact names. Either way, match the identity text as carefully as the tag text. A spelling difference, a missing extension, or a renamed file can prevent the intended match.

Three-file example

Example, fictional: Mira is organizing three demo recordings from a local trio called Luma Vale. She has copied the files into a test folder. The selected files in Mp3tag are:

luma-vale-01.mp3
luma-vale-02.mp3
luma-vale-03.mp3

Her text table contains Unicode characters in the album and title values:

luma-vale-01.mp3,Luma Vale,Café Lantern,1,Brighter Than Nú
luma-vale-02.mp3,Luma Vale,Café Lantern,2,Zoë at the Window
luma-vale-03.mp3,Luma Vale,Café Lantern,3,Ålesund Sketch

Because the first column identifies the file name, Mira does not want to rely only on row order. She opens Convert → Text File - Tag, selects the text file, and uses this format string:

%_filename_ext%,%artist%,%album%,%track%,%title%

After importing into the copied files, she checks the visible tags. She confirms that Café Lantern, Nú, Zoë, and Ålesund still display correctly. She also confirms that each title belongs to the file name in the first column.

If she had instead used a table without the filename column:

Luma Vale,Café Lantern,1,Brighter Than Nú
Luma Vale,Café Lantern,2,Zoë at the Window
Luma Vale,Café Lantern,3,Ålesund Sketch

then her format string would be:

%artist%,%album%,%track%,%title%

In that version, the rows would need to be in the same order as the selected files. The table would not identify the files by itself.

Check before batch editing

Before writing a large batch, compare the table and the selected files. Count the rows. Count the selected files. Look for duplicates, skipped tracks, renamed files, and columns that have shifted because a delimiter appears inside a value. If the first row has five comma-separated parts but a later row has six, the mapping may not mean what you think it means.

Then run the import on a small copy. Three to five files are enough to verify the format string, row matching, and Unicode display. Inspect the fields you actually wrote. If your usual view does not show a field you care about, add that field to your review process rather than assuming it worked because other fields look correct.

Record the result of the sample test: the format string used, the file identity method, the number of rows, the number of selected files, and any characters that needed special checking. If the import result is wrong, stop and return to the text table or the copied files. For a related recovery workflow, see Undo a Tag Edit in Mp3tag.

Do not remove existing tags just to make the import feel tidy. The goal is to write the intended fields accurately, not to erase useful context. Work on copies when you are uncertain, and expand to the full selection only after the sample files show that the format string and matching method are correct.

Next step

Prepare a three-row text file from one album, include either a reliable file-name column or a carefully verified row order, then run Convert → Text File - Tag on copied files and inspect every imported character before applying the same pattern to more music.

If you need a listening reference while checking your table, look up the song and artist on Mp3Juice. Verify the file-to-row match separately before importing any metadata in Mp3tag.