Skip to content
screenjson

For screenwriters

ScreenJSON for Screenwriters

Why a working writer should care about treating their screenplay as structured data — and what that actually changes about the day-to-day of writing.

Last updated January 2026

The writing hasn’t changed. Everything around it has.

If you’ve been writing screenplays professionally for more than a few years, you’ve lived through Final Draft 8, Final Draft 10, Final Draft 11, the rise of Fade In, the rise of Highland, the rise of WriterDuet, Fountain becoming a thing, and a dozen web-based tools that either swallowed your last draft or vanished. And the file you hand off at the end of every one of those journeys is still, usually, a .fdx or a flat PDF.

That’s fine when the only consumer of your script is another writer or a reader. It stops being fine the moment a producer wants a breakdown, a studio wants to search their catalogue, a director wants a revision diff, a streamer wants localised subtitles, or — increasingly — an AI tool wants to understand your characters.

ScreenJSON is what happens when you stop treating those downstream needs as somebody else’s problem and start treating the screenplay as what it already is: a structured, hierarchical, typed document with stable identity for every character, every scene, every line.

You keep writing in whatever tool you like. ScreenJSON is what you export to, what your producer ingests, and what survives.

What changes for you, the writer

Your drafts become versionable. Every scene, every element, every line has a UUID. That means git diff — or any other diffing tool — can show you that scene 14 lost three lines, scene 22 got a new parenthetical, and everything else is identical. No more “I think this blue revision is the one, but I’m not sure.”

Your characters become real objects. When MARA speaks in scene 3 and MARA speaks again in scene 47, ScreenJSON knows it’s the same MARA — even if scene 47 writes her cue as MARA (V.O.) and scene 3 wrote it as plain MARA. A character list is a first-class part of the document, not something your producer’s assistant reconstructs from a regex.

Your translations live alongside the English. Every text field in ScreenJSON is a language map:

{ "en": "We have ninety seconds.", "fr": "Nous avons quatre-vingt-dix secondes." }

One file, every language. A renderer picks whichever language the reader asked for. No more “final_EN_v4.fdx” next to “final_FR_v4.fdx” next to “final_ES_v4.fdx” next to the inevitable “final_FR_v4_ACTUAL.fdx”.

Your notes have anchors. A note in ScreenJSON isn’t a floating comment; it’s a range of character indices inside an element, with a contributor UUID and a colour. Even after the surrounding text gets rewritten, the note knows which stretch of words it was attached to.

Your script can be encrypted without being opaque. If you’re working on something sensitive — a pre-announcement project, an unsigned pitch, a sequel with spoilers — ScreenJSON’s AES-256 encryption encrypts the text, not the structure. Your producer can still see how many scenes there are, how many speaking parts, how long the script is, without ever seeing a line of dialogue.

The everyday workflow

You don’t have to change your writing app. Final Draft, Fade In, Highland, WriterDuet — keep using them. The ScreenJSON layer lives alongside the thing you write in.

A normal day looks like this:

  1. You write in Final Draft.
  2. You export .fdx.
  3. You (or your tooling) run screenjson convert -i script.fdx -o script.json.
  4. That .json is what gets committed to your Git repo, sent to your producer, indexed in your agent’s system, shown in the collaboration tool you share with a co-writer.
  5. If anyone needs a Final Draft file back — the assembly editor, the line producer running a breakdown, the cinematographer — they run screenjson export -i script.json -f fdx -o script.fdx, and get a valid FDX out the other side.

You don’t have to touch the JSON. The JSON is just a more honest version of the file you were going to send anyway.

What about Fountain?

Fountain is a beautiful, minimal, plain-text format for writing — and ScreenJSON converts to and from it natively. Fountain solves the writing problem: a writer wants plain text they can edit in any tool. ScreenJSON solves the downstream problem: everyone else wants structure.

The two are complementary. Many writers we’ve spoken to write in Fountain, export to ScreenJSON for hand-off, and keep both side by side. Whichever one feels authoritative to you, keep writing it; ScreenJSON is the format your script arrives in at the places that aren’t your writing app.

Pushback and honest answers

“I don’t want another format.”

Fair. You aren’t getting one. You write in the tool you already use; the conversion to ScreenJSON is automated and reversible. Think of it as “save as” to a format that doesn’t lose anything.

“What if a tool downstream doesn’t understand ScreenJSON?”

Then you export back to whatever it does understand — FDX, Fountain, FadeIn, PDF. ScreenJSON can produce all of them.

“Is this going to end up locked to one company?”

The schema is open. The reference implementation is open-source. The licensable parts are the production-grade CLI and the batch service, not the format itself. You can always get your script back out.

Start somewhere small

  • Export your current project to .fdx.
  • Run screenjson-export once, locally, with Docker.
  • Open the resulting .json in a text editor.
  • See if it looks like your screenplay.

That’s the whole onboarding. The moment you want more — multiple formats, validation, encryption, API access — the full CLI is a drop-in upgrade.

Next