File Format Compatibility for Novelium

You've finished a sprawling manuscript, exported it, and uploaded it for analysis. The file opens. The word count looks plausible. Nothing flashes red. Then the report starts returning nonsense: chapters have swallowed their scene breaks, a viewpoint character appears to narrate scenes they never enter, and a recurring object seems to vanish between two paragraphs.

That's the ugly part of file format compatibility. A document can open perfectly in your word processor and still arrive in an analysis tool with its structure damaged. For a long novel, especially one with multiple viewpoints, recurring characters, nested timelines, or a large cast, the import file isn't packaging. It's evidence. If the structure is wrong, the conclusions are wrong.

Why File Format Compatibility Determines Analysis Quality

A writer with a 90,000-word manuscript doesn't need another generic reminder to save a backup. They need to know why a file that looks normal on screen can fail when another system reads it.

A Word document may display a chapter title exactly as intended while storing it as manually enlarged text rather than a heading style. A scene break may look like a clean blank line, yet contain several paragraph returns, a tab, and a decorative character. Copying from Google Docs can preserve the words while stripping the hierarchy that told the parser where chapters and scenes begin. Plain text removes that hierarchy altogether.

The result isn't always an obvious import error. More often, the document imports and the damage hides in the analysis. The system may treat an entire chapter as one scene, attach dialogue to the wrong structural unit, or miss the point where a new POV begins. That makes character appearances, timeline extraction, and continuity checks less reliable.

Practical rule: If your manuscript's structure exists only in visual appearance, it doesn't reliably exist for an importer.

This is why format choice belongs in the revision workflow, not in the last-minute technical chores. DOCX, RTF, Scrivener exports, and TXT files carry different amounts and kinds of structure. OOXML, the XML-based package used by modern Word formats, is standardized under ECMA-376, but standards compliance doesn't guarantee that every application interprets every style, relationship, or conformance profile identically.

The practical test is simple: can the receiving tool identify the same chapters, scenes, paragraphs, emphasis, and metadata that you can? If not, you're not importing a manuscript. You're importing a reconstruction problem.

Supported Import Formats and Preparation Requirements

Novelium accepts Microsoft Word files, Scrivener compiled exports, Google Docs files downloaded as Word documents, plain text, and Rich Text Format. Each can work, but none should be uploaded casually. The cleanest import usually comes from a file prepared specifically for analysis rather than one exported for printing or submission.

Microsoft Word and Google Docs

For Word, apply Heading 1 to chapter titles and Heading 2 to scene breaks or scene headings. Don't simulate hierarchy with bold type, larger fonts, centered alignment, or repeated blank paragraphs. Remove decorative spacing and tab-based dialogue indents where possible. Those choices may look harmless, but they create ambiguous paragraph boundaries.

Google Docs should travel through File, Download, Microsoft Word (.docx). Copying and pasting into another application is the wrong route because it can flatten heading levels and discard comments or other document metadata. After downloading, open the DOCX in Word or another compatible editor and verify that the heading styles remain attached to the intended paragraphs.

Scrivener, RTF, and plain text

Scrivener users should compile through the Manuscript preset, select DOCX or RTF as the output, and enable metadata inclusion where the compile panel provides it. Don't export directly from the binder and assume the binder's visual organization will survive. Binder structure and compiled document structure are separate things.

RTF remains usable, but old word processors often leave behind hidden formatting codes. If the file has passed through several editors, open it in a current word processor, save a clean copy, and inspect the scene separators before importing.

Plain text needs discipline. Use one consistent scene delimiter, such as ### or ***, and place a blank line between paragraphs. Don't alternate between symbols, centered asterisks, extra blank lines, and ornamental rules.

What Happens During the Import Process

An importer doesn't see a page. It sees a package of content, styles, relationships, and metadata. In a DOCX file, the application reads the underlying Office Open XML package, then identifies paragraph properties, heading styles, character formatting, and the relationships connecting the document's internal parts. In a TXT file, it mostly sees characters and line endings, so it must infer far more.

The parser then turns those elements into a hierarchy. Chapters act as parent nodes, scenes sit beneath them, and paragraphs become the units attached to structural and interpretive metadata. That hierarchy matters because a character mention inside a chapter isn't equivalent to a character appearance inside a specific scene with a particular viewpoint and location.

Where format-specific damage appears

A DOCX with inconsistent heading styles can create orphaned sections. A Google Docs export may preserve the visible text while flattening distinctions between heading levels. Scrivener's compiled file can carry useful organizational information, but only if the compile settings turn the project's internal organization into document structure.

Plain text is the most transparent format and the least informative. It doesn't carry style hierarchy, comments, revision history, or embedded metadata. The parser has to rely on delimiters, blank lines, and predictable patterns. If those patterns change midway through a manuscript, the resulting tree can break without producing a dramatic error.

The final stage is validation. The system checks for missing chapter boundaries, duplicate scene identifiers, conflicting metadata, and other structural anomalies. Treat those warnings as evidence, not administrative clutter. A missing break can disable scene-level analysis, while a duplicated identifier can cause two distinct scenes to be treated as one.

OOXML adds another complication. ISO/IEC 29500 distinguishes Strict and Transitional conformance, so “supports DOCX” isn't a sufficiently precise compatibility statement. A workflow that depends on round-trip fidelity should establish which profile the source and destination tools handle, especially when documents move between different suites.

Comparing Format Fidelity Across Word Scrivener Google Docs and Plain Text

There's no universal winner because writers ask formats to do different jobs. A revision-heavy DOCX needs to preserve editorial structure. A Scrivener export needs to translate project organization into a compiled manuscript. A Google Docs file needs to survive a download without losing its headings. Plain text needs to provide reliable content when all visual decoration is expendable.

The useful comparison is not “which file opens?” It's “what survives the crossing?” Structural fidelity covers chapters, scenes, headings, and paragraph boundaries. Metadata retention covers comments, annotations, revision information, and project labels. Cleanup effort measures how much manual repair stands between import and trustworthy analysis.

Word is usually the safest general-purpose interchange format, but it's also the format most likely to carry invisible baggage. Tracked changes, copied styles, text boxes, embedded objects, and pasted content from other applications can all complicate parsing.

Scrivener is excellent for modular drafting, provided the compile process is intentional. Its binder is not a magic passport. If scene separators, heading levels, and annotations aren't mapped during compilation, the receiving tool gets a flattened approximation.

Google Docs works best when the writer downloads a DOCX and checks the result before import. Plain text is honest but stripped down. It won't pretend to preserve hierarchy it never contained.

For a closer look at the practical differences between the two workflows, see Novelium versus Scrivener.

Export Settings That Preserve Manuscript Structure

The best export is the one that makes structure explicit. Don't optimize for how the manuscript looks in the source application. Optimize for what another application can identify without guessing.

Scrivener

Open File, Compile, choose the Manuscript preset, and select DOCX when you need heading hierarchy and a richer interchange file. Map chapter folders to Heading 1 and scene documents or scene separators to Heading 2. Preserve section separators rather than replacing them with visual spacing. If annotations need to remain available for later review, configure them as comments or another supported output element instead of leaving them trapped inside the project.

RTF can be useful for a simpler export, but it gives you less confidence when the project contains nested organization or legacy formatting. Inspect the compiled file, not just the compile preview.

Microsoft Word

Before saving, accept or remove tracked changes if they aren't part of the analysis target. Revision markup can make paragraph boundaries harder to interpret, particularly when a paragraph has been repeatedly split and recombined. Keep chapter titles in Heading 1 and scene markers in Heading 2. Don't rely on manual page breaks as scene indicators.

Use File, Save As, Word Document (.docx). If the file has been assembled from multiple sources, select all content and inspect the Styles pane for accidental heading assignments. Smart quotes usually render correctly in modern workflows, but a document containing mixed encodings or copied legacy text should be normalized and checked before upload rather than trusted blindly.

Google Docs

Use File, Download, Microsoft Word (.docx). Don't use plain text when the manuscript's chapter and scene hierarchy matters. After downloading, inspect several chapters throughout the file, including one with nested scenes, one with dialogue-heavy pages, and one with notes or unusual formatting.

A format conversion also creates a fidelity boundary. Moving from Scrivener to Word to another format can preserve the words while losing annotations, labels, separators, or custom styles. Keep the source project intact and treat each converted file as a new artifact that needs inspection. The terminology around publishing and layout can also vary, so the book formatting glossary is useful when a production export and an analysis export are being confused.

When Default Formats Create Hidden Workflow Costs

“Supported” doesn't mean “equally useful.” A file can import quickly and still leave you with an expensive cleanup job. The shortcut is often measured at upload time, while the cost appears later, when scene-level reports fail and you have to reconstruct the structure manually.

Three traps account for much of the avoidable damage. The first is the Google Docs plain-text export, which preserves prose but discards the heading hierarchy. The second is a Scrivener compile using default separators that don't map to recognizable scene boundaries. The third is a Word file assembled through years of copying, pasting, tracked revisions, and local style changes.

The fifteen minutes spent checking an export is cheaper than rebuilding a novel's structure after analysis.

The damage isn't limited to aesthetics. If chapter boundaries disappear, chapter-level pacing views become meaningless. If scene breaks collapse, POV tracking can treat several narrative movements as one continuous unit. If paragraph boundaries fracture, dialogue attribution and character-state extraction can attach details to the wrong scene.

The fix is procedural. Export a dedicated analysis copy, verify headings and separators, open it in a second application, and inspect the import preview or validation log. Don't overwrite the source manuscript with the cleaned version. You're creating a stable interchange file, not declaring the original obsolete.

Troubleshooting Format-Specific Import Failures

Silent failures are the worst kind because the file appears to work. Read the import log and compare its structural counts with the manuscript before trusting any report.

Scrivener RTF becomes one stream

The signature is a chapter count that looks too low, with scene content appearing as uninterrupted prose. The cause is usually a compile configuration that outputs text without mapping binder folders or separators to structural markers.

Return to File, Compile, choose the Manuscript preset, map folders and documents to heading levels, define a consistent section separator, and compile a fresh DOCX. Reopen the output before uploading it again.

Word paragraph boundaries break

Look for dialogue or paragraphs split at strange points, often around passages with extensive tracked changes. Accept or reject revisions in a working copy, remove comments that aren't required for analysis, and save as a new DOCX. Then inspect the affected chapter rather than assuming the whole file is equally damaged.

Google Docs headings flatten

If the import log shows chapters but no subordinate scenes, the downloaded DOCX may have lost custom heading styles. In Word, select the affected titles and assign built-in Heading 1 or Heading 2 styles. Save, close, reopen, and verify the Styles pane before reimporting.

Plain text scenes merge

Mixed delimiters, inconsistent blank lines, and different line-ending conventions can cause the parser to miss boundaries. Normalize the document in a plain-text editor, replace every scene marker with one agreed pattern, and ensure paragraphs use the same spacing throughout. If a text file is rejected before parsing, this practical guide to how to fix unsupported file type offers broader file-validation steps.

PDF text is unreliable

PDF is a distribution and preservation format, not a dependable editable manuscript source. Text extraction can reorder layout elements, separate dialogue from attribution, or misread punctuation. If PDF is the only source, obtain the original DOCX, RTF, Scrivener compile, or TXT file instead. If you must extract from PDF, compare the extracted text against the visible pages and repair structural markers before analysis.

Choosing the Right Format for Each Stage of Your Manuscript

Format choice should change with the manuscript's job. During drafting, Scrivener's project structure is useful because scenes can remain modular and movable. For a serious analysis pass, compile that project into a structured DOCX or clean RTF with deliberate separators.

Mid-stage editorial work generally benefits from DOCX because editors, proofreaders, and writers can exchange a common working file. Keep tracked changes for the editorial record, but create a clean analysis copy when paragraph structure needs to be read without revision markup.

Beta feedback is different. A plain-text export can remove layout drift across devices and make comments about story content easier to compare, but it sacrifices the hierarchy needed for deep structural analysis. Use it for focused reading, not as the only canonical manuscript.

Final proofing calls for a stable, non-editing deliverable. PDF or PDF/A is appropriate for preservation and fixed-layout exchange when the exact page appearance matters. The National Archives transfer guidance treats PDF/A as an archival format and emphasizes constraints around embedded content, while the Library of Congress notes that files intended for durable access shouldn't be blocked by DRM or encryption.

For fiction workflows, the sensible model is three-tiered: a structured editable analysis copy, a vendor-neutral working or archival source, and a fixed-layout final deliverable. Novelium fits into the analysis stage by accepting common manuscript formats and using imported structure for character, timeline, and consistency work. Writers comparing broader drafting tools can also review writing software options, but the principle remains the same. Pick the format for the task, not out of habit.

Quick Reference Format Compatibility Checklist

Run this check before uploading:

• Extension: Confirm the file is .docx, .rtf, or .txt, and that it's the intended analysis copy.
• Headings: Verify chapter titles use Heading 1 and scene markers use Heading 2 where hierarchy matters.
• Separators: Confirm every scene uses the same delimiter or style.
• Paragraphs: Remove accidental blank paragraphs, tabs, and pasted layout artifacts.
• Revisions: Accept or reject tracked changes in a clean copy if revision markup isn't part of the analysis.
• Metadata: Check that any author notes or scene labels you need survived compilation.
• Encoding: Open the exported file in a second editor and inspect quotation marks, apostrophes, and nonstandard characters.
• Validation: Compare the imported chapter and scene structure with the source before acting on analysis results.

Novelium's Character Tracker and World Codex are designed for the problem that static character profiles never solve: tracking changing knowledge, relationships, traits, objects, and events across scenes. Prepare a structurally honest manuscript, import it into Novelium, and use the resulting analysis to catch continuity failures before they reach the next draft or the printer.