What software do publishers use for books? The real stack

Publishers use a chain of tools, not one program. The manuscript lives as a `.docx` in Microsoft Word through drafting and editing; page layout moves into a dedicated application such as Adobe InDesign, Affinity Publisher or Scribus, or into a template-driven formatter such as Vellum or Atticus; the book leaves as a print PDF and a reflowable EPUB; and the commercial record — title, contributors, subject codes, publication date — sits in a metadata system that never touches the layout file.

That list is the answer most people are looking for, and it is the least useful part of it. The question "what software do publishers use for books?" has a list answer and a structural answer. Tool names churn every couple of years. The handoffs don't. Learn which file crosses each boundary and what gets destroyed in transit, and you can pick a stack in an afternoon and still be right for the next five titles.

The stack in the order the file moves through it

One rule governs the whole chain: the source of truth moves exactly once, at typesetting. Before that moment, the `.docx` is the book. After the layout file exists, the `.docx` is a historical document. Teams that keep editing the manuscript once typesetting has begun end up with two books and no defensible way to say which one is correct — this is the single most common way a schedule slips by a week without anyone doing anything wrong.

Why the manuscript stays in Word longer than anyone expects

Word survives in professional publishing for one unglamorous reason: tracked changes with attributable authorship, plus comments, is still the interchange format that editors, authors, agents and freelancers can all open without negotiation. Google Docs handles the same job for teams that live in a browser, and its suggestion mode maps cleanly onto tracked changes. Scrivener and similar drafting environments are genuinely good at the writing stage and largely irrelevant after it, because their job ends at "compile to `.docx`".

The handoff that matters is styles, not software. A manuscript where every chapter heading uses a named style called `Chapter Title` imports into a layout application as structure. A manuscript where headings are 18pt bold, centred, typed by hand imports as a wall of unstructured text that someone has to re-mark by eye. The same document looks identical on screen in both cases. That is why the difference survives all the way to the typesetter, and why the typesetter is the one who discovers it.

If you are handing off to someone else, ask for their style sheet before the copy edit, not after. Retrofitting styles onto an edited 90,000-word manuscript is an afternoon of tedious work that nobody budgeted for.

What a typesetter checks before accepting a manuscript

• Every heading level uses a named style, and the levels are consistent from chapter one to the end.
• No manual line breaks or empty paragraphs used to force spacing.
• Images supplied as separate files at original capture resolution, not pasted into the document.
• Notes are real footnotes or endnotes, not superscript numbers typed by hand with a list at the back.
• Special characters (curly quotes, en and em dashes, accented names, any non-Latin script) are in the text, not approximated.

Page layout: where the trade stack and the indie stack split

Trade publishing sets pages in a page-layout application because the book has a designed grid: baseline alignment across a spread, running heads that change per chapter, anchored figures, controlled hyphenation. Independent publishers with text-only books often skip that entirely and use a template formatter, where you pick a design and the tool re-flows the whole book into it and exports print PDF and EPUB in one pass.

Neither is a better tool. They fail in different places, and the decision is mechanical:

• Template formatter fits when the book is running text with fewer than roughly five pinned artifacts per 100 pages (a pinned artifact being anything that must land on a specific page: a full-page image, a table that cannot break, an epigraph facing a part title).
• Page-layout application fits when you have more than about 30 pinned artifacts in the book, a designed grid you need to hold, or a series look that has to match across titles set years apart.
• Between those numbers, choose on who else has to open the file — which is usually the deciding factor anyway.

Before you plan a schedule around any specific tool, check its current system requirements and export list on the vendor's own documentation. Platform restrictions and output formats change between versions, and a tool that only runs on hardware your designer doesn't have is not a candidate regardless of how it scores.

The reflow arithmetic that should pick your tool

Here is a model you can run on your own book. Take a 320-page paperback with 32 chapters, each starting on a fresh recto — 10 pages per chapter on average.

A late correction that changes the line count reflows text from the correction point to the end of that chapter, because the next chapter is pinned to a new page. A correction landing at a random point in a chapter therefore puts about half a chapter — roughly 5 pages — back into play for re-checking.

A normal proof round produces nine corrections spread across the book. Nine corrections × 5 pages = 45 pages to re-check, about 14 percent of the book, for nine changed lines. Run three proof rounds and you have re-read 135 pages of a 320-page book while the text changed on 27 lines.

The template formatter has the opposite profile. It re-flows all 320 pages deterministically every time you export, so you never re-check pages for line-position reasons — but every pinned artifact in the book goes back into play on every export. Whole-book re-flow is cheaper to verify when there are few pinned artifacts; partial re-flow is cheaper once anchored objects outnumber the pages you would otherwise re-check.

That is the whole trade-off, and it is why the same tool is right for a novel and wrong for a cookbook.

The same arithmetic, in hours

Pages to re-check are only a proxy. Here is what the two profiles cost on a 320-page novel with three proof rounds, at a proofreading rate of 4 minutes a page.

For a novel, that is not close. Now the cookbook, where the picture inverts: 180 anchored images, and every export puts each one back into play at roughly 30 seconds to verify placement.

The cookbook does not flip the verdict — it widens it. What flips it is the third case nobody models: a reference book updated annually. There the whole-book tool re-exports 320 pages in minutes with no manual step, while the layout tool needs its 9 hours again every single year. Over five editions that is 45 hours against roughly 2.

So the real question is not novel versus cookbook. It is how many times this file will be exported over its life. Once or twice: partial reflow. Every year: whole-book.

The three-format equality test

Before you commit a title to any tool, put one chapter through the entire chain and export print PDF, reflowable EPUB, and whatever preview the retailer generates from your file. Then check eight things across all three:

1. Table-of-contents depth and whether the EPUB navigation matches the print levels.
2. Note numbering and linking, especially if footnotes convert to endnotes.
3. Image resolution after the tool's own downsampling, per output.
4. Hyphenation and justification — present in print, usually off in reflow. Is that intentional?
5. Widow and orphan control, and whether the tool honours the setting you gave it.
6. Drop caps, small caps and ornaments, which are the usual first casualties in EPUB.
7. Diacritics, dashes, curly quotes and any non-Latin characters.
8. Hard page and section breaks — do part titles still start on a recto?

Use the messiest chapter, not chapter one. Pick the one with a table, a block quote, a figure and a footnote in it. A tool that misses three of the eight is not usable for that title — which is a scoping judgement about this book, not a verdict on the software.

The nine metadata fields that must match everywhere

Metadata is software too, and it is the stage that gets skipped because it feels like admin. The failure mode is duplication: the same book is described in a distributor portal, a retailer dashboard and a spreadsheet, and the three descriptions diverge. Nine fields have to be byte-identical everywhere they appear:

title · subtitle · contributor name form · ISBN (one per format) · imprint · publication date · edition statement · series name and number · subject codes (BISAC, Thema, or both)

Contributor name form is the one that bites. "J. A. Smith", "J.A. Smith" and "Jo Smith" produce three author pages across a catalogue, and consolidating them afterwards means contacting each channel separately. Decide the exact string once, write it in the title record, and copy it from there — never retype it.

Keep one file as the metadata source of truth and treat every portal as an output of it. That is the same discipline as the layout rule above, applied to the commercial record.

A 100-point scorecard for choosing book production software

Score each candidate against your actual next title, not a hypothetical one.

Thresholds: below 60, don't adopt. Between 60 and 79, pilot it on one title and re-score after the first proof round, when the correction cost is measured rather than guessed. At 80 or above, standardise and write the style sheet.

Exit cost gets underweighted by almost everyone, because it only matters years later — when a backlist title needs a reissue and its source file is in an application that no longer runs.

The scorecard, run once

The 100-point scorecard above is only useful once you have seen it produce an answer. Both tools below are composites.

The result flips if you delete one row. Remove *three-format equality* — a print-only monograph — and Tool A goes to 32 of 80 while Tool B goes to 74 of 80; still B. Remove *reflow* as well and it is 27 of 55 against 49 of 55. Tool A never wins on this scorecard, which tells you the weights were built for a multi-format publisher.

That is the check to run before you trust any scorecard, including this one: delete the rows that do not apply to you and see whether the ranking survives. If a single 25-point row is carrying the verdict, you are not comparing tools, you are restating a weighting decision you made earlier.

What usually goes wrong

Formatting done twice. The author spends a weekend making the `.docx` look like a book; the typesetter strips all of it in the first ten minutes. Tell authors what to leave alone before they start, not after.

Image resolution discovered at the print proof. Screenshots and web-sourced images are fine on screen and unusable in print. Catch it at manuscript acceptance by checking pixel dimensions against the printed size you plan to use.

Corrections marked on the PDF and never applied to the layout file. The next export silently reverts them. Every correction round needs one owner and one file.

Font licence terms assumed rather than read. Embedding a typeface in a PDF and embedding it in an EPUB are separate permissions in most licences. The terms are in the licence you bought, not in the application — read them before you set the book, not before you upload it.

The tool chosen for the first book, not for the shelf. A stack that produces one title beautifully and cannot reproduce it in three years is a stack that quietly makes reissues expensive.

Publishing operations of any kind converge on the same shape: one source of truth, explicit gates between stages, and outputs generated rather than hand-maintained. If you run a web publishing operation alongside a book programme, the parallels are close enough to be worth stealing from — the same logic drives content operations software evaluation and the separation between the system that decides what ships and the system that serves the page, described in publishing control plane software. The approvals layer is the same problem again, one level up: see editorial workflow software.

Questions people actually ask

What do commercial publishers use to lay out pages?

A page-layout application rather than a word processor, because the grid, running heads and anchored figures are not things a word processor manages. The practical question isn't which application is most widespread — it's which file formats the person setting your book can open and hand back. Ask for that list (`.indd`, `.idml`, ICML, packaged fonts and links) before you commission. If all you get back is a flat PDF, you don't own your layout.

Is there free software for book layout?

Scribus covers page layout, LibreOffice Writer handles styles and PDF export, and Google Docs works for drafting and editing. The trade-off is that free tools rarely span the whole chain, so you bridge the gaps by hand — most often EPUB generation and note handling. Run the three-format test on a real chapter before committing a title to one.

What software do most authors write in?

Whatever they like, and it usually doesn't survive the handoff. Scrivener, Ulysses, Word, Docs and plain Markdown all export or compile to `.docx`, which is what the editor and typesetter work from. Questions of the form "what does novelist X use" get asked constantly; the honest answer is that the drafting application is the least consequential choice in the chain, because its output is normalised the moment editing starts.

Do I need separate tools for print and ebook?

Not if the book is running text — one source can produce both. You need separate treatment when the design is fixed-layout, because a reflowable EPUB cannot hold a designed spread. Check the target retailer's own fixed-layout specification before designing to it.

How much does an author earn per copy?

That's a contract question, not a tooling one. Verify it from two documents: the royalty clause in your publishing agreement (rate, whether it's calculated on list price or net receipts, and any escalators), and the published royalty terms for the specific channel you're selling through. A single per-copy figure quoted without both of those is a guess.

When this framework flips

Everything above assumes a book whose source of truth becomes a layout file. Two categories break that assumption.

Academic, scientific and technical books are often produced XML-first: the source of truth is structured XML or LaTeX, and print PDF, EPUB and HTML are all generated outputs rather than hand-set artifacts. If your book has equations, cross-references that renumber themselves, a bibliography that regenerates from a database, or chapters that will be chunked onto a platform, the drafting-app question is simply the wrong question — a LaTeX or Markdown-to-toolchain pipeline fits the material better than any page-layout file will.

Illustrated children's books, cookbooks and art books flip the other way. The image is the page, the layout is the content, and the design starts in a page-layout application on day one. A reflowable EPUB may not be a sensible output at all; check what fixed-layout formats your intended channels accept before you design a single spread, because that constraint decides the trim size, and the trim size decides everything else.