Exporting for Production: PDF vs. FDX Standards

You hit export. You send the file. A week later, a development exec says the margins look wrong or a line producer cannot import the script into the breakdown. The problem is not your story. The problem is the format you sent. When you export for production or submission, the file type and the export settings are not afterthoughts,they are part of the handoff.

Two formats dominate: PDF and FDX. PDF is the universal read-only snapshot. Everyone can open it. Readers, judges, and executives expect it for submissions and for reading. FDX is the industry-standard interchange format for the actual script data: scene headings, action, dialogue, and metadata in a structured form that other software can read, edit, and break down. Each has a role. Sending the wrong one, or a badly generated version of either, can delay or derail the next step. This article is about why that is, when to use which, and how to export so your script looks and behaves the way production expects.

We will stay focused on the practical side: what PDF and FDX are, who asks for what, and what can go wrong if you ignore the standards. The goal is to make the export step something you do once, correctly, instead of a last-minute guess that costs you notes or credibility.

Why File Format Matters at Submission

A script is not just text. It is a structured document. Scene headings, action, character names, dialogue, parentheticals, and transitions each have a place on the page and a meaning in production. When you export, you are deciding how that structure is preserved. A PDF freezes the visual layout: what you see is what the reader sees. That is ideal for reading and for locking the draft you are submitting. It is not ideal for editing or for breaking the script down into schedules and budgets. For that, production needs data. They need to know which block is a scene heading, which is dialogue, which character said what. That information lives in structured formats. FDX is the most widely supported of those formats in the film and television pipeline.

If you send a PDF when someone asked for FDX, they may not be able to import your script into their breakdown or scheduling software. If you send an FDX when someone asked for a PDF (e.g. a contest or a coverage service), they may not have a viewer that displays it nicely, or their workflow may assume PDF. If you send a PDF that was exported with wrong margins or font size, the script will look unprofessional and may not match the one-page-per-minute convention that production uses. So the choice of format is not arbitrary. It is dictated by who receives the file and what they will do with it. Getting it right is part of being easy to work with. For a grounding in why layout and structure matter in the first place, our screenplay format guide covers the rules that both PDF and FDX are meant to preserve.

PDF is for human eyes. FDX is for software. Send the one your recipient is set up to use. When in doubt, ask,or send both and label them clearly.

PDF: The Reading Standard

PDF stands for Portable Document Format. In screenwriting, a script PDF is a fixed representation of the script page. It looks the same on every device. Readers open it in Acrobat, Preview, or a browser. They do not need your screenwriting app. They do not need to worry about fonts or margins,as long as you exported correctly, the PDF already has the right layout embedded. That is why contests, agencies, and studios routinely ask for PDF. It is the lowest-friction way to read and share a script without losing formatting.

The catch is that PDF is a display format. It describes where pixels go, not "this is a scene heading" or "this is dialogue." Software can try to infer structure from a PDF (some tools do), but the result is not always reliable. So PDF is perfect for submission and for locking a draft for reading. It is not the format you use when the recipient needs to edit the script or run it through breakdown and scheduling software. For that, they need the structured file,FDX.

When you export to PDF, your app should be applying the same margins, font (Courier or Courier Prime 12pt), and element positions that we describe in our format guide. If your export dialog lets you tweak margins or font size, leave them at industry standard unless you have a specific request from the recipient. A PDF that does not look like a standard script will raise red flags before anyone reads a word. One more detail: page count. Production assumes roughly one minute per page. If your PDF is generated with different margins or font size, the page count can shift. That can throw off schedule and budget estimates. So export with the correct settings once, and reuse them for every submission.

One script, two outputs: PDF for reading and submission, FDX for editing and production.

FDX: The Production Interchange Format

FDX is an XML-based format originally associated with Final Draft. Over time it has become a de facto standard for exchanging script content between applications. An FDX file stores the script as structured data: each element is tagged (e.g. scene heading, action, character, dialogue). That allows other software to parse the script, extract scene lists, character lists, and dialogue, and feed them into breakdown and scheduling tools. Line producers and production offices often request FDX so they can import the script into their pipeline without retyping or re-parsing a PDF.

If you are only ever sending scripts to readers or contests, you might never need FDX. If you are working with a production company, a showrunner, or a co-writer who uses another app, FDX is often the handoff format. Export your script to FDX; they import it into their tool. The structure is preserved. Edits can be made in their environment. No one has to retype your script. That is why many screenwriting apps, including web-based and modern alternatives, support FDX export. It is the lingua franca for script data. For a comparison of how different tools handle export and collaboration, see our roundup of screenwriting software alternatives; export formats are a key differentiator when you are choosing or switching tools.

FDX is not always human-friendly to look at. Open an FDX file in a text editor and you will see XML tags. That is normal. The point is that another application can read it and reconstruct the script with correct formatting. When you export to FDX, you are not trying to make something pretty for a reader. You are making something machine-readable for the next step in the pipeline. So do not worry if the raw file looks technical. Worry about whether your app exports FDX that other apps can import without errors. Most mainstream tools do; if you use something niche, test the FDX with the recipient’s software before the real handoff.

What Can Go Wrong (And How to Avoid It)

The most common export mistakes are simple. Sending PDF when FDX was requested, or the other way around. Exporting PDF with non-standard margins or font, so the script looks wrong or the page count is off. Exporting FDX from an app that does not tag elements correctly, so the receiving software misparses scene headings or dialogue. Or sending a draft that is not the one you intended,wrong version, wrong file. All of these are avoidable. Check the submission or handoff instructions. Use industry-standard settings for PDF. Test FDX with the recipient if possible. And double-check the file you attach. A quick scan of the first page and the last page of a PDF will confirm it is the right draft and that formatting looks correct.

Some contests and agencies specify "PDF only" or "no FDX." Respect that. They have a pipeline built around PDF. Sending FDX anyway will not impress them; it will complicate their workflow. Conversely, if a production company asks for FDX, send FDX. They need the structure. Sending only a PDF means someone may have to re-enter or re-parse the script, which is error-prone and slow. When the request is ambiguous, a short email,"Do you need PDF for reading, FDX for breakdown, or both?",saves time and avoids a resend. For more on presenting your script in the best light, our piece on mistakes that get scripts tossed includes submission and formatting pitfalls that can undermine an otherwise strong draft.

Export settings to double-check

Before you export, a quick pass over your app’s export options will prevent most issues. For PDF: confirm that the font is Courier or Courier Prime at 12pt, that margins match the standard (e.g. 1.5" left, 1" right, 1" top and bottom), and that page breaks fall where you expect. Some apps let you export with or without scene numbers; for submission you usually want the version the recipient asked for (often without numbers for spec scripts, with numbers for production drafts). For FDX: confirm that your app’s FDX export is enabled and that you are exporting the current draft, not an older snapshot. If you have used custom elements or non-standard formatting, run a test: export to FDX, open it in another app or send it to a colleague, and confirm that scenes and dialogue come through correctly. One bad export can undermine an otherwise smooth handoff. Taking a minute to verify settings and doing a single test export will save you from resends and confusion later.

PDF preserves how the script looks; FDX preserves what each element is. Both matter, for different stages.

Seeing It in Action

A short demonstration can clarify the export flow. The video below walks through exporting a script to PDF with correct formatting for submission, exporting to FDX for production handoff, and what to check before you send either file. Whether you are submitting to a contest or handing off to a line producer, the same principles apply: match the requested format, use standard settings, and verify the file before it goes out.

The Bottom Line

Exporting for production is not an afterthought. PDF is the standard for reading and submission: universal, locked layout, correct margins and font. FDX is the standard for handing script data to production: structured, editable, importable into breakdown and scheduling tools. Use PDF when the recipient needs to read. Use FDX when they need to edit or run the script through their pipeline. When in doubt, ask what they want,or send both and label them clearly. Get the export settings right once, and your script will look and behave the way the industry expects. That is how you close the loop between writing and production without losing format or credibility along the way.