Convert DOCX to ODT: Move a Word Document Into OpenDocument Text

The practical feature mapping between WordprocessingML and ODT, including the Word functions Microsoft says will change, flatten, or disappear.

  1. Add a file Choose or drop it here
  2. Pick the format Change it whenever needed
  3. Download the result After conversion completes

DOCX and ODT are both office packages, but they model a document differently

DOCX is a WordprocessingML package under the Office Open XML family. Microsoft describes it as a package of parts linked by relationships, with a main document part containing a body, paragraphs, runs, and text ranges. ODT is an OpenDocument Text package. OASIS OpenDocument 1.3 requires a ZIP package with a META-INF/manifest.xml manifest, and its schema identifies content.xml and styles.xml as distinct document content and style files. Both formats can hold editable text, styles, tables, pictures, headers, and document metadata, but their markup vocabularies and feature rules are not interchangeable.

A real DOCX-to-ODT conversion reads the Word package and writes a new ODF package. Renaming the extension leaves the original WordprocessingML parts and relationships untouched, so it does not make an ODT file. The target is useful when the next editor uses LibreOffice Writer, Apache OpenOffice Writer, or another ODF-first workflow. Microsoft Word can also open and save ODT, but Microsoft explicitly warns that formatting can change because Word and OpenDocument applications support different features. Save the DOCX master before conversion; the ODT is a separate editable document with its own compatibility boundary.


What the converter maps from WordprocessingML into ODF text and styles

At the basic level, DOCX paragraphs and runs map naturally to ODF paragraphs and text content. ODF has elements for headings, paragraphs, lists, sections, fields, tables, images, and tracked changes, so a text-first Word document can become an editable ODT rather than a page image. The difficult conversion work is not the text itself; it is translating Word’s style inheritance, document controls, drawing objects, field behavior, section layout, comments, and revision semantics into features that an ODF consumer understands. A page that looks identical at first may behave differently when new text is inserted, a table is expanded, or a new heading is added.

Microsoft’s compatibility table supplies specific limits. Word comments are only partly supported in ODT: a table inside a comment loses its table structure even though its contents remain. Word Track Changes are not supported when saving as ODT; Microsoft says all changes are accepted. Document protection, Information Rights Management, and encryption are not supported. Mail-merge ADDRESSBLOCK and RECIPIENT fields become plain text, and the source-data connection must be established again if another ODF application edits the file. These are not cosmetic differences. They determine whether the ODT is safe for an active review, protected workflow, or automated document process.


Practical advantages and documented feature costs of the ODT copy

  • ODF-native editing: the converted document can be maintained in an OpenDocument Text workflow with editable paragraphs and styles.
  • Open package structure: ODF stores content and styles as XML package parts with a required manifest.
  • Strong basic text overlap: standard paragraphs, lists, headers, footers, page numbering, pictures, and ordinary shapes have support paths.
  • Accepted revisions: Word Track Changes are not supported in ODT save, so all changes are accepted rather than retained as Word review history.
  • Lost protection features: document protection, IRM, and encryption are removed or unsupported in the ODT target.
  • Simplified advanced structure: captions, bibliography, some fields, nested text-box content, complex tables, and section properties have named limits.

This makes ODT a good working target for documents whose content will be edited in an ODF-based environment, not a safe substitute for every Word workflow. A plain report can be converted, reviewed, and maintained successfully. A contract under protection, a document with unresolved redlines, or a mail-merge template must preserve its DOCX master and may need a separate final PDF for sharing. Decide whether the task is “edit this text in an ODF editor” or “preserve every Word behavior.” Only the first goal is a sound reason to make ODT the continuing working file.


Microsoft Word, LibreOffice, and OpenOffice should each be used for a different check

Microsoft’s current support instructions cover Word for Microsoft 365, Word 2024, 2021, 2019, and 2016 and describe saving through Save As or Save a Copy with OpenDocument Text chosen as the target. Microsoft also recommends closing and reopening the file to see its ODT appearance. LibreOffice Writer and Apache OpenOffice Writer are the practical ODF-native editors in which to test the delivered file. The first check is whether the ODT opens and edits correctly in the intended ODF editor. The second is whether the original DOCX still exists and opens in Word, because Microsoft advises saving a Word version before saving the ODT copy.

Font and layout differences are separate from container recognition. A receiving program may substitute a font, alter line height, or calculate a table differently. Microsoft marks tables as partly supported: tables with more than 64 columns are unsupported, and theme formatting is converted to cell-level formatting. Continuous section breaks can lose top or bottom margins, headers or footers, borders, and line numbering. Check the first and last pages of every section, all table-heavy pages, and any page with a tight footer. A file that opens without an error may still require layout repair before it is suitable for distribution.

Reference-heavy documents need another check. Microsoft lists bibliography sections as unsupported and converts them to plain text. It marks a table of contents partly supported because items labeled with a SEQ field are lost. Check every generated list, bibliography, caption list, and cross-reference after opening the ODT. Rebuild those tools in the target editor after the text and heading structure are stable; otherwise later edits can leave a convincing-looking but outdated list of figures or sources.


Failures with clear causes: accepted redlines, lost controls, flattened fields, and misplaced objects

If a DOCX’s redlines vanish in the ODT, the conversion has followed Microsoft’s documented behavior: saving Word Track Changes to ODT accepts all changes. Do not use ODT as the first conversion target for a review record. Preserve the original DOCX with its revisions, make an agreed final version with changes accepted if appropriate, and then convert that final text. If a protected document can no longer be protected in the same way, the reason is also documented: document protection, IRM, and ODT encryption support do not map from Word’s corresponding features. Use the approved security system outside the file or keep the protected DOCX workflow.

If a caption stops auto-numbering, Microsoft says SEQ fields are converted to plain text and new captions will not automatically increment. Recreate the numbering scheme in the target editor rather than typing a series of fixed numbers. If an object disappears from a text box, inspect nesting: SmartArt, shapes, or text boxes inside a text box are not supported and can be lost. Move important objects out of nested boxes before conversion, or replace a complex graphic with a prepared image when editability is not needed. Word SmartArt itself is converted to a group of shapes, so it may remain visible but not retain its original SmartArt editing model.

If a table, header, or section layout drifts, identify which source feature controls it. Rebuild continuous sections with explicit ODT page styles and verify each header/footer; simplify a table over 64 columns before conversion; replace theme-driven table formatting with explicit cell formatting only after the master is saved. These are targeted repairs based on published feature limits, not random attempts to save the file repeatedly in different extensions.


A DOCX-to-ODT compatibility table that identifies real review priorities

Word featureMicrosoft-documented ODT resultWhat to do
Track ChangesNot supported; all changes acceptedKeep the DOCX review record first.
Comments containing tablesContents kept, table structure lostMove important review tables into body text.
Document protection, IRM, encryptionNot supportedKeep protected workflow outside this ODT copy.
SEQ captionsConverted to plain textRebuild auto-numbering in the target editor.
Tables over 64 columnsNot supportedSplit or redesign before conversion.
Nested text-box objectsSome content is not supported and can be lostMove objects outside the text box.

Questions before Word content becomes an OpenDocument working file

Can DOCX be renamed to ODT?
No. DOCX uses an OOXML package and ODT requires an ODF ZIP package with its own XML parts and manifest.

Will Track Changes be preserved?
No. Microsoft says ODT save does not support Word Track Changes and accepts all changes. Keep the DOCX review version.

Why did my caption number stop updating?
Word SEQ fields become plain text in ODT. Recreate automatic numbering after conversion if it is required.

Why did a text-box object vanish?
Objects nested inside text boxes have documented ODT limits. Move critical objects to normal document content before converting.

Should the DOCX be deleted after making ODT?
No. Microsoft recommends retaining a Word version. Keep it as the master until the ODT has been opened and reviewed in its intended editor.