Export to DOCX, import it at the other end, and check the result yourself, because the honest answer to "what survives?" is that nobody publishes it.
No writing application vendor publishes a round-trip fidelity matrix. There is no authority to appeal to. Any guide that tells you confidently what will and will not survive a specific move between two specific apps is guessing, and the only reliable method is a test file.
What the Format Authorities Do Say
Three findings that change how you should think about this.
DOCX is an open standard that is still lossy in practice
The Library of Congress describes DOCX as an "International open standard. Maintained by ISO/IEC JTC1 SC34/WG4", standardised as ISO/IEC 29500 in 2008, with "None beyond XML-aware software" as its external dependencies. That is about as good as interchange formats get.
But two things undercut it. The specification is enormous: "The standards documents that specify this format run to over six thousand pages." And there is a variant trap. The Library of Congress found that non-Microsoft applications write the Transitional variant rather than the Strict one "even when the document includes no elements or attributes not present in the Strict versions of the schemas."
The Library of Congress also names your actual failure mode directly: differences on display can occur "if the original fonts used are not available in the system used for viewing or due to conversion from another word-processing format with different markup semantics."
That last clause is the whole problem. Two apps can both write valid DOCX and still disagree about what a given piece of formatting means.
RTF is worse than its reputation, and it matters more than you think
RTF is widely recommended as the safe interchange format. The Library of Congress record makes that hard to sustain.
It is "proprietary... developed and maintained through several versions by Microsoft Corporation through 2008." Microsoft's own 2010 statement: "The RTF file format is no longer enhanced to include new features and functionality. Features and functionality that are new to Word 2010 and future versions of Word are lost when they are saved in RTF."
Word's own Save As dialog warns that saving to RTF "does not reliably preserve the formatting, layout, or other features of the document."
Support varies invisibly: "such support may be based on a subset of control words or a chronological version other than the latest (version 1.9.1)", and "The version supported may not be obvious from product documentation."
And it has no Unicode: "RTF does not use a UTF encoding." For a manuscript with accented names or non-Latin text, that is a live corruption risk rather than a theoretical one.
Why this matters more than it looks: Scrivener stores document text as RTF inside its project package. We know this first-hand, because Deckle's Scrivener importer has to parse those RTF files to read your manuscript. So the tool most novelists are pointed at keeps their prose in a format Microsoft froze in 2008, warns about in its own save dialog, and never gave Unicode encoding.
Our importer also ran into exactly the undocumented-subset problem the Library of Congress describes: Scrivener's RTF writer embeds TIFF and BMP images using no standard RTF keyword of their own, so reading them required handling a behaviour no specification describes.
There is no authority behind "plain text and Markdown are archival"
This one is a clean negative and it kills a claim you will see everywhere.
The Library of Congress maintains format descriptions for hundreds of formats. There is no entry for Markdown, and none for plain text, ASCII or UTF-8 as document formats. So "the Library of Congress recommends plain text for long-term storage" is not something you can source from their format assessments.
Plain text and Markdown have real virtues, chiefly that you can read them in anything and they carry no proprietary structure. Just do not attribute those virtues to an authority that has not assessed them.
Microsoft's own format table is blunt about the cost, noting that .txt "loses all formatting" and that .odt means "Formatting might be lost."
What Actually Survives, Roughly
Stated as tendencies, since no vendor publishes the specifics:
Almost always survives: the words, paragraph breaks, bold and italic, and heading structure when it comes from real styles.
Usually survives: chapter divisions, if the source used heading styles rather than manual formatting.
Often lost: comments and tracked changes, footnotes in some directions, custom styles, and anything the source app stored outside the text such as synopses, labels, status flags and corkboard notes. Those live in app-specific structures with no equivalent in a document format.
Reliably lost: page layout, since it belongs to the output rather than the manuscript, and anything using a proprietary extension.
The general rule: structure expressed as styles moves; formatting applied directly does not. This is the same reason a manuscript sent to an editor should use styles.
How to Test It Properly
Twenty minutes here saves a lot of repair work.
- Make a small test file in the source app containing everything you actually use: two chapters, a scene break, italics, a footnote, a comment, an image with a caption, an em dash, curly quotes, and any accented or non-Latin characters in your book.
- Export it in the format you plan to use, usually DOCX.
- Import it into the destination app.
- Check each item against the list. Note what is missing rather than assuming.
- Then move the real manuscript, knowing what to expect.
Do this before you commit, not after. And keep the original project until you are certain, because an import is not a migration until you have checked it.
What Deckle Imports and Exports
There is an asymmetry worth knowing before you plan a move.
Deckle imports three manuscript formats: DOCX, EPUB, and Scrivener projects as a zipped .scriv package. There is no RTF import, which on the evidence above is not much of a loss.
Markdown is deliberately different: it imports as research material via a folder picker, not as a manuscript. The reasoning is documented in the code: a single loose .md file has no vault to resolve wikilinks against, and offering it in the manuscript picker alongside DOCX and EPUB confused people who expected to choose a folder.
Deckle exports five: DOCX, EPUB and PDF from Compile, plus Markdown and plain text on a separate path.
So a manuscript can come in from Word, from a published EPUB, or from Scrivener, and can leave as any of five formats. Moving to Deckle from a Scrivener project preserves considerably more than a DOCX round trip would, since the importer reads the project structure directly rather than a flattened document. That is covered in moving from Scrivener to Deckle.
For the Word side specifically, see formatting your Word manuscript for import, and for the underlying choice, writing a novel in Word vs dedicated software Scrivener alternatives and best novel writing software.
Common Mistakes
- Using RTF as your safe format. Frozen since 2008, no Unicode, and Word warns about it itself.
- Trusting a fidelity claim you read somewhere. No vendor publishes one. Test it.
- Moving the whole manuscript first. Move a test file first.
- Deleting the source project after import. Keep it until you have verified everything.
- Expecting notes, labels and synopses to travel. Those are app structures, not document content.
- Citing an authority for plain text durability. The Library of Congress has not assessed it.
FAQ
Q: What format should I use to move a manuscript? A: DOCX. It is an open ISO standard and universally supported, though not perfectly lossless.
Q: Is RTF safer than DOCX? A: No. It is frozen at 2008, has no UTF encoding, and support varies invisibly between applications.
Q: Will my comments and tracked changes survive? A: Often not. Check them specifically in your test file.
Q: Is Markdown a good archival format? A: It is readable and unproprietary, but no format authority has assessed it, so do not claim more than that.
Q: Why does my formatting look different after importing? A: Usually missing fonts, or two apps disagreeing about what a piece of markup means. The Library of Congress names both.