5 min read
WAV vs AIFF: does the choice still matter in 2026?
Same audio, different container. The decision comes down to metadata and who receives the file.
WAV and AIFF store the same thing: uncompressed linear PCM. Convert one to the other at the same sample rate and bit depth and the audio is bit identical. So why does anyone care?
The short history
WAV came from the Microsoft and IBM world, AIFF from Apple by way of Electronic Arts. For years that shaped which one you saw in which studio. Both have been fully cross platform for a long time, and modern software reads both without complaint.
Where they genuinely differ
- Metadata: WAV has the BWF extensions, bext and iXML, which the entire location sound industry relies on. AIFF has its own chunk system, less consistently supported for production metadata.
- Byte order: WAV is little endian, AIFF is big endian. Irrelevant to you, relevant to whoever writes the decoder.
- File size limits: classic WAV is capped near 4 GB, which long multitrack recordings can hit. RF64 and Wave64 extend it. AIFF has a similar practical ceiling.
- Habit: music production on Apple systems leans AIFF, film and broadcast lean WAV almost universally.
Which one to choose
For film, television, documentary and any workflow involving a field recorder, choose WAV. The BWF metadata layer is not optional in that world: timecode, scene, take and track names all live there.
Choose AIFF when a client or a sample library explicitly asks for it, or when you are delivering into a music pipeline that standardised on it years ago. There is no quality argument in either direction.
What BWF carries that AIFF does not
Broadcast WAV adds the bext chunk, which holds start timecode, originator, description and coding history, plus iXML for track names, scene and take. That combination is the backbone of a location sound workflow: it is how a file arriving in post still knows where it came from. AIFF has metadata chunks, but nothing as standardised for production sound, and no equivalent field that every recorder and NLE agrees on for timecode.
Where AIFF still makes sense
- Long-standing support across Apple tools and older Mac-based libraries.
- Sound effects collections that ship AIFF with embedded loop and instrument data.
- Music workflows and samplers that standardised on it years ago.
- A client or library that explicitly asks for AIFF in the delivery spec.
File size is identical
At the same sample rate, bit depth, channel count and duration, a WAV and an AIFF of the same recording are within a few kilobytes of each other. Neither format saves space, because neither compresses anything.
The 4 GB question and RF64
Classic WAV is limited to roughly 4 GB by its 32 bit size fields, which a long multitrack take at 24 bit and 96 kHz can reach. RF64 extends WAV past that limit and most modern field recorders switch to it automatically. AIFF has a comparable ceiling, addressed by its own variants. If you record long continuous takes, check what your recorder writes before the shoot rather than after it.
Converting between them
Because both are PCM, conversion is a container change, not a re-encode. Nothing is lost in the audio. What can be lost is metadata, since bext and iXML do not survive a naive trip to AIFF.
If you need AIFF deliverables and want to keep production data, keep the WAV masters, note the metadata separately, and generate AIFF only for the delivery. The extractor and export tools here write both WAV and AIFF at the sample rate and bit depth you choose, locally in your browser.
The practical production sound rule
Use BWF WAV for anything that touches production sound, because timecode and track names have to survive the trip to post. Use AIFF only when a library, a client or a Mac-based tool asks for it, and treat it as a delivery format rather than a master format.