A producer is sent a script as an FDX file, opens it, and everything looks right. Then the scheduler imports it and some of what the writers and script editors worked on is missing, or the page count has quietly changed. Understanding the FDX file format will not make you a technician, but it explains why scripts behave differently as they travel between departments.
This guide is for producers, line producers and anyone who receives scripts rather than writes them. It covers what an FDX file is, what is stored inside it, where information gets lost, and what to ask for when a script is handed over.
What the FDX file format actually is
FDX is the native file type of Final Draft, the screenwriting software used widely in film and television. An FDX file is XML: structured text that software can read, not a picture of a page. According to one parser's documentation, it can be traversed with standard XML tools, which is why so many other programmes can open it.
Two things follow from this. First, an FDX file is a description of a script, not a finished page layout. The same file can look slightly different depending on the software that opens it. Second, because it is structured, it carries meaning as well as words: the software knows which line is a scene heading and which is dialogue.
That is the difference between an FDX file and a PDF. A PDF is for reading and signing off. An FDX is for working with.
Inside an FDX file: elements, not just text
Every line in a Final Draft script belongs to an element. Final Draft's own help centre lists the script elements: Scene Heading, Action, Character, Dialogue, Parenthetical and Transition, among others. In the file, each is stored as a paragraph tagged with its element type, with the visible words held inside it.
For a producer, this is the useful part. Because a scene heading is tagged as a scene heading, software can list every scene, location and time of day without guessing. Because a speaker's name is tagged as a Character, it can count who speaks, and where.
The file also stores formatting rules separately from the words, such as indents and spacing for each element type. This is why a script can be re-flowed on a different machine and land on different page breaks.
A practical consequence: the quality of what you can extract is only as good as the tagging. If a writer typed a scene heading as ordinary Action text, it looks fine on the page but is invisible to anything that reads the structure.
What the FDX file format does not carry
The commonest surprise is what does not travel with the file. Not every tool treats FDX the same way. For example, Filmustage's export notes say scene synopses, scene notes, annotations and comments are not carried over into an FDX export from that tool. Other tools will have their own gaps, so the general rule is to test with a real script before relying on any hand-off.
Scheduling is the clearest example. According to a guide to the Final Draft to Movie Magic workflow, Movie Magic Scheduling can open an FDX but cannot read the tagging data from it, so the script needs to be exported in the scheduling format (.sex) instead. Final Draft's help centre also describes this route, including numbering scenes first.
Page count is another trap. If a script has been converted between programmes, it can end up several pages longer or shorter, which matters when a page count is also a budget input. Compare totals after any conversion, not only the first one.
What to ask for when a script is handed over
You do not need to open the file yourself. You need to ask the right questions of whoever sends it:
- Which version is this, and is it locked? Know which draft you hold before anyone builds a schedule on it.
- Has it been through another programme? Every conversion is a chance for page counts and tagging to shift.
- Are scenes numbered, and are headings real scene headings? Scheduling imports depend on it.
- Where do the notes live? If comments and annotations matter, ask for them separately rather than assuming they are inside the file.
- Can I have both? A PDF for reading and the FDX for working is a sensible pairing.
None of this is exotic. It is the same discipline a script supervisor applies on set, applied one stage earlier.
Where a read-only tool fits
Because FDX is structured, software can read it and report on it: scenes, characters, locations, and what changed between drafts. That is the idea behind (CONT'D), a screenplay intelligence tool currently in pilot. It reads and analyses scripts, including FDX uploads; it does not write or rewrite them, and the writer's draft stays exactly as the writer left it.
In short
The FDX file format is structured text that knows what each line of a script is, which is why it is useful and why it is fragile in hand-offs. Know which draft you hold, confirm what has been converted, and ask where notes and numbers live. If you want to see how a read-only analysis layer handles your own scripts, join the pilot waitlist at https://contd.app/waitlist.