EDL vs XML vs AAF: which interchange format to send

EDL vs XML vs AAF comes down to one trade: EDL is simple and survives everything but carries almost nothing; AAF carries the most but only speaks to compatible systems; XML sits in between — richer than EDL, more readable than AAF, and less universally supported than either of them claims to be. All three describe the same thing — your timeline — so another system can rebuild it. Which one you send determines how much of your edit survives the trip.

If you're staring at a turnover spec that demands all three, that's not the post house being difficult. It's redundancy: the AAF or XML to do the heavy lifting, and the EDL as the human-readable fallback when something in the rich file doesn't translate. (If you need to actually read what's in one of those EDLs, the EDL to CSV converter turns it into a spreadsheet in a few seconds.)

What each format actually is

EDL (Edit Decision List) is a plain-text file from the linear tape era — one line per edit, listing reel, source in/out, and record in/out timecode. The dominant dialect is CMX3600, a format so old its 999-event limit comes from the memory of a 1970s edit controller. You can open an EDL in any text editor and read the cut, line by line. That readability is the entire reason it refuses to die. We cover the format line-by-line in What is an EDL?

[AAF (Advanced Authoring Format)](https://en.wikipedia.org/wiki/Advanced_Authoring_Format) is a binary container built for NLE-to-finishing handoffs — it's the native interchange language of the Avid world. An AAF carries clip metadata, multiple tracks, effects parameters, audio levels, and in some workflows embedded media itself. To a compatible system it reconstructs as a tidy timeline; to a human with a text editor it's noise.

XML (in the editorial sense: Final Cut-style XML, and its modern successor FCPXML) is a text-based, tag-structured description of your timeline. It holds much of what AAF holds — tracks, effects, speed changes, metadata — but you can open it, read it, and hack it. Premiere exports the older FCP 7-style XML; current Final Cut Pro speaks FCPXML, and the two are not the same thing, which is its own recurring source of turnover pain.

What survives the trip

The practical question isn't "which format is best" — it's "what does my timeline contain, and which format can carry it."

The honest footnote to every "Partial" and "app-dependent" in that table: no interchange format translates everything. Third-party plugin effects, complex nests, and anything exotic will drop or mangle in all three. That's why conform artists ask for a reference QuickTime with burn-in alongside the files — as the finishing-side view from postPerspective's turnover explainer puts it, the files rebuild the timeline, and the reference movie proves the rebuild is right.

When to send which

• Editorial → color (Resolve): Resolve reads all three. AAF from Premiere or Avid is the most common request; XML from Premiere works well for cuts-and-dissolves timelines. An EDL per video track usually rides along as the fallback.
• Editorial → audio post (Pro Tools): AAF, full stop. This is the one lane where there's no real debate — audio post lives on AAF (with OMF as the legacy option for very old setups).
• Avid ↔ anything: AAF. It's Avid's native interchange, and Media Composer's EDL support is an afterthought these days (via List Tool).
• Premiere ↔ Final Cut Pro: XML — with the version caveat above. Expect a translation step (or third-party tool) between FCP 7-style XML and FCPXML.
• VFX pulls, stock footage lists, music cue sheets, dailies matchback: EDL. Not because it's powerful — because everyone and everything reads it, including spreadsheet workflows once you convert the EDL to CSV.

The overriding rule: the receiving house's spec wins. Whatever this guide says, if the facility asks for a CMX3600 with eight-character reel names and one EDL per track, that's what you send. Their system, their rules — and asking them why is usually a better use of time than guessing.

Why post houses still ask for EDLs with everything else

It seems backwards — you've sent a metadata-rich AAF, why do they want the stone-age format too? Three reasons, all practical:

1. Troubleshooting. When a shot conforms wrong, the finishing artist opens the EDL and reads what the edit actually was. You can't do that with a binary AAF.
2. Cross-checking. The EDL is an independent description of the cut. If the AAF import produces something suspicious, the EDL settles the argument about what editorial intended.
3. Worst case, it still works. Systems disagree about AAF and XML flavors constantly. Nothing disagrees about a CMX3600. It is the format of last resort, and post houses have been burned enough times to always keep one in hand.

That third reason is also why "export one EDL per video track" is standard practice: CMX3600 only describes a single video track reliably, so a four-track timeline becomes four EDLs.

The turnover checklist

Specs vary by facility, but a turnover that arrives looking like this rarely bounces:

• The rich file: AAF (audio post, Avid-side color) or XML (Resolve, FCP interchange) — whichever the spec names, exported from a duplicated, flattened copy of your locked sequence, not the working timeline with its disabled clips and abandoned layers.
• One EDL per video track, CMX3600 unless told otherwise, with reel names intact.
• A reference QuickTime with burn-in (timecode + clip names), exported from the same locked cut.
• A change list or notes for anything you already know won't translate — third-party plugin effects, speed ramps, temp VFX. Naming them beats making the conform artist discover them.
• Consistent naming. SHOW_EP101_LOCKED_V3.aaf next to SHOW_EP101_LOCKED_V3_V1.edl and a matching reference movie. If the facility has to guess which EDL belongs to which track, the turnover is already generating emails.

Ten minutes of cleanup before exporting — flatten what can be flattened, delete empty tracks, name your reels — saves hours of back-and-forth after. Most "the AAF is broken" conversations are actually "the timeline was messy" conversations.

The frame-rate trap

The most common way turnovers go wrong isn't the format choice at all — it's frame rate. If your sequence contains mixed-frame-rate media, or the project frame rate doesn't match the source, the interchange file inherits the confusion, and clips land with wrong in/out points on the other side. It shows up in every format, but EDLs make it obvious fastest, because you can see the timecode. If a conform comes back with consistent off-by-a-bit errors, check for a frame-rate conversion inside your NLE before blaming the file.

FAQ

Is AAF better than XML? For carrying timeline detail into finishing and audio systems, generally yes — AAF holds more (levels, effects parameters) and is the native language of Avid and Pro Tools workflows. But "better" depends on the receiving system: a Resolve colorist may prefer Premiere XML, and a facility's conform spec beats any general ranking.

Can I convert an EDL to XML or AAF? Not meaningfully. An EDL contains only cuts, timecode, and reels, so a converted file can't gain metadata that was never there. Tools exist that re-wrap EDLs, but the useful direction is exporting the richer format from your NLE in the first place.

Why does my post house want one EDL per video track? Because CMX3600 reliably describes a single video track. Multi-track timelines get split into one EDL per layer so nothing stacks or disappears — a limitation inherited from the tape-to-tape era the format was built for.

Which format should I send to DaVinci Resolve? Resolve reads AAF, XML, and EDL. From Premiere, XML or AAF both work for typical timelines; from Avid, AAF. Include an EDL per track as the fallback, and always send a reference QuickTime so the conform can be checked shot-by-shot.

Is FCPXML the same as XML? No. Premiere exports the older Final Cut Pro 7-style XML; modern Final Cut Pro uses FCPXML, a different (and not backward-compatible) format. Sending one where the other is expected is a classic turnover failure — confirm which the receiving side needs.

How do I read what's inside an EDL or AAF? An EDL is plain text — open it in any editor, or convert it to CSV to sort and filter events in a spreadsheet. An AAF is binary and effectively unreadable outside an application that supports it, which is exactly why EDLs still travel with every turnover.