Remove audio metadata

A recording carries more than sound: the tags a tagger wrote, the artwork somebody attached, and — on anything from professional gear — the name of the person or company that made it. Cleaning here copies the samples across byte for byte and rewrites only the parts around them.

Drag & drop your file here

or paste from the clipboard

Choose file

Reads metadata in: JPEG · PNG · WebP · HEIC/HEIF · AVIF · MP4 · QuickTime MOV · WebM · PDF · MP3 · WAV · M4A

Your file never leaves your device. Processing happens entirely in your browser.

Where audio metadata sits

An MP3 keeps its tags in a block at the front (ID3v2) and often a second one in the last 128 bytes of the file (ID3v1), with older APEv2, Lyrics3 and TAG+ blocks sometimes stacked behind it. A WAV is a RIFF file, so each kind of metadata is a chunk beside the audio: INFO fields, an ID3 tag, an XMP packet, the labels on cue markers. An M4A is an MP4 whose tracks are sound, and its tags are iTunes-style atoms inside the movie header.

In every one of them the metadata sits beside the samples rather than inside them, which is why a clean is a rewrite of the container and never a re-encode. The decoded audio of a cleaned file is identical to the original, sample for sample, and that is checked with ffmpeg outside this project rather than asserted here.

A song can contain a photograph that knows where it was taken

Cover art is an image, and images carry metadata of their own. One real MP3 in the test corpus holds artwork whose IPTC block names the photographer, their agency, their job title, and the city and country the shot was taken in — inside a music file, where nobody thinks to look for it.

So the artwork is opened and read as the file it is, and what it contains is listed in the report before you decide. Removing the tag removes the picture with it. An M4A can hold more than one image in a single artwork atom; each is reported separately, because a reader that stops at the first leaves the rest unmentioned.

What a field recorder writes about the person holding it

The Broadcast Wave extension — the bext chunk, from EBU Tech 3285 — has an originator field, and on professional equipment that field is routinely a person, a company, or a machine serial number, stored with the date and the time of day the recording was made. A session file in the corpus carries the recorder software, the date and the time to the second.

It is treated with the weight GPS gets in a photograph: named in the warnings, and removed by a clean. So is iXML, the production block that holds project, scene, take, notes and often the names of the crew. Both are removable rather than editable: they are fixed-layout production records, and the useful operation on somebody else’s name in one is removal.

What is deliberately left alone

The first frame of a variable-bitrate MP3 usually carries a Xing, Info or VBRI header, and inside it a LAME tag naming the encoder and its settings. It is metadata by nature, and it is left in place: removing it breaks seeking, and damaging a recording to hide the name of a program is not a trade this tool makes on your behalf. It is reported instead, encoder name and all, so the choice is visible rather than silent.

Cue marker positions stay too. The words somebody typed against a marker are metadata and go; where the marker sits is part of the shape of the recording and stays.

What this build does with each of them

Read from the same table the engine consults before it opens a file, so it describes behaviour rather than intention. The formats page shows every format in it.

MP3

Analysed · cleaned · edited · 11 writable fields

Removable: ID3 tag, ID3v1 and other end-of-file tags, Cover art.

Metadata sits in a tag block before the audio and a pile of smaller ones after it — ID3v1, APEv2, Lyrics3, TAG+. The audio frames between them are copied byte for byte and never decoded.
ID3v2.3 and 2.4 are read and written. Version 2.2 is read but not written: a file carrying one is reported and left alone rather than quietly upgraded to a version some players do not read.
A frame marked compressed or encrypted is reported as unreadable rather than guessed at, and is carried across untouched.
ID3v1 gives each field a fixed 30-byte slot. When a file carries both tags and a value is too long, the ID3v1 copy is shorter — and the result says which fields were shortened rather than leaving it to be discovered.
The Xing, Info or VBRI header in the first audio frame is metadata, and it names the encoder. It is reported and left in place: removing it breaks seeking in a variable-bitrate file, which would damage the recording to hide the name of a program.
Cover art is an image, and images carry metadata of their own. What the artwork contains is reported, and it can be removed with the rest.
No C2PA embedding is defined for MP3, so Content Credentials are reported as not checked rather than as absent.

WAV

Analysed · cleaned · edited · 12 writable fields

Removable: RIFF INFO fields, Broadcast Wave extension, iXML production metadata, ID3 tag, XMP, Cover art.

A WAV is a RIFF file: the audio is one chunk and the metadata sits in others beside it, so cleaning copies the samples across untouched.
The Broadcast Wave extension (bext) is where a field recorder writes the originator — routinely a person or a company — along with the recording date, time reference and coding history. It is treated as the privacy-relevant block in audio, and it can be removed.
iXML holds what a production recorder knows: project, scene, take, notes, and often the names of the crew.
RIFF INFO fields, an ID3 tag inside a RIFF chunk, an XMP packet in _PMX, and the text labels on cue markers are all read and removable.
RF64 and BW64 — a WAV extended past four gigabytes — are handled as ordinary RIFF files, with the size table they keep for that purpose carried across.
bext and iXML are reported and removable but not editable: they are fixed-layout production records, and the useful operation on somebody else’s name in them is removal.
No C2PA embedding is defined for WAV, so Content Credentials are reported as not checked rather than as absent.

M4A

Analysed · cleaned · edited · 17 writable fields

Removable: Container metadata, Cover art, EXIF, GPS, XMP.

An M4A is an MP4 whose tracks are sound, so the container work is the same: the encoded audio is copied through untouched and only the metadata boxes are rewritten.
The sample tables that say where each piece of audio begins are rewritten with it, which is why the file still plays and its duration is unchanged.
iTunes-style metadata lives in ilst atoms — title, artist, album, date, the encoding tool — and all of it is removable.
Cover art is an image, and images carry metadata of their own. What the artwork contains is reported and it goes with the rest.
Freeform atoms are reported by the name they give themselves — a reverse-DNS owner and a field name — and their contents are shown as they are rather than guessed at.

Frequently asked questions

Does cleaning re-encode the audio?

No. The encoded audio is copied across byte for byte and only the metadata around it is rewritten. A cleaned file decodes to exactly the same samples as the original, which is verified against ffmpeg rather than assumed.

Will the track still play, and will its length be right?

Yes. For an M4A the tables that say where each piece of audio begins are rewritten to match the new layout, which is the part that would otherwise break playback; duration is unchanged. For MP3 and WAV the audio never moves relative to what matters.

What happens to the cover art?

It is read as the image it is, its own metadata is listed in the report, and a clean removes it along with the tag that held it. If you want to keep the artwork, edit the fields you care about instead of cleaning.

Can it write tags as well as remove them?

Yes, for ID3v2.3 and ID3v2.4, for RIFF INFO fields and for iTunes-style atoms. ID3v2.2 is read but refused for writing, in those words: its frame identifiers are three characters rather than four, and rewriting an old file as a newer version would make it unreadable to the players that only ever implemented the old one.

Is the mapping between MP3 tags and WAV fields a standard?

No, and the interface says so. The Metadata Working Group guidelines that govern this for photographs do not cover audio, so there is no document to cite for "this ID3 frame and that RIFF field are the same thing". It is what every player and tagger has done for twenty years, and it is recorded as convention rather than dressed up as a citation.