{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Audio:{{ resultsReady ? 'Byte-for-byte match' : 'โ€”' }} Tag:{{ resultsReady ? computation.values.output_tag_version : 'โ€”' }} Frames:{{ resultsReady ? computation.values.written_frame_count : 'โ€”' }}
{{ summaryAnnouncement }}
MP3 source and reviewed metadata
Drop or browse one .mp3 file up to 12 MiB. Nothing is uploaded or persisted.
{{ sourceFile ? sourceFile.name : 'Drop one MP3 here' }}
{{ sourceFileSummary }}
A short local tone is loaded initially so every result artifact can be reviewed.
{{ sourceStatusAnnouncement }}
Use 3 or 3/12; leave blank to omit.
Free-text content type; leave blank to omit.
Replacement accepts one bounded PNG or JPEG; removal writes no APIC frame.
{{ replacementArtwork ? `${replacementArtwork.name} ยท ${formatBytes(replacementArtwork.size)}` : 'Up to 1 MiB' }}
Front-cover artwork preview
{{ fields.artwork_action === 'replace' ? 'Replacement front cover' : 'Existing front cover' }}

{{ workflowMessage }}

This changes presentation only; it never changes the MP3 bytes.
Retagged MP3
{{ computation.values.download_name }}
Encoded audio
{{ formatBytes(computation.values.audio_byte_count) }}
ID3 metadata
{{ formatBytes(computation.values.metadata_byte_count) }}
Output file
{{ formatBytes(computation.values.output_byte_count) }}
Audio CRC32
{{ computation.values.audio_crc32 }}
{{ row.label }}
{{ row.detail }}

{{ downloadAnnouncement }}

{{ chartExportStatus }}

The chart renderer is unavailable. Exact byte counts remain in the MP3 and ledger artifacts.

{{ ledgerExportStatus }}
FieldWritten valueCopy
{{ row.field }}{{ row.value }}

Introduction:

An MP3 can carry descriptive data before its encoded sound. Players and libraries use those tags to show a title, artist, album, track position, genre, and cover image. Changing that information can fix a mislabeled recording or prepare a clean handoff without changing how the audio itself was encoded.

ID3 tags are made from named frames. Common text frames hold fields such as the title and artist, while an attached-picture frame can contain front-cover artwork. Different players support different versions and frame types, so a file that looks correct in one library can display stale or missing information elsewhere.

Common MP3 metadata and practical use
TagTypical useCommon mistake
Title and artistIdentify the recording and main performerUsing a filename as a substitute for embedded tags
Album and trackOrder recordings inside a releaseWriting track 12/10 or mixing disc and track numbers
GenreSupport browsing and library groupingExpecting every player to normalize plain-text labels
Front coverShow album or recording artworkEmbedding an oversized image that dominates file size

Retagging is not the same as preserving every existing frame. A focused rewrite can deliberately carry forward only the reviewed fields and front cover, leaving behind comments, lyrics, private frames, URLs, additional pictures, and other unsupported data. That is useful when a clean result is wanted, but it is the wrong workflow when unknown metadata must remain intact.

The safest check separates metadata from sound. Confirm the written tags in a second player, then listen to the output and keep the original until the new file has passed the intended library or publishing workflow.

How to Use This Tool:

Review the five supported text fields and the front-cover choice before creating a new tagged copy.

  1. Choose one Source MP3 no larger than 12 MiB. The file must contain a recognizable MPEG audio frame after its tags.
  2. Edit Title, Artist, Album, and Genre, leaving a field blank when it should not be written. Enter Track as a positive position such as 3 or 3/12; the position cannot exceed the stated total.
  3. Choose whether to keep, replace, or remove the Front-cover artwork. Replacement artwork must be a PNG or JPEG no larger than 1 MiB.
  4. Run the edit, then confirm Unchanged audio, the output tag version, and the written values before downloading the retagged MP3.

Interpreting Results:

Unchanged audio means the MPEG audio payload in the generated file matches the source payload byte for byte. The total file size may still change because the old tags are replaced with a new ID3v2.3 tag and optional artwork.

The written frame count covers non-empty supported text fields plus one front-cover frame when artwork remains. The changed-field count compares the reviewed values and artwork with the common fields read from the source. It does not account for every unsupported or duplicate frame that may have existed in the original tag.

Open the result in the player or library that will consume it. A successful round trip proves that the new tag can be read back and that the sound bytes are unchanged, but it cannot force another application to display or sort every field in the same way.

Technical Details:

ID3v2 places a header and a sequence of frames before the MPEG audio payload. Each ID3v2.3 frame has a four-character identifier, a size, flags, and frame-specific content. The rewrite uses a compact reviewed subset rather than copying the source tag wholesale.

Transformation Core:

Audio metadata fields and ID3v2.3 output frames
Reviewed valueOutput frameWriting rule
TitleTIT2UTF-16 text, omitted when blank
ArtistTPE1UTF-16 text, omitted when blank
AlbumTALBUTF-16 text, omitted when blank
TrackTRCKPositive position or position/total, up to 9999/9999
GenreTCONPlain text, omitted when blank
Front coverAPICEmbedded PNG or JPEG with picture type 3

Source ID3v2.3 and ID3v2.4 tags are inspected for the first supported common frame and front cover. ID3v1 values are used only when a readable ID3v2 tag is unavailable. The output always begins with a new ID3v2.3 tag containing the reviewed subset, followed by the original MPEG audio payload; a trailing ID3v1 tag is not carried forward.

Text is normalized by removing null characters, collapsing repeated whitespace, and trimming its ends. Title, artist, and album accept up to 200 characters, while genre accepts up to 80. The track field accepts one to four digits with an optional one-to-four-digit total, and both values must be at least 1.

Verification Mechanism:

The newly written file is parsed again. Each supported text value and the artwork byte count must round-trip, and the extracted MPEG payload must equal the source payload byte for byte. A CRC-32 value is also reported for convenient comparison, although direct byte equality is the acceptance check.

No Formula Core is needed because the governing operation is a frame transformation rather than a numeric calculation. Byte counts and frame counts describe the result; they do not drive the rewrite.

Privacy and Compatibility Notes:

The MP3, its tags, replacement artwork, and generated output stay in memory in the current browser tab. They are not uploaded or persisted.

  • Unsupported, duplicate, private, encrypted, compressed, comment, lyric, URL, and custom frames are not preserved.
  • Only one front-cover image is written; other picture types are omitted.
  • The editor does not change filenames in a library, look up metadata, normalize sound, transcode audio, or write tags for non-MP3 formats.
  • CRC-32 detects accidental byte changes but is not a cryptographic authenticity or security check.