Pricing Dashboard Sign up
Recent

Word to Markdown for Publishers — Manuscript Processing

Publishers receive manuscripts from authors in Word — and most of the production pipeline (typesetting, EPUB generation, multi-format output, version control) wants Markdown or LaTeX. mdisbetter.com bridges author convention and production reality. Convert each incoming .docx, normalise the formatting, run through your editorial pipeline. Authors keep their familiar Word workflow; production gets clean structured input that flows into Pandoc-driven multi-format output (PDF, EPUB, MOBI, HTML).

Why this is hard without the right tool

  • Authors deliver in Word; production wants Markdown
  • Inconsistent formatting across manuscripts
  • Multi-format output (PDF, EPUB, MOBI) needs structured input
  • Editorial workflow benefits from version-controllable text

Recommended workflow

  1. Receive manuscript from author in .docx
  2. Run editorial review in Word with track-changes (the author UX they expect)
  3. Once edits are accepted, upload the clean .docx to /convert/word-to-markdown
  4. Download the Markdown output
  5. Apply house-style normalisation pass (chapter formatting, dialogue style, scene-break conventions)
  6. Feed into your production pipeline: Pandoc for multi-format output (PDF / EPUB / MOBI), or hand off to typesetters working in InDesign/LaTeX from the .md source

Why Markdown for book production

Markdown source enables: Pandoc-driven multi-format output (PDF, EPUB, MOBI, HTML, LaTeX from one source), Git-based version control of manuscripts (every editorial change tracked, rollback at any point), seamless typesetter handoff (LaTeX/InDesign workflows accept .md as starting point), and easy mass-correction passes (find/replace across the whole manuscript with regex). The .docx-only workflow has none of these — every output format requires manual rework, version history is fragile, and bulk corrections are slow.

The author keeps Word

Don't force authors out of Word. The familiar UX (track changes, comments, review cycle) is decades ahead of any Markdown editor and forcing the migration kills author satisfaction. The hybrid that works: author writes in Word, production converts at intake, production runs the rest of the pipeline in Markdown. Final ARC review with the author can come back to Word PDF if they prefer. Author never sees Markdown unless they want to.

For high-volume publishing operations

Publishing operations doing dozens of manuscripts per month should probably run Pandoc directly in their production pipeline rather than the web tool — same conversion engine, scriptable, no per-manuscript human step. mdisbetter is the right tool for smaller operations (1-10 books/month) or for ad-hoc author handoffs where the volume doesn't justify pipeline automation. Larger ops: invest in Pandoc-based pipeline.

Frequently asked questions

Will footnotes and endnotes survive?
Yes — Word footnotes and endnotes convert to Markdown footnote syntax (<code>[^1]</code> with corresponding definition). For book-length manuscripts with hundreds of footnotes, verify the numbering after conversion (rare for the order to break, but worth a spot-check). Pandoc renders Markdown footnotes correctly in PDF/EPUB output.
How are scene breaks and chapter formatting preserved?
Chapter formatting (H1/H2 headings) survives cleanly. Scene breaks (typically blank lines or asterisks <code>* * *</code> in the manuscript) usually survive but may need normalisation if the author used non-standard conventions. Build a quick post-conversion script or apply a regex pass to normalise scene-break markers to your house style.
Can I generate EPUB and PDF from the converted Markdown?
Yes — that's the whole point. Use <a href="https://pandoc.org/">Pandoc</a>: <code>pandoc manuscript.md -o manuscript.epub</code> for EPUB, <code>pandoc manuscript.md -o manuscript.pdf --pdf-engine=xelatex</code> for PDF. Style with custom CSS (EPUB) or LaTeX templates (PDF). One Markdown source, multiple output formats — the production-pipeline benefit Markdown delivers.
What about authors' tracked changes during editorial?
Track-changes is Word-only and doesn't survive conversion. Workflow: do the editorial review cycle in Word with track-changes (authors see your edits in their familiar tool), accept all changes when the manuscript is final, then convert the clean version to Markdown for production. Two phases: editorial in Word, production in Markdown.
Should I switch authors to Markdown directly?
Generally no. Author satisfaction is high-leverage; forcing them to learn Markdown and lose track-changes UX kills the author experience. A few technical authors might prefer Markdown — let those use it directly. The default flow keeps authors in Word and converts at production intake. Author UX = Word; production UX = Markdown.

Try the tool free →