Guide
An EDL is a list of decisions, not a video file
An edit decision list is a plain, machine-readable record of which piece of source plays when, in order. It contains no picture and no sound. It was invented so an edit made on cheap equipment could be recreated exactly on expensive equipment. This page covers where it came from, the four facts inside one edit event, and why every automated editor still produces one. By the end you will know which files in your archive are worth keeping.
- Frames of video inside an EDL
- 0
- Fields that define one edit event
- 4
- When the format was standardised
- 1970s
It exists because the cheap room and the expensive room had to agree
Video editing used to happen twice. An offline edit was assembled on low-quality copies. Then the finished decisions were recreated in an online suite on the master tapes.
The list is what travelled between those two rooms. It records the decisions rather than the pictures, so it is small, readable and equipment-agnostic.
That is why the format is so plain. It had to survive being read by machines from different manufacturers, in an era where nothing else could be shared between them.
The tape rooms are gone and the idea outlived them. Separating decisions from pixels turns out to be useful in every editing system built since.
A modern project file does the same job with more in it. The EDL is the stripped version that still interchanges when nothing else will.
One event is four facts, and everything else is commentary
An edit event names a source, says which part of it to use, says where it lands in the finished sequence, and says how it arrives.
Timecode is the shared clock. Hours, minutes, seconds and frames, counted from a fixed origin, which is what makes the whole idea unambiguous.
That is genuinely all of it. The apparent complexity of an EDL is notation rather than concept, and the notation exists to keep it machine-readable.
- The source: which recording this event comes from.
- Source in and out: the part of that recording to use, as timecode.
- Record in and out: where it lands in the finished sequence, as timecode.
- The transition: how it arrives, which is usually a straight cut.
What one edit event says
Four facts per event, in order, with no picture attached. A whole edit is a list of these.
Which source
The recording
Which part of it
Source in and out
Where it lands
Record in and out
How it arrives
Cut, or a transition
This is the whole editor
Highlight a phrase and a clip lands on those exact words. No timeline, no keyframes, no layers.
Every automated editor produces one, whether it shows you or not
This is the part that makes a forty year old format worth understanding today. Any system that assembles video from decisions has to hold those decisions somewhere.
Separating the decision list from the render is what makes an edit cheap to change. Change one entry, recompile, and a new file comes out.
It also makes a change safe. The source is never modified. An edit is a description of what to play rather than an operation on the footage.
Cutroom works this way by design. The words you act on become entries in a plan. The compiler owns all the time arithmetic. The render is produced from that plan.
Delete a line and the sequence rebuilds around the gap. Change the pace and the whole plan is recomputed. Highlight a phrase and an entry lands over exactly those words.
That is why a second version costs an export rather than an evening. Nothing is baked in until the render, which is the same insight the tape rooms had.
Decisions against pixels
The whole reason the format survived. Everything on the left is cheap to change and everything on the right is not.
| The decision list | The rendered file | |
|---|---|---|
| Size | Text, kilobytes | Video, hundreds of megabytes |
| Cost to change one cut | Edit a line, recompile | Re-render everything |
| Readable by a person | Yes, it is plain text | No |
| What a viewer can watch | Nothing | The ad |
Knowing this changes one practical habit: keep the sources
An EDL is worthless without the recordings it points at. A rendered file is worthless as a starting point for a new version.
So the asset worth keeping is the source take, named in a way you will understand in six months. The exports are disposable, because they can be produced again.
Teams routinely do the opposite. They archive the finished files, lose the originals, then discover that a small change means re-shooting.
The second habit is a naming convention. Timecode is precise and file names are not. Most interchange problems are actually naming problems.
The third is knowing your tool's export path. If you ever move an edit elsewhere, the question is what leaves the building. For many modern tools the answer is the finished video.
A fourth habit is worth five minutes. Write down which tool made each edit and when. A project you cannot reopen in two years is a project you will remake from scratch.
That is not hypothetical. Editing software changes hands, changes format and disappears. The decision list was invented to survive exactly that.
The plan stays live, which is why a change costs an export
In Cutroom the decision list is internal and it stays editable for as long as the project exists. Your source is never modified. Every version is produced from the plan.
That is the whole reason a change is cheap. Delete a line, recompile, and a new 9:16 MP4 comes out at 20 credits per output minute. The batch was paid once, at 100 credits.
Two facts to know before you plan a workflow around it. The plan does not export as an EDL, and a project from another system cannot be brought in. What leaves is the finished file.
There is no timeline underneath either. No keyframes, no layers, no track to drop into, so word level is the finest change you can ask for.
For interchange, conform work and finishing, use an editor built for it. This is built to turn a spoken take into a vertical ad, quickly and repeatedly.
The idea underneath is older than any tool. Decisions are cheap and pixels are expensive. Keep the decisions separate, keep the sources they point at, and the next version costs an export.
Questions people ask
- Is an EDL the same as a project file?
- No. A project file holds everything your editor knows, including effects, settings and layout. An EDL holds only the sequence decisions in a plain interchange format. That narrowness is the point, because it is what lets different systems agree.
- Do people still use EDLs in practice?
- Less often than they use richer interchange formats, and still regularly for simple conform work and for moving a cut between systems that share nothing else. The idea underneath, separating decisions from pixels, is used constantly.
- Can I open an EDL and read it?
- Yes. It is plain text, and once you know timecode reads as hours, minutes, seconds and frames, each line is legible. That readability is why the format outlived the equipment it was built for.
- Does everyone need an interchange format?
- Only if an edit has to move between systems or reach a finishing suite. If your finished video is the only thing that ever leaves, what matters instead is keeping the source takes, because those are what a new version gets built from.
Keep the sources and treat the exports as disposable. Cutroom keeps the decisions live, so the next version of an ad is a 10 credit export rather than an evening.