Do I still need a JSON file if all I want to change is the cover art?

Yes. The run always expects exactly one MP3 and exactly one .json alongside it, so a cover-only edit still needs a JSON file present. An empty object written as two braces is enough for that case, since every key inside is optional. Without the JSON the run stops before any tag work happens.

My JSON has a "track" key and nothing works. Why is it rejected instead of ignored?

Any key that is not one of title, artist, album, year and genre is treated as a mistake rather than quietly dropped, because a silently ignored typo produces a file that looks edited and is not. Track number is genuinely unsupported here, along with composer, comment, lyrics and BPM. Remove the key and the rest of the file will be applied.

My MP3 already had a cover and now it does not. What happened?

The writer replaces the whole leading tag block rather than patching it, and existing artwork is not among the fields that get read back and carried forward. So if you do not supply a replacement image in the same drop, the file comes out with no embedded picture. Save the old cover out of the file first if you want to keep it, then upload it alongside the MP3 and the JSON.

Which ID3 version does the output file use?

The tool writes an ID3v2.3 tag, with the title, artist, album and genre frames stored as UTF-16 with a byte-order mark, so accented characters and non-Latin scripts survive intact. The year frame is digits only and goes in as plain Latin-1. It reads ID3v2.3 and ID3v2.4 when working out what to carry forward, but it always writes 2.3, which is the version with the widest player support. Roughly four kilobytes of padding is added after the frames so a later editor can grow the tag without rewriting the whole file.

Can I queue up a whole album and tag every track in one go?

Not in a single run. The upload box takes several files because a run needs the song, the values and optionally the picture together, not because it processes a playlist, and it insists on exactly one MP3. For an album you repeat the run per track, which is where the JSON approach starts to pay off since a script can emit one file per song from a spreadsheet.

Something failed and the page only shows a vague sentence. Where is the real reason?

The shared upload shell catches anything the tag writer throws and replaces it with one generic message, while the underlying error goes to your browser's developer console. Open the console and the specific complaint is there, whether that is malformed JSON, an unsupported key, a year outside 0 to 9999, or an image whose contents do not match its extension.

MP3 Tag Editor Online Free: Edit ID3 Metadata

Set an MP3's title, artist, album, year, genre and cover art from a small JSON file, in your browser. The audio frames are copied through untouched.

🔒 Private by design: your files are processed locally in your browser and never uploaded to any server.

Three files in one drop, sorted out by extension

Most tag editors give you a form. This one does not, and the reason is worth stating plainly: the upload box on a sysfenix tool page takes files, not free text, so the values have to arrive as a file too. You supply up to three things in a single drop and the tool sorts them by extension.

The .mp3 is the song. The .json holds the fields you want to set. An optional .jpg, .jpeg or .png becomes the new front cover. Exactly one MP3 and exactly one JSON are required, and at most one image is allowed; anything else about the combination stops the run before a single tag is written.

That trade costs you a minute of typing on the first go and buys something a form cannot. The same JSON shape can be produced by a script from a spreadsheet, a naming convention, or a database export, which turns a repetitive library cleanup into something you can generate rather than type.

Writing the JSON and running the edit

Create a small JSON file, for example {"title": "Song Name", "artist": "Band Name", "album": "Album Name", "year": 2024, "genre": "Rock"}. Every key is optional, so include only the fields you are changing. Text values must be non-empty strings and year must be a whole number between 0 and 9999.
If you are setting new artwork, have a JPG or PNG ready. Skip this if you are not.
Drop the MP3, the JSON and the optional image onto the box above together, or press Choose files and select all of them at once.
Press Edit MP3 Tags, then use the download link that appears. The output takes the song’s base name with -tagged.mp3 on the end, so track03.mp3 comes back as track03-tagged.mp3.

Keys outside the supported five are rejected rather than ignored, which catches a titel typo before it produces a file that looks edited and is not.

The five frames this writer sets

Title, artist, album, year and genre. Those are the fields a phone, a car head unit and a media player show without being asked, and they are the five the tool reads, merges and writes.

Behind them sit the standard ID3 text frames: TIT2 for the title, TPE1 for the artist, TALB for the album, TYER for the year and TCON for the genre. Cover art goes in as a picture frame typed as front cover. The four text frames are written as ID3v2.3 with UTF-16 text and a byte-order mark, so an artist name with umlauts or a title in Cyrillic comes out the way you typed it.

The merge step, and the tags it cannot rescue

A writer that blanks every field you did not mention would be useless for fixing one thing at a time, so before writing anything the tool reads the tag the file already has and fills the gaps. Set only a title and the artist, album, year and genre already in the file are carried through unchanged.

That read is deliberately best-effort, and it has hard edges:

It understands ID3v2.3 and ID3v2.4 tags. An older ID3v2.2 tag is still removed from the output but cannot be read back, so its values are lost unless your JSON supplies them.
Only the five supported fields are recovered. A track number, a comment, embedded lyrics, a composer or a BPM value in the original does not survive the rewrite.
Existing cover art is not read back either, which is why replacing a picture means uploading one rather than leaving the field alone.
The legacy 128-byte tag some very old players read sits at the end of the file, outside the block that gets replaced, so whatever it said before is still there afterwards.

If you want a guaranteed-clean result rather than a merge, list every field you care about in the JSON and do not rely on what the tool managed to recover.

One song per run, and what that means for a library

The upload box accepts several files, but they are the three roles of a single edit, not a queue. Each run tags exactly one MP3.

For a handful of podcast episodes that is fine. For a few hundred ripped tracks it means a few hundred runs, and at that point a desktop tagger with a batch grid is the better tool and this page is honest enough to say so. Where this one earns its place is when the values already exist somewhere structured and you would rather emit JSON than retype them, or when you are on a machine where installing software is not an option.

Once the metadata is right, the neighbouring jobs live elsewhere on the audio tools hub. Cut MP3 trims a section out of a single MP3 with a stream copy that leaves the audio untouched, Boost MP3 Volume raises or lowers the level of one file, and Normalize Audio Loudness brings a track to a consistent loudness target. All three reach into the audio stream in a way this page never does, and each of them handles one file at a time as well.

A tag rewrite is not a re-encode

An MP3 file is a run of compressed audio frames with a metadata block bolted to the front. Changing a title touches only that block. The writer strips the old leading tag, assembles a new one, and copies the original audio frames in behind it byte for byte.

Nothing is decoded and nothing is compressed again, so there is no generation loss and no quality setting to think about, and you can run the same file through repeatedly without it degrading. The only work in the whole operation is reading the file, assembling a few kilobytes of tag, and writing the audio back out behind it. That is a fundamentally different kind of job from decoding and re-encoding a track, and it is the reason a tag fix can never be the step that costs you fidelity.

Edit MP3 Tags