PPTX File Documentation

Summary

A PowerPoint Open XML Presentation is Microsoft PowerPoint’s slide-deck format, used by default since PowerPoint 2007. A .pptx file is not a single document but a ZIP archive of XML parts: one XML file per slide plus layouts, masters, themes and embedded media. It is standardised as ISO/IEC 29500 (Office Open XML), and its MIME type is application/vnd.openxmlformats-officedocument.presentationml.presentation. Because it is ZIP-based, you can rename a copy to .zip and extract the images inside.

Technical details

FeatureValue
Full nameMicrosoft PowerPoint Open XML Presentation
File extension.pptx
MIME typeapplication/vnd.openxmlformats-officedocument.presentationml.presentation
Format typeOffice Open XML package (zipped XML parts)
Container / base formatZIP, following the Open Packaging Conventions (OPC)
DeveloperMicrosoft
Introduced2007 (PowerPoint 2007)
StandardISO/IEC 29500 (2008); ECMA-376
Open standardPartial — OOXML is ISO-standardised, but PowerPoint adds app-specific features
Byte orderLittle-endian (ZIP structures)
Magic number (hex)50 4B 03 04 (ASCII PK, ZIP local file header)
Text encodingUTF-8 XML
Manifest part[Content_Types].xml
Main partppt/presentation.xml
Per-slide partsppt/slides/slideN.xml
Embedded mediappt/media/ (images, audio, video)
Font embeddingSupported (fonts stored as parts)
Vector graphicsDrawingML shapes and paths
EncryptionSupported (AES via the ECMA-376 agile encryption wrapper)
Macro-enabled variant.pptm (plain .pptx cannot carry VBA)
Related extensions.ppt, .ppsx, .pptm, .potx, .odp, .key
Specificationlearn.microsoft.com/openspecs/office_standards/ms-pptx/
File signature (magic bytes)
50 4B 03 04

Offset 0, 4 bytes, ASCII PK — the standard ZIP local file header (the initials of ZIP’s author, Phil Katz). A PPTX is an Open Packaging Conventions ZIP, so it begins exactly like a plain .zip, a DOCX or an XLSX. What identifies it as a presentation is the internal layout, not the header: a [Content_Types].xml manifest plus a ppt/presentation.xml part and a ppt/slides/ folder. This is unlike the older binary .ppt, which is an OLE2 compound file starting with D0 CF 11 E0 A1 B1 1A E1.

What is a PPTX file?

PPTX is the file format of a PowerPoint Open XML Presentation, the default way Microsoft PowerPoint has saved slide decks since PowerPoint 2007. It is part of Office Open XML (OOXML), the same family that gives Word its DOCX and Excel its XLSX. OOXML was published by Ecma International as ECMA-376 in 2006 and ratified as the international standard ISO/IEC 29500 in 2008. PPTX replaced the older binary .ppt format, which stored a presentation as an opaque OLE2 compound file.

The single most important technical fact about a .pptx is that it is not one file: it is a ZIP archive holding dozens of separate parts. The coded content of the deck lives in XML text files, the pictures and videos live as ordinary image and media files inside the archive, and a set of manifest and relationship files tie them together. Because the container is a plain ZIP and the parts are documented XML, any program can read a PPTX accurately without reverse-engineering a proprietary binary blob. The sections below describe that package structure part by part.

The OPC package: a ZIP with rules

A PPTX follows the Open Packaging Conventions (OPC), defined in Part 2 of ISO/IEC 29500. OPC is a thin set of rules layered on top of an ordinary ZIP archive, so a PPTX begins with the ZIP local file header 50 4B 03 04 (PK) and can be opened by any ZIP tool. Renaming a copy to .zip and extracting it reveals the whole tree; the images and videos in ppt/media/ come out as normal files.

OPC calls each file inside the archive a part, and each part has a name that looks like an absolute path (for example /ppt/slides/slide1.xml). Two kinds of housekeeping part make the package self-describing:

/                          (ZIP root)
├─ [Content_Types].xml     content-type map for every part in the package
├─ _rels/.rels             package-level relationships (points to the start part)
├─ docProps/
│   ├─ core.xml            title, author, created/modified timestamps
│   └─ app.xml             app name, slide count, titles of slides
└─ ppt/
    ├─ presentation.xml    the deck: slide list, slide size, defaults
    ├─ _rels/presentation.xml.rels   maps r:id values to slide/master parts
    ├─ slides/slide1.xml   one part per slide
    ├─ slideLayouts/       layout parts
    ├─ slideMasters/       master parts
    ├─ theme/theme1.xml    colours, fonts, effect styles
    ├─ notesSlides/        speaker notes
    └─ media/image1.png    embedded pictures, audio and video

The [Content_Types].xml part is mandatory and must be readable before anything else, because it declares the MIME content type of every part in the package. It does this two ways: a default rule maps a file extension to a type (for example png to image/png), and an override rule pins one specific part name to a type. A reader consults this map to know that ppt/slides/slide1.xml is a slide part rather than, say, a theme, without guessing from the name.

Relationships: how parts reference each other

OOXML parts never point at each other by hard-coded path. Instead every reference goes through a relationship, and this indirection is what lets PowerPoint rename or rearrange parts without breaking the deck. Relationships live in .rels files kept in a _rels sub-folder beside the part they describe. The package-level _rels/.rels names the start part (the presentation), and ppt/_rels/presentation.xml.rels lists what presentation.xml depends on.

<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
  <Relationship Id="rId1"
     Type=".../officeDocument/2006/relationships/slide"
     Target="slides/slide1.xml"/>
  <Relationship Id="rId2"
     Type=".../relationships/slideMaster"
     Target="slideMasters/slideMaster1.xml"/>
</Relationships>

Inside presentation.xml, the slide list refers to a slide only by its relationship id:

<p:sldIdLst>
  <p:sldId id="256" r:id="rId1"/>
  <p:sldId id="257" r:id="rId3"/>
</p:sldIdLst>

The r:id="rId1" is resolved through the relationships file to the actual target slides/slide1.xml. The same mechanism attaches an image to a slide: the slide’s XML says “fill this shape with the picture at rId5”, and the slide’s own .rels file maps rId5 to ../media/image1.png. Reordering slides is therefore an edit to the sldIdLst, not a rename of any file.

presentation.xml: slide order, size and the master list

The ppt/presentation.xml part is the top of the presentation tree. It holds no slide content itself; it records the deck’s structure. Three things matter here. The <p:sldMasterIdLst> lists the slide masters, the <p:sldIdLst> lists the slides in display order (each entry a relationship id, as above), and <p:sldSz> gives the slide dimensions.

Slide size is expressed in English Metric Units (EMU), the fixed-point unit used throughout DrawingML. One inch is 914400 EMU and one centimetre is 360000 EMU, chosen so both imperial and metric values are exact integers. A standard 16:9 slide is cx="12192000" cy="6858000" EMU, which is 13.333 by 7.5 inches. Because EMU are integers, a shape’s position and size survive round-tripping without the rounding drift that a floating-point unit would introduce.

Inside a slide: the shape tree and DrawingML

Each slide is a self-contained part, ppt/slides/slideN.xml, in the PresentationML namespace (conventional prefix p:). Everything visible on the slide hangs off a single shape tree, <p:spTree>. Each shape is a <p:sp> carrying non-visual properties (an id and name), shape properties (<p:spPr>, holding position and size as an <a:xfrm> transform in EMU), and, for a text box, a text body.

<p:sld xmlns:p="http://schemas.openxmlformats.org/presentationml/2006/main"
       xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main">
  <p:cSld>
    <p:spTree>
      <p:sp>
        <p:spPr>
          <a:xfrm>
            <a:off x="838200" y="365125"/>   <!-- position, EMU -->
            <a:ext cx="7772400" cy="1470025"/> <!-- width/height, EMU -->
          </a:xfrm>
        </p:spPr>
        <p:txBody>
          <a:p><a:r><a:t>Quarterly results</a:t></a:r></a:p>
        </p:txBody>
      </p:sp>
    </p:spTree>
  </p:cSld>
</p:sld>

Two namespaces cooperate. The p: (PresentationML) namespace describes the slide-level containers: the slide, its shape tree, placeholders and timing. The a: (DrawingML) namespace describes the graphics common to all Office apps: the transform, geometry, fills, line styles and the text itself. Inside a text body, a paragraph is <a:p>, a text run with uniform formatting is <a:r>, and the literal characters are in <a:t>. Run properties such as bold or size sit in an <a:rPr> before the text, with font size given in hundredths of a point (sz="1800" is 18 pt).

Masters, layouts and formatting inheritance

PowerPoint formatting is a three-level inheritance chain, and each level is its own part connected by relationships. A slide master (slideMasters/slideMasterN.xml) defines the base look: the theme reference, background, and the position and default text style of each placeholder type (title, body, date, slide number). A slide layout (slideLayouts/slideLayoutN.xml) is based on a master and specialises it, for example “Title and Content” or “Two Content”. A slide is based on a layout and supplies the actual content.

The link between the levels is a placeholder index. A placeholder shape carries <p:ph type="title"/> or <p:ph idx="1"/>, and a slide inherits position, size and default text formatting from the matching placeholder on its layout, which in turn inherits from the master. A slide only overrides what it changes. That is why editing the master retitles or restyles every slide at once, and why one master’s theme colours propagate through all its layouts and slides.

The theme part: colours, fonts and EMU geometry

A ppt/theme/themeN.xml part holds the design vocabulary the rest of the deck refers to by name rather than by literal value. Its colour scheme names twelve slots — four text/background colours, six accents, plus hyperlink and followed-hyperlink — and shapes reference them symbolically (<a:solidFill><a:schemeClr val="accent1"/></a:solidFill>). Change accent1 in the theme and every shape bound to it recolours. The font scheme names a major (heading) and minor (body) font, again referenced by role, so swapping the theme font restyles the whole deck. Keeping design tokens in the theme, and content in the slides, is what makes a PowerPoint template reskinnable.

PPTX versus PPTM: why the extension matters for macros

A plain .pptx cannot contain or run VBA macros. This is enforced by the content-type system, not by convenience: macro-enabled presentations use a different extension, .pptm, and a different top-level content type, and their VBA project is stored as a separate ppt/vbaProject.bin part (an OLE2 stream) that a .pptx is not permitted to declare. The practical security consequence is that a file that is genuinely a .pptx is a passive bundle of slides, images and XML with no code path to execute.

The attack that abuses this is disguise. A malicious .pptm can be renamed to look like a harmless .pptx, or its content types can be crafted so the macro project rides in unexpectedly; opening it and clicking “Enable Content” runs the VBA. Modern PowerPoint opens files from email and the internet in Protected View and disables macros by default for exactly this reason. Two defences follow from the structure. First, treat an unexpected prompt to enable macros as a red flag, since a real informational deck never needs them. Second, because the file is an OPC ZIP, you can inspect it before opening in PowerPoint at all: extract it as a ZIP and check whether a vbaProject.bin part and a macro-enabled content type are present.

References