Start with the script you intend to shoot
A breakdown turns a screenplay into a list of things a production must provide. The useful question is concrete: for scene 12A, who speaks, where does the action happen, and what has to be present? A screenplay describes the finished experience. A production breakdown records the requirements behind that experience. Keeping those two documents connected makes revisions easier to catch before someone books a location or arrives without a required object.
Open a Fountain, FDX or UTF-8 text version of the current script in the workspace above. You can also paste screenplay text directly. Create the breakdown, then inspect one scene at a time. The extracted scene information is a starting point for your review. It does not replace a director, production designer, assistant director or department head reading the actual pages.
Keep a recognizable script version beside the exported breakdown. Put the draft name and review date in a production note if those details matter to the team. A spreadsheet named only “final” is difficult to reconcile when three different scripts have circulated. A short, explicit name such as “Station short, October rehearsal draft” gives collaborators a common reference without pretending that the tool manages your production files.
The tool accepts up to 250,000 source characters and 500 scenes. File selection also has a one-megabyte limit. These limits keep the browser workspace manageable. For a larger project, split the source at scene boundaries, identify the section in your filenames, and check that no scene falls between two exports. Do not split in the middle of dialogue and expect the second section to inherit its speaker.
What the parser can identify
Scene headings establish the structure. A heading beginning with INT., EXT., INT./EXT., EXT./INT., I/E. or EST. starts a scene in text input. A Fountain forced heading beginning with a single period can also establish a scene. A location and recognized time suffix are separated when the heading supplies them. Missing information stays missing so you can fill it deliberately.
For example, “INT. STATION OFFICE - NIGHT #12A#” supplies an interior, the station office, night and scene number 12A. A heading without a number stays unnumbered. The tool assigns an internal identifier for editing, but that identifier is not presented as an official screenplay scene number. This distinction matters when a production uses lettered insert scenes after locking its numbering.
Recognized time labels include common choices such as DAY, NIGHT, DAWN, DUSK, MORNING, EVENING, LATER and CONTINUOUS. A custom phrase can remain in the location field rather than becoming a reliable time category. Review headings with unusual punctuation or a custom time description. Editing the resulting location and time is often faster than rewriting a whole source document merely to satisfy a parser.
Speaking characters come from character cues. In text, these usually appear as a short uppercase name followed by dialogue. A forced Fountain character cue can begin with an at sign. Common extensions such as V.O., O.S. and CONT’D are removed from the cast name. The name identifies a speaking role; it does not determine whether an actor must physically attend that particular location.
Structured FDX files provide paragraph types for headings, characters, action and dialogue. The importer uses those types rather than guessing every paragraph from capitalization. Text spans within a paragraph are joined, and explicit scene-number attributes are retained. Content in an FDX title-page section is excluded from the screenplay scene list. Standard screenplay FDX is supported; arbitrary XML exports and PDFs are not interchangeable formats.
Speaking cast and additional cast need different checks
A character who speaks is easy to miss in a production plan when their dialogue comes from a telephone, a radio or off screen. The speaking list therefore retains the role even when the cue includes an extension. You decide whether that role needs a performer on set, a recording session, a temporary reading voice or another arrangement. Record that production decision in notes instead of deleting useful source evidence.
Additional cast is more limited. The parser can suggest an introduced uppercase name followed by a recognizable age description in action. You can also supply explicit cast tags. It cannot reliably discover every background performer, implied crowd, stunt double, reflection or animal from unrestricted prose. Read entrances, exits, reactions and background activity carefully before considering a scene reviewed.
A named character who appears in both an introduction and a speaking cue is kept in the speaking list rather than duplicated in additional cast. That cleanup prevents an obvious double count. It does not merge aliases such as “MARA,” “YOUNG MARA” and “THE GUARD.” If two labels refer to one performer, decide the appropriate production naming convention and edit the scene records consistently.
Use the grouped cast summary to find scenes associated with a name. It is a scene-reference index, not a cast booking schedule. A role appearing in scenes 3, 8 and 12 does not imply those scenes can be filmed on the same day. Availability, costume changes, location access and the shooting plan still need a separate scheduling discussion.
Reviewable suggestions instead of invented certainty
The action scanner uses a deliberately narrow vocabulary. It looks for handled objects after verbs such as holds, carries, picks up or sets down. A brass key in a character’s hand is a stronger prop clue than the same word in a speech. Dialogue is excluded from this action pass so a character mentioning a phone does not automatically create a confirmed phone requirement.
Wardrobe suggestions follow explicit clothing actions such as wears or puts on. A red coat may be detected; an implied evening dress code may not. Vehicles and selected effects terms can be suggested from action descriptions. Every suggestion needs review because a mentioned bus could be a parked background vehicle, a practical location, a miniature or an image visible through a window.
The practical-effects category recognizes a small set of explicit terms, including gunfire, explosions and certain production devices. The visual-effects category recognizes expressions such as green screen or wire removal. These matches describe words in the source. They do not specify a safe execution method, an effects budget, a vendor or an approved shot design.
Open the original element evidence beneath a scene’s editor. Each entry shows the detected label, category, source reference and a short source excerpt. It also distinguishes a suggestion from an explicit tag. After you rename or remove an element, the evidence remains a record of the original extraction. It is useful for checking why the first list contained an item, rather than silently rewriting the script’s history.
Add explicit tags when a requirement must survive import
Fountain notes provide a practical place for production annotations. This tool recognizes single-line double-bracket tags for PROP, PROPS, WARDROBE, VEHICLE, VEHICLES, SFX, VFX, CAST and NOTE. A tag such as “[[PROP: station ledger]]” adds that requirement directly. “[[CAST: platform attendant, two commuters]]” adds comma-separated cast entries. A NOTE tag appends its text to the scene’s production notes.
Use one specific element per requirement tag when you want a clear evidence entry. “[[PROP: stamped ticket]]” is easier to review than a long sentence combining a ticket, suitcase, newspaper and weather request. Cast tags are the exception that explicitly accepts a comma-separated list. The scene editor itself uses comma-separated lists for its editable requirement fields.
Keep annotations close to the scene they describe. A tag belongs to the current scene after its heading. A general note before the first scene does not establish a production-wide requirement. If an object travels through five scenes, confirm it in each relevant record instead of assuming one tag automatically propagates throughout the film.
Tags improve explicitness but do not prove completeness. A hand-entered visual-effects request can still be outdated after a rewrite. A wardrobe tag can omit a duplicate costume needed for a wet sequence. Treat tagging as a way to preserve a known decision, and scene review as the separate process that tests whether the decision still matches the production.
An illustrative station breakdown
The sample in the workspace is fictional. Its two scenes demonstrate the workflow rather than report a production case study. The first heading describes the station office at night, numbered 12A. Mara is introduced in action wearing a red coat and holding a brass key. A taxi waits outside. Her dialogue mentions a phone, while an explicit prop tag adds a station ledger.
The useful result is not merely “one scene.” You should see Mara as speaking cast, the coat as a wardrobe suggestion, the key as a prop suggestion and the taxi as a vehicle suggestion. The ledger appears because of its explicit tag. The phone mentioned in dialogue should not become an action-derived prop. That difference is a simple check on whether the breakdown is respecting source context.
The second scene moves to an exterior platform at dawn and carries number 13. Eli has an off-screen cue. A flashlight appears in action, and a tagged skyline replacement appears under visual effects. A human reviewer might add platform access, crowd control, a dawn photography window and sound restrictions. Those requirements are not inferred merely because a heading says PLATFORM.
Now change “taxi” to “licensed picture taxi, stationary” in the editable vehicle field and add a note identifying the shot that needs it. Mark the scene reviewed only after checking the source. Download CSV and confirm that the edited vehicle wording appears. Save a project as well if you want to return to these edits without re-parsing the script and losing your production decisions.
Source references you can actually verify
Text imports use source line numbers. Blank lines and removed boneyard comments retain their place in that numbering, which helps you locate the original material. FDX imports use screenplay paragraph positions. A paragraph reference is useful within the imported FDX content, but it is not a page number in a differently formatted PDF export.
When the text contains explicit form-feed page breaks, the tool can include a source-page reference. Otherwise it does not manufacture screenplay pagination. Font choice, margins, dialogue wrapping and revision formatting all affect printed page boundaries. Counting a fixed number of lines and calling that a production page would give a misleading precision.
After editing a scene’s location or requirements, its source references continue pointing to the import that created it. If a new script draft adds twenty lines earlier in the document, the old line numbers do not magically relocate. Import the new draft, compare the changes, and decide which previous production notes need to be carried into the new project.
A scene’s heading text and references provide context, while its editable fields hold your working production interpretation. Preserve the original screenplay alongside the project file. If a collaborator questions a requirement, the shortest reliable review is to open the referenced scene and read the surrounding action, not to debate a detached spreadsheet cell.
Work through a scene in a repeatable order
First check the scene identity: number, interior or exterior, location and time. A room name such as “office” may refer to two different sets in one script. Add enough specificity in the editable location field for the team to distinguish them. Preserve the script’s scene numbering where it exists; do not casually renumber a locked draft to make a spreadsheet prettier.
Next check people. Read the dialogue cues, introductions, entrances and background activity. Verify whether an off-screen line needs a separate recording note. Confirm whether a named role appears under more than one spelling. Distinguish a character requirement from an actor assignment, because this tool records the former and does not maintain contracts or performer availability.
Then inspect physical and visual requirements. Read every action paragraph for handled objects, clothing changes, vehicles and effects. Add omissions manually. Remove a suggestion if the word describes something that will not appear. If a source phrase is ambiguous, write a decision question in notes and leave the scene unreviewed until someone resolves it.
Finally read the scene as a whole. The checklist categories cannot capture every constraint. A ringing bell may imply sound playback or postproduction work. A sunrise may impose a narrow lighting window. A child character may change production planning. Put concrete questions where the team can find them, then use the reviewed checkbox to record that you completed this pass rather than to imply every departmental decision is approved.
Sort for a meeting without changing the screenplay
Script order is the natural starting point because it follows the story. Location sorting helps discuss what happens in the same place across separate scenes. Time-of-day sorting can help identify night or dawn material that deserves a closer planning conversation. These are views of the scene records; they do not rewrite the underlying screenplay.
The grouped location summary lists scene references under a location name. The cast summary does the same for detected and manually entered role names. Consistent naming is essential. “Station office” and “Station manager office” remain separate labels unless you choose to standardize them. Automated merging could erase a real distinction between two sets, so the decision belongs to the person reviewing the script.
CSV, copied tables and printouts follow the current scene view. A saved project preserves the editable records for later work. Before distributing a location-sorted export, make the order clear in the filename or meeting notes. A collaborator expecting story sequence may otherwise mistake a changed view for a revised screenplay order.
No sorting choice creates a shooting schedule. Scheduling requires practical constraints the source does not contain, including travel, access, weather, performer availability and setup time. The breakdown provides inputs to that work. Use its grouped requirements to ask better scheduling questions, then move the agreed decisions into the production system your crew actually uses.
Choose the right export for the next person
CSV works well when collaborators need to filter, add columns or combine the breakdown with their own planning sheet. Every exported row includes the scene identity, cast lists, requirement categories, source reference, notes and review state. Cells are quoted so commas and line breaks inside notes do not accidentally create extra columns or rows.
Spreadsheet applications can interpret certain leading characters as formulas. The export prefixes potentially executable cell values with an apostrophe so script text is treated as text. That protective character may be visible in another application. It is preferable to allowing an imported screenplay line beginning with an equals sign to execute as a spreadsheet expression.
The JSON project is the resumption format. It retains scene fields and original extraction evidence, allowing a later browser session to reopen the reviewed breakdown. It is not a cloud backup. Save it somewhere you can find, and protect it with the same care as the screenplay because its notes and excerpts may reveal story material.
Copy is convenient for a quick discussion, while printing is useful for a scene review meeting. Wide breakdown tables are intended for landscape paper. Check the browser’s print preview, margins and scale before producing many pages. Long notes can require more space than short requirement lists, and your printer settings determine the final physical pagination.
Import and recovery boundaries
Opening a script creates a new extraction. Opening a saved project restores editable production data. These are different actions: re-parsing the original screenplay does not preserve every manual correction you made to an earlier breakdown. Use the project format whenever your intention is to continue the same review rather than start a fresh script pass.
After replacing an existing breakdown, the workspace offers an undo for the previous import. This is a short recovery aid, not a version-history service. Save a project before testing a substantially revised script. A downloaded project gives you an explicit checkpoint that survives closing the tab, refreshing the page or opening a different tool.
Invalid projects are rejected when their structure, identifiers, element lists or source references are unsuitable. Malformed XML is also rejected, and FDX documents with entity or document-type declarations are not accepted. These checks protect a predictable editing workflow. They do not promise compatibility with every proprietary export that happens to use an XML filename.
If no scenes appear, check the first heading in your source. A prose paragraph describing a room does not establish a screenplay scene. Try the provided sample to confirm the workspace works, then compare its heading and cue structure with your export. For a PDF-only script, return to the writing application and export an actual supported text or FDX format.
Use the breakdown to prepare a better next draft
An unexpectedly long requirements list can reveal a practical writing problem. Five brief scenes in five locations may be harder to produce than a longer scene in one place. A vehicle appearing for one line can require disproportionate coordination. The breakdown helps you notice these choices, but it does not decide that the cheapest version is always the best creative version.
Discuss each expensive or uncertain requirement in terms of the story function it serves. If the taxi merely establishes that Mara arrived, another image may communicate the same information. If a dawn platform is central to the ending, protecting that location and time may be worth simplifying elsewhere. Record the resulting choice in the screenplay and regenerate the relevant breakdown after the revision.
Use the shot-list editor when you are ready to specify individual camera views. The screenplay format checker serves a different job: reviewing the writing structure before production planning. For a guided route from story to finished short, follow the free Book-to-Screen course, then explore screenplay and film planning when you need a broader project workflow.
The format references behind this importer are the Fountain syntax guide and the structured screenplay paragraphs used by the repository’s FDX fixtures. The scene editor, export functions and fixture tests define this tool’s particular behavior. Requirements outside those tested rules remain part of your human script review, where production judgment belongs.
Check the reviewed count before sharing
The reviewed counter measures scene checkboxes, not parser confidence. If a two-scene project shows one reviewed scene, one record still needs your pass. Sorting the view does not change that count. Editing requirements after checking a scene does not automatically clear its review flag, so deliberately uncheck it when a new decision calls for another reading.
Before the final export, compare the number of scene records with the headings you expect in the current script. Investigate a missing scene rather than adding a note that nobody will see. A repeated location should create separate scene records when separate headings exist. A location grouping can combine their references for convenience, but it must never hide their individual cast, requirements or review state.