ODT OpenDocument Text: The Complete Format Guide

What Is ODT?

ODT (OpenDocument Text) is the word processing format of the ODF (OpenDocument Format) standard, an ISO/IEC standardized format (ISO/IEC 26300) for office documents. ODT is the native format of LibreOffice Writer, Apache OpenOffice Writer, and Google Docs (when exported as ODF). It was developed by OASIS (Organization for the Advancement of Structured Information Standards) as an open, vendor-neutral alternative to Microsoft's proprietary formats.

ODT files are ZIP archives containing multiple XML files and resources. Unlike RTF (plain text) or DOC (binary), ODT separates content, formatting, metadata, and settings into distinct XML files — making it both machine-readable and human-inspectable by unzipping the file.

The ODF family includes:

• ODT — OpenDocument Text (word processing)
• ODS — OpenDocument Spreadsheet (spreadsheets)
• ODP — OpenDocument Presentation (presentations)
• ODG — OpenDocument Graphics (vector drawing)
• ODF — OpenDocument Formula (mathematical formulas)

ODT Package Structure

An ODT file is a ZIP archive. Renaming document.odt to document.zip and extracting reveals:

document.odt/
├── mimetype                    ← "application/vnd.oasis.opendocument.text" (uncompressed, first entry)
├── META-INF/
│   └── manifest.xml            ← package manifest listing all files
├── content.xml                 ← document content + automatic styles
├── styles.xml                  ← named styles + page layouts
├── meta.xml                    ← document properties (author, title, statistics)
├── settings.xml                ← application settings (view, cursor position)
└── Thumbnails/
    └── thumbnail.png           ← preview image

Important: The mimetype file must be the first entry in the ZIP and must be stored uncompressed (no deflate). This allows MIME-type sniffing by reading the first bytes of the file without decompressing it:

bytes 38-77: application/vnd.oasis.opendocument.text

content.xml Structure

The document content lives in content.xml, following the ODF XML namespace:

<?xml version="1.0" encoding="UTF-8"?>
<office:document-content
    xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0"
    xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0"
    xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0"
    xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0">

  <office:automatic-styles>
    <!-- Automatic (unnamed, direct) styles applied in content -->
    <style:style style:name="P1" style:family="paragraph">
      <style:text-properties fo:font-weight="bold" fo:font-size="14pt"/>
    </style:style>
  </office:automatic-styles>

  <office:body>
    <office:text>
      <text:p text:style-name="Heading1">Introduction</text:p>
      <text:p text:style-name="P1">This paragraph uses direct bold 14pt formatting.</text:p>
      <text:p text:style-name="Text Body">Normal body text paragraph.</text:p>
    </office:text>
  </office:body>
</office:document-content>

Key ODF XML Elements

Styles vs Direct Formatting

ODT has a dual formatting model:

Named Styles (in styles.xml)

Paragraph styles (Text Body, Heading 1, List Paragraph), character styles (Strong Emphasis, Quotations), and page layouts are defined in styles.xml and referenced by name. This is the recommended approach — changing a style updates all paragraphs using it.

<!-- In styles.xml -->
<style:style style:name="Heading1" style:family="paragraph"
             style:parent-style-name="Standard">
  <style:text-properties fo:font-size="18pt" fo:font-weight="bold"
                         fo:color="#1f3864"/>
  <style:paragraph-properties fo:space-before="12pt" fo:space-after="6pt"/>
</style:style>

Automatic Styles (in content.xml)

"Automatic" styles are unnamed styles generated by direct formatting — when you make a paragraph bold without creating a named style. These appear in <office:automatic-styles> in content.xml with generated names like P1, P2, T1. This is the source of "style soup" in complex documents.

Embedded Images and Objects

Images in ODT are stored in a Pictures/ directory inside the ZIP:

<!-- In content.xml -->
<draw:image draw:name="image1"
            xlink:href="Pictures/10000000000001E000000160ABCD1234.png"
            xlink:type="simple"
            xlink:show="embed"
            xlink:actuate="onLoad"/>

The image is the actual PNG/JPEG file stored in the ZIP archive. This is cleaner than RTF's hex encoding — images in ODT are stored at full quality without encoding overhead.

Embedded OLE objects (charts, spreadsheets) are stored in Object 1/, Object 2/ subdirectories, each containing their own ODF sub-document with content.xml.

Metadata in meta.xml

<office:meta>
  <dc:title>My Document</dc:title>
  <dc:creator>Jane Smith</dc:creator>
  <dc:date>2025-03-15T10:30:00</dc:date>
  <meta:creation-date>2024-01-01T09:00:00</meta:creation-date>
  <meta:editing-duration>PT2H30M</meta:editing-duration>
  <meta:document-statistic meta:word-count="1250" meta:paragraph-count="45"
                           meta:page-count="5" meta:character-count="7500"/>
</office:meta>

ODT Compatibility

LibreOffice Writer

Native format — full fidelity, including all styles, macros (Basic/Python), forms, and extension-specific features.

Google Docs

• Import: Good — most formatting, styles, images, and tables import correctly
• Export: File → Download → OpenDocument Format (.odt)
• Limitations: Complex multi-column layouts, certain table styles, and Basic macros don't round-trip perfectly

Microsoft Word

Word has supported ODT since Word 2007 (via compatibility pack) and natively since Word 2013:

• Word 2013+: Opens ODT directly; conversion is reasonable but not perfect
• Known losses: Custom paragraph styles, certain list styles, section formatting nuances

Word cannot save changes within ODT's native feature set — it converts to its internal model and back, so some features degrade.

Apple Pages

Pages can import ODT files but conversion quality is mediocre for complex documents. Export to ODT is available but limited.

Converting ODT Files

Pandoc

# ODT to DOCX
pandoc input.odt -o output.docx

# ODT to PDF
pandoc input.odt -o output.pdf

# ODT to Markdown
pandoc input.odt -t markdown -o output.md

# ODT to HTML
pandoc input.odt -t html -s -o output.html  # -s for standalone with CSS

# DOCX to ODT
pandoc input.docx -o output.odt

LibreOffice headless

# ODT to PDF (best quality)
soffice --headless --convert-to pdf input.odt

# ODT to DOCX
soffice --headless --convert-to docx input.odt

# Batch convert all ODT in directory
soffice --headless --convert-to pdf *.odt --outdir /output/

Python (odfpy)

from odf.opendocument import load
from odf.text import P

# Load and inspect ODT
doc = load('document.odt')

# Extract all paragraph text
for para in doc.text.getElementsByType(P):
    print(para.plaintext())

# Create a new ODT document
from odf.opendocument import OpenDocumentText
from odf.style import Style, TextProperties
from odf.text import P

newdoc = OpenDocumentText()
para = P(text="Hello, OpenDocument!")
newdoc.text.addElement(para)
newdoc.save("new_document.odt")

Inspect ODT directly (it's just a ZIP)

# List files in ODT
unzip -l document.odt

# Extract and view content.xml
unzip -p document.odt content.xml | xmllint --format -

# Extract embedded images
unzip document.odt "Pictures/*" -d ./extracted_images/

ODT vs DOCX: Which to Choose?

The pragmatic choice: If you or your recipients primarily use Microsoft Word, DOCX is safer. If you primarily use LibreOffice or work in environments that mandate open standards (EU public sector, academia), ODT is the right choice. Both are ISO-standardized, both are solid long-term archival formats.

ODT's status as an ISO/IEC standard — unlike the proprietary DOC format it replaced — ensures it will remain readable by open-source tools indefinitely, making it the gold standard for document archival without vendor lock-in.

Related conversions

Document conversions that follow this topic naturally:

• PDF to DOCX
• DOCX to PDF
• MD to PDF
• HTML to PDF
• ODT to PDF
• PDF to TXT