ODT File Documentation

Summary

An ODT (OpenDocument Text) file is a word-processing document stored as a ZIP package of XML parts, standardised by OASIS and published as ISO/IEC 26300. It is the native format of LibreOffice Writer and Apache OpenOffice, and the text counterpart of the ODS spreadsheet. Its MIME type is application/vnd.oasis.opendocument.text. Microsoft Word has opened and saved .odt since Word 2007, so the common questions are about how it is built inside and how faithfully it round-trips to DOCX.

Technical details

FeatureValue
Full nameOpenDocument Text
File extension.odt
MIME typeapplication/vnd.oasis.opendocument.text
Format typeZIP package of XML parts
Container / baseZIP archive; content described in XML
DeveloperOASIS (originated in the StarOffice / OpenOffice.org XML format at Sun Microsystems)
Introduced2005 (ODF 1.0)
StandardISO/IEC 26300 (2006); OASIS ODF 1.3 (2021)
Open standardYes — vendor-neutral, royalty-free
Text encodingUTF-8
Magic number (hex)50 4B 03 04 (ZIP local file header, “PK”)
First archive entrymimetype, stored uncompressed, at offset 30
Main body partcontent.xml
Formatting partstyles.xml
Package manifestMETA-INF/manifest.xml
Root XML element<office:document-content>
Native supportLibreOffice Writer, Apache OpenOffice Writer, Collabora Office
Microsoft Word supportRead/write since Word 2007; ODF 1.3 in Microsoft 365
Template variant.ott (template); .fodt (flat single-XML)
EncryptionOptional AES password protection, recorded in the manifest
Related extensions.ott, .fodt, .ods, .odp, .docx, .rtf
Specificationdocs.oasis-open.org/office/
File signature (magic bytes)
50 4B 03 04

Offset 0, 4 bytes: the ZIP local file header, ASCII PK\x03\x04, because an ODT is a ZIP archive. What makes it an ODT rather than a plain ZIP is the first entry: a file named mimetype, stored uncompressed and with no extra field, so the ASCII string mimetype appears at offset 30 and its contents, application/vnd.oasis.opendocument.text, are readable in the clear starting near offset 38. That fixed placement lets a system identify the exact ODF type from the raw bytes without unzipping.

What is an ODT file?

ODT is the word-processing member of the OpenDocument Format (ODF) family. OASIS approved ODF 1.0 in 2005, and the format became the international standard ISO/IEC 26300 in 2006 — the first fully open, XML-based office document standard, created so documents would not be tied to one vendor’s software. The current major version is ODF 1.3 (OASIS, 2021). ODT grew out of the StarOffice and OpenOffice.org XML format developed at Sun Microsystems, and today it is the native format of LibreOffice Writer, Apache OpenOffice Writer and Collabora Office. Several governments recommend or require ODF for public documents.

A single .odt is not one file but a small archive of several. It is a ZIP package whose entries are mostly XML: one part holds the text, another the styles, another the metadata, plus a manifest and any embedded images. Because it is a ZIP, you can rename a copy to .zip, extract it, and read every part with a plain text editor. The sections below walk through that package and the XML inside it.

The ODF package: mimetype, parts and the manifest

An ODT is a ZIP archive laid out to a strict recipe. A minimal document contains these entries:

mimetype                    first entry, STORED (uncompressed)
content.xml                 the document body: text, tables, fields
styles.xml                  paragraph/character styles, page layout, headers/footers
meta.xml                    author, title, edit time, statistics
settings.xml                view state: zoom, cursor position, window
META-INF/manifest.xml       inventory of every part + encryption info
Thumbnails/thumbnail.png    preview of the first page
Pictures/                   embedded images

Two rules make ODF identifiable and robust. First, the mimetype entry must be the very first member of the ZIP and must be stored uncompressed with no extra field. That forces its contents, the literal string application/vnd.oasis.opendocument.text, to sit at a fixed byte position (near offset 38) so a file-type detector can read the exact ODF flavour without decompressing anything. Second, every part in the package is listed in META-INF/manifest.xml. A reader consults the manifest first to learn what parts exist, their media types, and whether any are encrypted; nothing in the package is trusted to exist by name alone.

content.xml: the document tree

The visible document lives in content.xml. Its root element is <office:document-content>, and the running text sits under <office:body> → <office:text>. Paragraphs, headings, lists and tables are child elements in document order:

<?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">
  <office:body>
    <office:text>
      <text:h text:style-name="Heading_20_1" text:outline-level="1">Report</text:h>
      <text:p text:style-name="Standard">This is a paragraph.</text:p>
      <text:list text:style-name="L1">
        <text:list-item><text:p>First item</text:p></text:list-item>
      </text:list>
    </office:text>
  </office:body>
</office:document-content>

A heading is <text:h> with an outline-level; a paragraph is <text:p>. Notice that neither carries direct formatting like “bold, 12pt” inline. Instead each element names a style through text:style-name (here Heading_20_1 and Standard). Everything visual is delegated to the style system, which is what keeps the body markup clean and makes global reformatting a matter of changing one style rather than every paragraph.

The XML uses many namespaces, each with a defined prefix: text: for content, table: for tables, draw: for graphics and frames, style: for style definitions. A table becomes <table:table> with <table:table-row> and <table:table-cell> children; an inline image is a <draw:frame> wrapping a <draw:image> whose xlink:href points into the Pictures/ folder.

Styles: named styles versus automatic styles

ODF splits formatting into two layers. Named styles — the ones a user picks from a list, such as “Heading 1” or “Standard” — are defined in styles.xml under <office:styles>. Direct formatting that a user applies ad hoc (select a word, make it italic) is captured as an automatic style: a machine-generated style, named something like T1 or P2, stored in the <office:automatic-styles> block. Automatic styles for the body sit inside content.xml; those for page layout sit in styles.xml.

<style:style style:name="T1" style:family="text">
  <style:text-properties fo:font-weight="bold"/>
</style:style>
...
<text:p>Some <text:span text:style-name="T1">bold</text:span> text.</text:p>

Page geometry, headers and footers are described by a <style:page-layout> plus a <style:master-page> in styles.xml. Formatting properties themselves reuse XSL-FO attribute names in the fo: namespace — fo:font-weight, fo:margin-left, fo:text-align — which is why anyone who knows CSS or XSL-FO can read ODF style markup almost immediately.

meta.xml and package encryption

meta.xml carries the document’s Dublin Core and ODF metadata: title, author (meta:initial-creator and dc:creator), creation and modification timestamps, the total editing time, and statistics such as page, word and character counts under <meta:document-statistic>. Editors update these automatically as you work, which is why an ODT can silently reveal an author name or edit history unless the metadata is cleared before sharing.

Password protection in ODF operates at the package level. When a document is encrypted, the individual XML parts are compressed and then encrypted (ODF 1.2 and later default to AES-256), and the details — algorithm, key-derivation parameters, salt and checksum — are recorded per part inside META-INF/manifest.xml. The mimetype entry itself stays in the clear so the file remains identifiable. A digital signature, when present, is stored as an additional part and covers the other parts, letting a recipient confirm the document was not altered after signing.

Interoperability with DOCX, part by part

ODT and DOCX are cousins: both are ZIP packages of XML. The difference is the schema. ODT follows the OASIS OpenDocument grammar (the text:/style:/table: namespaces above); DOCX follows ECMA-376 / ISO/IEC 29500 Office Open XML, where the body lives in word/document.xml using the w: namespace and formatting is expressed as run properties (<w:rPr>) rather than named ODF styles. Converting between them is a schema translation, not a repackaging.

Ordinary text, headings, lists, tables and images map cleanly in both directions, which is why LibreOffice, Word (since Word 2007) and Google Docs all round-trip everyday documents well. The mismatches show up at the edges: some field types, complex numbered-list definitions, tracked-change edge cases, embedded macros and intricate page layout have no exact counterpart in the other schema and get approximated or dropped. That gap, not any defect in either format, is the real reason behind most “odt to docx” searches. For a batch conversion, LibreOffice’s headless mode does it without the GUI: soffice --headless --convert-to docx *.odt.

Frequently asked questions

Why must the mimetype entry be first and uncompressed?

So the format is identifiable from the raw bytes. Because ODF requires mimetype to be the first ZIP member and stored without compression, its contents land at a fixed offset near byte 38. A file-type detector reads the MIME string there and knows it is an OpenDocument Text without extracting or even fully parsing the archive.

Can I really open an ODT with a ZIP tool?

Yes. An ODT is a standard ZIP archive. Rename a copy to .zip and extract it, and you will see content.xml, styles.xml, meta.xml, the manifest and any embedded pictures. This is a good way to inspect or repair a document, or to pull an image out of it, without a word processor.

What actually differs between ODT and DOCX inside the file?

Both are ZIP+XML, but the XML grammar differs. ODT uses the OASIS OpenDocument schema with named styles and the text: namespace; DOCX uses ISO/IEC 29500 Office Open XML with run properties and the w: namespace, and its body is word/document.xml. Converting between them translates one schema to the other, so features without a direct equivalent can shift.

References