ODP File Documentation

Summary

An OpenDocument Presentation (.odp) is the native slide-deck format of LibreOffice Impress and Apache OpenOffice Impress, the vendor-neutral counterpart to PowerPoint’s .pptx. It is a ZIP package of XML files defined by the OpenDocument standard (ISO/IEC 26300), with the MIME type application/vnd.oasis.opendocument.presentation. Open it free in LibreOffice Impress, upload it to Google Slides, or open it in PowerPoint 2007 SP2 and later.

Technical details

FeatureValue
Full nameOpenDocument Presentation
File extension.odp
MIME typeapplication/vnd.oasis.opendocument.presentation
Format typePresentation document; ZIP package of XML parts
Container / base formatZIP archive (OpenDocument package)
DeveloperOASIS (originated at Sun Microsystems / OpenOffice.org)
Introduced2005 (ODF 1.0, OASIS)
StandardISO/IEC 26300 (2006); OASIS ODF 1.3 (2021)
Open standardYes — royalty-free OASIS / ISO standard
Byte orderZIP structures little-endian; XML is UTF-8 text
Magic number (hex)50 4B 03 04 (ZIP local file header)
Type identifiermimetype entry at offset 30, MIME string at offset 38
Main slide partcontent.xml (uses draw:page elements)
Styles partstyles.xml (master slides, layouts)
Package manifestMETA-INF/manifest.xml
Native applicationLibreOffice Impress; Apache OpenOffice Impress
PowerPoint supportRead/write since PowerPoint 2007 SP2 (2009); ODF 1.3 in Microsoft 365
Related extensions.otp, .fodp, .odt, .ods, .odg, .pptx
Specificationdocs.oasis-open.org/office/OpenDocument/v1.3/
File signature (magic bytes)
50 4B 03 04

Offset 0, 4 bytes, ASCII PK\x03\x04: the standard ZIP local file header, because an ODP is a ZIP archive. What tells an ODP apart from an ordinary ZIP is the first entry. The OpenDocument package rule requires the first archive member to be a file named mimetype, stored uncompressed (STORED, not DEFLATE) and with no extra field, so the literal string mimetype sits at offset 30 and its content application/vnd.oasis.opendocument.presentation begins at offset 38. A Unix file/magic check reads those bytes to identify the deck without trusting the extension.

What is an ODP file?

ODP stands for OpenDocument Presentation. It is the slide-deck member of the OpenDocument Format (ODF), the vendor-neutral office-document standard ratified by OASIS in 2005 and published as ISO/IEC 26300 in 2006. The current major revision is ODF 1.3 (OASIS, 2021). The format grew out of the XML file format developed for StarOffice and OpenOffice.org at Sun Microsystems, and it is today the native save format of LibreOffice Impress and the older Apache OpenOffice Impress. Its MIME type is application/vnd.oasis.opendocument.presentation.

An .odp is not a single monolithic binary. It is a ZIP archive whose members are XML documents plus any embedded media. The slides, their text and shapes live in one XML file; the master slides and formatting live in another; a manifest lists everything in the package. It is the presentation counterpart to ODT (text) and ODS (spreadsheet), which use the same packaging with a different MIME type and a different root XML element. Everything below describes how that package is put together, entry by entry.

The ODF package: a ZIP with rules

Open an .odp with any unzip tool and you see a small file tree. ODF reuses the ordinary ZIP container (magic bytes 50 4B 03 04 at offset 0), so any archiver can list the parts, but ODF adds constraints that a plain ZIP does not have.

presentation.odp  (ZIP)
 ├─ mimetype                first entry, STORED (uncompressed), no extra field
 ├─ content.xml             the slides: text, shapes, layout, animation
 ├─ styles.xml              master slides, slide layouts, fonts, formatting
 ├─ meta.xml                document metadata (author, dates, statistics)
 ├─ settings.xml            view/app settings (zoom, active slide)
 ├─ META-INF/
 │   └─ manifest.xml        inventory of every part + its media type
 ├─ Pictures/              embedded images and media
 └─ Thumbnails/
     └─ thumbnail.png       preview shown by file managers

The separation is deliberate: content, presentation (styling) and metadata are three different XML streams, so an application can rewrite formatting without touching the slide content, or read the metadata without parsing the whole deck. All XML in the package is UTF-8. The ZIP structures themselves store their integers little-endian, the normal ZIP convention.

The mimetype entry: how a package identifies itself

The single most important rule in the OpenDocument package format concerns the first ZIP entry. Part 3 of the specification requires that if a mimetype file is present it shall be the first entry in the archive, it shall be stored uncompressed (ZIP STORED method, not DEFLATE), and its local header shall not use an extra field. Its content is the exact MIME type string with no trailing newline.

Offset 0   : 50 4B 03 04            PK\x03\x04  local file header
Offset 26  : 08 00                  file-name length = 8  ("mimetype")
Offset 30  : 6D 69 6D 65 74 79 70 65  "mimetype"
Offset 38  : 61 70 70 6C 69 63 61 ...  "application/vnd.oasis.opendocument.presentation"

Because the entry is uncompressed and free of an extra field, those three fixed lengths line up every time: the name mimetype lands at offset 30 and the type string at offset 38. That is what lets a Unix file/magic rule, or any content sniffer, read a fixed byte window near the start of the archive and report “this is an OpenDocument presentation” without trusting the .odp extension. Change presentation to text or spreadsheet in that string and the same package rule identifies an ODT or ODS instead. A ZIP that lacks this entry, or compresses it, is a plain ZIP and not a conformant ODF package.

content.xml: draw:page and the slide tree

The slides themselves are XML in content.xml. Presentations use the drawing namespace (draw:) layered with a presentation namespace (presentation:). The document body holds a <office:presentation> element, and inside it each slide is a single <draw:page>.

<office:body>
 <office:presentation>
  <draw:page draw:name="Slide 1"
             draw:style-name="dp1"
             draw:master-page-name="Default">
    <draw:frame presentation:class="title" ...>
       <draw:text-box><text:p>My title</text:p></draw:text-box>
    </draw:frame>
    <draw:frame presentation:class="outline" ...> ... </draw:frame>
    <presentation:notes> ... speaker notes ... </presentation:notes>
  </draw:page>
  <draw:page draw:name="Slide 2" ...> ... </draw:page>
 </office:presentation>
</office:body>

Each draw:page names the master page it is built on (draw:master-page-name) and the automatic style that controls its transition and background (draw:style-name). Content on the slide is a set of draw:frame elements; the presentation:class attribute (title, outline, subtitle, notes) marks each frame’s role in the layout. Text inside a frame is ordinary ODF text markup: text:p paragraphs and text:span runs, the same elements an ODT uses. Because slides are just elements in a list, reordering a deck is moving draw:page nodes.

styles.xml: master slides, layouts and automatic styles

Formatting is split from content. styles.xml holds the named styles, the page layouts, and the master pages. A master page in ODF is what a presenter thinks of as a slide master: a background, placeholder positions, and any repeated furniture such as a logo or page number. A draw:page in content.xml references a master by name, and the master supplies everything the individual slide does not override.

ODF distinguishes two style groups. Named styles in styles.xml are the ones a user picks from a list. Automatic styles are machine-generated, one per unique combination of direct formatting; presentation automatic styles often live in content.xml next to the slides that use them. This two-tier scheme keeps the slide markup compact: a frame carries a short style-name reference rather than a full run of formatting attributes.

manifest.xml and embedded media

The META-INF/manifest.xml file is the package’s own table of contents. It lists every entry with its full path and media type, including the root document and each file under Pictures/. A reader consults the manifest to learn what is inside without walking the raw ZIP directory, and the manifest is also where an encrypted ODF package records its per-entry encryption parameters. Embedded images sit under Pictures/ and are referenced from a draw:image element by a relative path, so the picture bytes are stored once and the slide points at them.

ODP and PPTX: two ZIP+XML presentation formats

Both ODP and PPTX are ZIP archives full of XML, but they are different schemas. PPTX is Microsoft’s Office Open XML (ECMA-376 / ISO/IEC 29500) and stores one XML part per slide under ppt/slides/slide1.xml, wired together by relationship files. ODP keeps all slides in a single content.xml and uses the draw:/presentation: vocabulary. The two describe transitions, animations and effects with different elements, which is why a complex deck can shift slightly when converted between them even though text and basic layout round-trip cleanly. PowerPoint has read and written ODP since PowerPoint 2007 SP2 (2009), and Microsoft 365 targets ODF 1.3, so the conversion is built in rather than an add-on.

Frequently asked questions

Why must the mimetype file be first and uncompressed?

So a content sniffer can identify the package from a fixed byte range. Because the first entry is mimetype, stored (not DEFLATE-compressed) and without an extra field, the ZIP header lengths are constant, and the MIME string always begins at offset 38. That lets tools tell an ODP from an ODS, ODT or a plain ZIP by reading a few bytes, independent of the file name.

Can I unzip an .odp to get the images out?

Yes. Rename a copy to .zip (or point any archiver at it) and extract. The Pictures/ folder holds the embedded images in their original encoding, and content.xml is the slide text as XML. This is a reliable way to recover a picture or read the raw text from a deck you cannot otherwise open.

Are ODP macros a risk?

An ODP can carry embedded Basic macros. LibreOffice and PowerPoint block or prompt on macros by default, so an unexpected deck is safe to open with macros disabled. Do not enable macros in a presentation you were not expecting, and treat hyperlinks in an unfamiliar deck with the same caution as any link.

References