TL;DR: A WAV file is a RIFF container — a twelve-byte RIFF/WAVE header followed by chunks. Two chunks carry the audio: fmt (the format descriptor) and data (the PCM samples). Everything else is metadata, and there's more than most creators realise. The 1991 spec defined a LIST chunk of type INFO with sub-chunks like INAM (title), IART (artist), ICRD (creation date), ISFT (software), and ICMT (comment). Broadcast Wave Format added a mandatory bext chunk with originator, time reference, and a 64-byte SMPTE UMID. Production gear writes an iXML chunk with sound mixer name, take, and microphone setup. Adobe apps embed XMP in a _PMX chunk. Some tools tack on a non-standard id3 chunk or a C2PA manifest. Stripping a WAV means walking the chunk chain, keeping fmt and data, and dropping the rest. Run it through Metadata Cleaner in your browser; the audio comes out bit-identical.
What's actually inside a WAV file?
The WAV format is a thin skin over RIFF — Microsoft and IBM's 1991 Resource Interchange File Format. A WAV file is a RIFF chunk that announces itself with the four ASCII bytes RIFF, then a four-byte little-endian length, then the four ASCII bytes WAVE, then a sequence of sub-chunks. Every sub-chunk has the same shape: a four-byte ID, a four-byte little-endian length, and that many bytes of payload. If the length is odd, a single padding byte follows so the next chunk starts on an even offset.
Two of those sub-chunks are mandatory and carry the audio. The fmt chunk (the trailing space is part of the four-character ID) holds the format descriptor — sample rate, channel count, bit depth, codec ID. The data chunk holds the PCM samples themselves, byte-packed in the format described by fmt . Everything else in the file — every other chunk you'll see in exiftool or BWF MetaEdit — is metadata. Stripping a WAV doesn't mean rewriting the audio. It means walking the chunk chain, keeping fmt and data, and dropping or zeroing everything else.
We've covered the same chunk-walking pattern for MP3 files — but MP3 metadata lives in ID3v2 frames in front of the audio, plus optional Xing or LAME tags. WAV's structure is flatter and the chunks are more independent. A creator might pick up half a dozen of them between recording, editing, and export without ever seeing them.
Photo by Anete Lusina on Pexels.
The LIST INFO chunk: the original tag store
The 1991 RIFF specification reserved a special chunk type called LIST — a container for grouping other chunks under a four-character "list type" code. The most common list type in WAV files is INFO. Inside a LIST of type INFO, you'll find descriptive sub-chunks each holding a single null-terminated ASCII string. The set is fixed in the RIFF spec and includes:
INAM— title of the dataIART— artistICRD— creation dateISFT— software that wrote the fileICMT— free-form commentICOP— copyrightIGNR— genreIENG— engineerIPRD— product (album)ITRK— track numberIKEY— keywords
There are about two dozen of these standardised codes in total. Field recorders, DAWs, and converters all reach for LIST INFO because it's universally readable — Windows Explorer will show INAM, IART, and ICRD in the file properties panel without any third-party tool. That convenience is also why creators leak more than they realise. If your DAW auto-fills IART with your real name, every export carries it. If your converter writes its own version string into ISFT, every file you ship reveals which app you used. None of that affects playback, but all of it sits in the file forever unless something strips it.
The bext chunk: broadcast metadata you didn't ask for
In 1997 the European Broadcasting Union published EBU Tech 3285, the specification of the Broadcast Wave Format. BWF is a constrained WAV file with one mandatory extra chunk: bext, the Broadcast Audio Extension. A BWF file is still a WAV file — players read it as PCM — but bext is required to be present, and it's much richer than LIST INFO.
The bext chunk is at minimum 602 bytes. The fields, in order, are: Description (256 ASCII bytes — free text about the recording), Originator (32 bytes — the producer or station name), OriginatorReference (32 bytes — a unique reference assigned by the originator), OriginationDate (10 bytes, YYYY-MM-DD), OriginationTime (8 bytes, HH:MM:SS), TimeReference (8 bytes — the 64-bit count of samples since midnight, used for sync), Version (2 bytes), UMID (64 bytes for BWF version 1 and later — a SMPTE Unique Material Identifier), LoudnessValue and four more loudness fields added in version 2 (10 bytes), 180 reserved bytes, and finally a variable-length CodingHistory field that holds a free-text log of every transcoding step.
The UMID is the one to think about. It's a globally unique identifier generated when the file is created, designed to follow the audio forever, across every copy and edit. That's useful for a broadcaster cataloguing tape archives. It's a fingerprint for a creator who wants to publish anonymously. The CodingHistory field is the other tell — it can disclose every machine, codec, and sample-rate conversion the file passed through.
Modern field recorders from Sound Devices, Zaxcom, Zoom, and Tascam all write bext by default. Most DAWs read it on import and propagate it on export. Strip it, and the file plays the same; leave it, and it carries the entire production history into whatever upload you do next.
Photo by Jessica Lewis on Pexels.
iXML, _PMX, and id3: the chunks production gear adds
Past LIST INFO and bext, several other chunks show up in real-world WAV files.
The iXML chunk is an XML-based metadata block defined by the iXML specification and maintained by Gallery UK. It's the de-facto standard for production sound — field recorders use it to record PROJECT, SCENE, TAKE, TAPE, CIRCLED, SOUND_MIXER_NAME, SOUND_MIXER_EMAIL, and per-channel microphone descriptions. An iXML block from a busy day's filming can run into tens of kilobytes. None of it affects how the file plays; all of it is set-and-forget for the post-production workflow that the recording was originally captured for.
The _PMX chunk holds XMP — Adobe's Extensible Metadata Platform — encoded as UTF-8 XML. The ID is _PMX rather than XMP_ because the original Adobe implementation got the processor byte order wrong and shipped the four-character code reversed, which then became canonical. XMP in WAV can carry Dublin Core fields, rights management, edit history, GPS coordinates if the recorder logged them, and Content Credentials assertions. The full storage model is documented in the XMP Specification Part 3. If you've edited a WAV in Adobe Audition or Premiere, you almost certainly have a _PMX chunk in the file.
Finally there's the non-standard id3 chunk (note the trailing space). The WAV specification never sanctioned ID3 inside RIFF — ID3v2 is MP3's tag format — but a handful of tools write it anyway because they want to share a single tag-writing code path across MP3 and WAV. Foobar2000, dBpoweramp, and a few DAWs all do this. Different apps disagree on the exact ID (id3 , ID3 , id3), so support is inconsistent and the chunk often goes unread, but it's still there in the file.
C2PA in WAV: Content Credentials in the chunk chain
The C2PA Technical Specification lists WAV among its supported formats. When a C2PA-enabled tool signs a WAV file, it embeds a JUMBF superbox into a RIFF chunk inside the outer WAVE container. The chunk holds a CBOR-serialised assertion store and a COSE digital signature, the same structure C2PA uses in JPEG APP11 markers, PNG iTXt chunks, and MP4 UUID boxes. We walked through the audio-side mechanics in more detail in our explainer on C2PA in audio files.
For AI-generated audio, the manifest typically includes a c2pa.actions assertion with c2pa.created plus a generator identifier and, increasingly, an aigc: true flag. Platforms reading C2PA at upload — TikTok was first, with others following — use that flag to drive their AI-content labels. The audible audio doesn't change, but the file the platform reads tells it everything about how the audio was made. Strip the C2PA chunk and the file is back to being structurally indistinguishable from any other PCM WAV.
How to remove WAV metadata online without uploading
You can do this in your browser without sending the file anywhere. Metadata Cleaner opens any WAV up to about 2 GB on a modern phone or laptop, walks the RIFF chunk chain, keeps fmt and data, drops everything else, and re-serialises the file. The audio bytes inside data are copied through unchanged, so the cleaned WAV is bit-identical to the source at the PCM level and lossless re-encodes won't change. The steps are five clicks and take about forty-five seconds end to end — see the HowTo block at the top of this post for the exact sequence.
Two things are worth knowing about the size of the output. First, the cleaned file will be smaller, sometimes much smaller. An iXML chunk from a multi-microphone field recording can easily run 30 kB. A _PMX chunk with a full Adobe edit history can run several hundred kilobytes. A C2PA manifest with multiple signed assertions can run tens of kilobytes. Second, if your file had a bext chunk with a non-trivial CodingHistory, the reduction can be enough to notice in a directory listing — usually a few hundred bytes to a couple of kilobytes.
To verify the strip worked, run exiftool -G1 -a cleaned.wav and look at the output. You should see the RIFF1:RIFFType field and the RIFF1:Format, RIFF1:BitsPerSample, RIFF1:SampleRate, and RIFF1:NumChannels fields from the fmt chunk, and nothing else. No Info1, no Bext, no iXML, no XMP, no ID3, no JUMBF. Or open the file in BWF MetaEdit and confirm that only the format and data chunks remain.
Photo by cottonbro studio on Pexels.
What stripping the file doesn't reach
Removing the RIFF metadata chunks is a clean intervention, but it's not the whole story. We try to be straight about what file-side stripping can and can't do, the same way we did in our piece on audio watermarks versus metadata.
Stripping the WAV doesn't touch any audible or sub-audible watermark in the PCM samples themselves. If the audio was generated by Suno, Udio, ElevenLabs, or another tool that embeds an inaudible signal into the waveform, that signal is part of the data chunk and survives the strip. We've written separately about why AI music gets throttled even when the file looks clean — the short answer is acoustic fingerprinting and waveform analysis run independently of the container metadata.
Stripping doesn't change the distributor record either. If you've uploaded the track to DistroKid, TuneCore, or any other digital service provider and flagged it as AI-assisted in the DDEX MEAD form, that flag travels with the release to Spotify, Apple Music, and the rest, regardless of what the file you handed over carries. And stripping doesn't remove the file from any account-level signal — if your account has previously uploaded labelled AI audio, the platform's reputation models still know that.
What stripping does is stop the file itself from announcing how it was made. That's a meaningful change for upload classifiers, for share-link previews, and for anyone who opens the file in a metadata viewer. It's not a one-step path to unmarked audio.
FAQ
Does removing WAV metadata change the audio quality?
No. The data chunk holding the PCM samples is copied through byte-for-byte. The cleaned file is bit-identical to the source at the audio sample level.
Will Windows still show file properties after stripping?
Windows Explorer reads LIST INFO for the properties panel. After stripping, the title, artist, and creation-date fields will be empty in Explorer. The file still plays normally and still shows duration, bit rate, and channel count from the fmt chunk.
Can I keep the bext chunk but remove the UMID?
You'd need a dedicated editor for that — BWF MetaEdit can zero individual bext fields without dropping the whole chunk. Metadata Cleaner is built around removal, not selective editing, so it drops bext entirely. If you need a specific bext policy, edit the file with BWF MetaEdit first and then strip the rest.
Does Metadata Cleaner upload my WAV anywhere? No. The file is processed inside your browser tab as an ArrayBuffer. Nothing leaves the device. The cleaned file is written back as a download.
Are AIFF files the same as WAV for stripping? The container is different — AIFF is IFF rather than RIFF, with big-endian length fields — but the principle is identical. Metadata Cleaner handles AIFF as well; the same walk-the-chunks-keep-the-audio approach applies.
If you ship WAV files — for podcasts, music releases, sample packs, sound design, or anything else — assume the file carries more than you put into it. Try Metadata Cleaner free and verify what comes out the other side.