Compiling Your Scrivener Manuscript for KDP, EPUB, PDF and Word

If you drafted your book in Scrivener, the binder is only half the job. At some point that collection of folders, documents, and scenes has to become a single file you can actually upload somewhere, a Word document for an editor or a submission, a PDF to sanity-check your layout, or an EPUB or MOBI-equivalent file ready for KDP. That's what Scrivener's Compile feature does, and it's also where a lot of authors hit friction, not because Compile is broken, but because it's a genuinely deep tool with a learning curve that isn't obvious from the interface.

This guide walks through what Compile actually does, how to set it up so your chapter breaks and headings come through correctly, the practical differences between compiling to Word, PDF, and EPUB, the mistakes that trip up most authors, and a realistic pipeline for getting from a Scrivener binder to a finished, publishable book.

What Compile actually does

Compile takes the documents and folders in your binder, in whatever order you've arranged them, and assembles them into a single output file. It doesn't just concatenate your text: it applies a Compile Format, a set of styling rules that determines how each type of document (a chapter, a front matter page, a scene) should look and behave in the final file, what font size a chapter title gets, whether a new document starts on a new page, how paragraphs are spaced, and more.

This means Compile is really two decisions layered together: which documents from your binder go into the output and in what order (controlled by checkboxes in the Compile pane and your binder's own arrangement), and how each of those documents should be styled once it's pulled in (controlled by the Compile Format and the Section Layouts you assign to your content). Getting a clean result depends on both being set up correctly, and it's the second part, the styling layer, that causes most of the confusion.

Section Types and Section Layouts: the part most authors skip

The feature that makes Compile predictable rather than fiddly is Section Types. In Project Settings, you define a small set of types that describe what a document is: for a novel, that might be as simple as Chapter, Front Matter, and Back Matter. Each document and folder in your binder is then assigned one of these types, either automatically (Scrivener applies sensible defaults based on your binder structure) or manually, from the Section Type column in the Outliner or Inspector.

Section Types by themselves don't control appearance. That's the job of Section Layouts, which live inside the Compile Format editor. A Section Layout defines the actual formatting for a given Section Type in this particular output: does a Chapter get a page break before it, a large drop number, a centered title in a specific font, and does the Title text itself get pulled from the document's title in the binder or suppressed? You map each Section Type to a Section Layout in the Compile pane's assignment list before you run Compile.

The reason this two-step system matters: it's what lets you compile the same binder into wildly different looking outputs (a plain manuscript format for an editor, a styled book interior for EPUB) without touching your actual content or reorganizing your binder. Skipping it and just hitting Compile with default settings is exactly how authors end up with chapter titles that look wrong, missing page breaks, or a front matter page that reads like a chapter.

Compiling to Word (.docx)

A Word export is the right choice when your file needs to go somewhere that expects a standard manuscript document: an editor, a proofreader, a beta reader, a literary agent, or as a source file to hand to a separate formatting tool. When compiling to .docx, keep the styling intentionally plain. Most editors and formatting tools work better with simple heading styles (Scrivener's default manuscript-style Compile Format uses standard Word heading levels for chapter titles) than with heavily styled fonts and spacing that will just get stripped out or reformatted downstream anyway.

One detail worth checking before you compile to Word: whether Scrivener's Compile Format is mapping your chapter titles to actual Word heading styles (Heading 1, Heading 2, and so on) rather than just bold, larger body text. If your next step is importing that Word file into another formatting tool, real heading styles are what let that tool auto-detect your chapter structure. Bold text that looks like a heading but isn't tagged as one won't be recognized the same way.

Compiling to PDF

Scrivener can compile directly to PDF, and it's a genuinely useful way to get a quick look at how your manuscript flows on a page, checking overall length, skimming for obvious formatting issues, or sharing a read-only copy with someone who doesn't need to edit it. What it is not is a print-ready interior file for KDP or IngramSpark. A Compile-generated PDF typically won't have running headers with your book's title and your name, correctly mirrored inside/outside margins for a bound book, widow and orphan control, or a matched front matter sequence with a proper title page and copyright page laid out the way print buyers expect.

Treat a Compiled PDF as a proofing tool for your text, not as the file you upload to a print platform. Getting a genuinely print-ready interior means running your manuscript through a dedicated interior design pass afterward, whether that's manual page layout software or a tool built specifically for book interiors.

Compiling to EPUB and MOBI

Scrivener's built-in EPUB export is functional: it produces a valid EPUB file with your chapters in order, and for a straightforward manuscript, that can be enough to get a working file onto a retailer. MOBI is also available as a legacy Compile format, though modern KDP now accepts EPUB directly, so the MOBI path is only worth using if a specific reason calls for it.

Where Scrivener's EPUB output tends to fall short is polish and design control: options for matching your interior typography to your genre, fine control over drop caps, scene break styling, a designed title page, and consistent handling of front and back matter tend to be limited compared to a tool built specifically around ebook and print interior design. The EPUB Compile does the structural job (a valid file with your content in the right order and readable headings) without doing much of the design job.

For more on what makes an EPUB well-built beyond basic structure, semantic markup, CSS, font embedding, and accessibility, see our EPUB formatting best practices guide.

Common Compile mistakes

Front matter and back matter documents tagged incorrectly

A frequent issue: a title page or copyright page sitting in the binder without the right Section Type assigned, so Compile treats it as a Chapter and applies chapter-style formatting, a large chapter number, a page break rule meant for fiction chapters, to a page that should look completely different. The fix is making sure every front and back matter document has its Section Type set correctly before you compile, not relying on Scrivener to guess correctly from position alone.

Inconsistent heading levels breaking the table of contents

If some chapter titles in your binder are actual document titles at the top level and others are nested inside sub-folders (say, part divisions), Compile can end up applying different Section Layouts to what should be visually identical chapter headings, or omitting some chapters from the navigation entirely. The result is a table of contents with inconsistent formatting or gaps, which is often confusing to trace back to its cause because the manuscript text itself looks fine, it's the underlying structure that's inconsistent. Keeping your binder's hierarchy consistent (every chapter at the same nesting level, using the same Section Type) avoids this class of problem entirely.

Assuming Compile handles chapter numbering and title formatting for you

Scrivener can auto-number chapters using placeholder tags in your Section Layout's title formatting (so you don't have to type "Chapter One," "Chapter Two" manually into every document title). Authors who don't set this up sometimes end up with either no chapter numbers at all, or numbers that are hardcoded into document titles and become wrong the moment a chapter gets reordered or deleted during revision. Using the auto-numbering placeholder in your layout, rather than typing numbers by hand, keeps this correct through structural changes.

A realistic pipeline: Scrivener to a finished, formatted book

Given what Compile is genuinely good at and where it tops out, the pipeline that works well for most authors looks like this:

1. Draft and organize in Scrivener. Use the binder, corkboard, and outliner for exactly what they're built for, structuring, reordering, and tracking a long manuscript while it's still taking shape.
2. Set up Section Types and a clean Compile Format once your structure is stable. Tag every document correctly (Chapter, Front Matter, Back Matter) rather than leaving it to defaults, and verify the Section Layout assignments before your first real compile.
3. Compile to a clean Word document, using simple, correctly-tagged heading styles, once your manuscript is drafted and structurally finished.
4. Move to a dedicated formatting tool for the actual interior design and export. Import that Word file into a tool built around print and EPUB interior design, where structure detection, typography, and export to EPUB, print PDF, and DOCX are the core job rather than a secondary feature.

This isn't a knock on Scrivener, which remains one of the best tools available for the drafting stage. It's recognizing that Compile is an export mechanism built primarily to get your content out of the binder in a usable form, not a full book design tool, and pairing it with something that is closes the gap. For a closer look at how the two tools divide that work, see our LiberScript vs Scrivener comparison.

Common Compile issues and fixes

Frequently asked questions

Do I need a different Compile Format for every output type?

Generally yes, or at least a separate configuration within Compile for each target. A format tuned for a plain Word manuscript (simple headings, no drop caps) looks very different from one tuned for an EPUB with styled chapter openings. Scrivener lets you save and reuse formats, so you can build one for "editor submission" and another for "EPUB draft" and switch between them rather than reconfiguring from scratch each time.

Can Compile produce a print-ready KDP paperback file directly?

It can produce a PDF, but "print-ready" involves details Compile isn't built to handle well on its own: mirrored margins for binding, running headers with your title and byline, and consistent widow and orphan control across the whole manuscript. Most authors compile to Word or a plain PDF from Scrivener, then do the actual print interior design in a tool built for that job.

Why does my table of contents look wrong even though my chapter titles are correct?

This is almost always a Section Type or binder hierarchy issue rather than a text problem. Check that every chapter has the same Section Type assigned and sits at a consistent level in the binder; Compile builds its navigation and heading styling from that structure, not from how the title text looks on the page.

Should I compile to MOBI or EPUB for KDP?

EPUB. KDP now accepts EPUB files directly, and MOBI is a legacy format kept in Scrivener mainly for older workflows or platforms that still expect it. Check KDP's current file requirements before uploading if you're unsure which formats are currently accepted.

Is it worth learning Compile in depth, or should I just export to Word and format elsewhere?

For most authors, a solid understanding of Section Types and basic Compile Format setup, enough to get a clean Word or EPUB export, is worth the time. Going deeper into Compile's more advanced styling options mainly pays off if you plan to publish many books from Scrivener and want a reusable format; if you're publishing once or twice, exporting cleanly and finishing design in a dedicated formatting tool is usually the faster path.

The bottom line

Compile is a genuinely capable export engine once you understand its two layers, Section Types that describe what a document is, and Section Layouts that describe how it should look, and it's worth setting those up properly rather than accepting Scrivener's defaults. But Compile is built to get your manuscript out of the binder, not to be the finishing tool for a professional print or EPUB interior. The pipeline that works reliably: draft and organize in Scrivener, compile to a clean Word or EPUB file once your structure is set, then hand that file to a tool built specifically for interior design and export.

For the KDP-specific checks worth running before you upload any file, see our KDP formatting checklist. For a deeper structural comparison between the two tools, see LiberScript vs Scrivener. To bring a Word or EPUB export in from Scrivener and finish the interior design and export, get started in LiberScript.