What's actually inside a .pptx file

The format is Office Open XML, standardised as ECMA-376 and as ISO/IEC 29500. A .pptx file is an Open Packaging Convention package, which is a zip archive with rules about what the files inside are called and how they refer to each other. There is nothing to decode.

cp deck.pptx deck-copy.zip
unzip deck-copy.zip -d deck-contents

# Or, without unpacking, just list what is in there by size:
unzip -l deck.pptx | sort -k1 -n -r | head -20

On Windows, rename a copy to .zip and open it in Explorer. On macOS, rename to .zip and double-click. Work on a copy, because a zip utility that helpfully re-compresses on close can leave you with an archive PowerPoint no longer accepts.

Sources: [1] [3]

A newly unpacked deck looks roughly like this. Names are fixed by the specification, so what you see will match, whatever produced the file.

[Content_Types].xml
_rels/
  .rels
docProps/
  app.xml
  core.xml
ppt/
  presentation.xml
  _rels/
    presentation.xml.rels
  slides/
    slide1.xml
    slide2.xml
    _rels/
      slide1.xml.rels
  slideLayouts/
  slideMasters/
  theme/
    theme1.xml
  media/
    image1.png
  fonts/

[Content_Types].xml

Declares the MIME type of every part in the package. Nothing can be read without it, which is why a package missing this file is unopenable rather than partly readable.

ppt/presentation.xml

The deck itself: slide size, the ordered list of slide ids, the default text styles. This is where the slide dimensions live.

ppt/slides/slideN.xml

One file per slide, each a tree of shapes. This is where your content is.

ppt/slideLayouts/ and ppt/slideMasters/

The inheritance chain. A slide inherits from a layout, which inherits from a master, which draws its colours and fonts from the theme.

ppt/theme/theme1.xml

The colour scheme and the heading and body font choices. Change the theme font here and every shape that uses the theme font follows.

ppt/media/

Images, video and audio, stored as ordinary files. Nothing is recompressed on the way in, so a 12 MB photo you dropped onto a slide is a 12 MB file in here.

ppt/fonts/

Present only when fonts are embedded. Each embedded font is a separate file, and this folder is where you can see exactly what embedding cost you.

_rels/ folders

Relationship files. Each part that refers to other parts has a matching .rels file listing those references by id.

The relationship indirection is the part that surprises people. A slide does not contain the path to its image. It contains a relationship id, and the slide's .rels file maps that id to ../media/image1.png. The same is true of the link between a slide and its layout, and between a slide and any hyperlink it contains.

<Relationships xmlns="...">
  <Relationship Id="rId1" Type=".../slideLayout"
                Target="../slideLayouts/slideLayout2.xml"/>
  <Relationship Id="rId2" Type=".../image"
                Target="../media/image1.png"/>
</Relationships>

Sources: [1] [3]

Open any slideN.xml and the structure is the same: a shape tree, spTree, containing one entry per object on the slide. Here is a single text box, stripped of the namespace noise.

<p:sp>
  <p:nvSpPr>
    <p:cNvPr id="2" name="Title 1"/>
  </p:nvSpPr>
  <p:spPr>
    <a:xfrm>
      <a:off x="838200" y="1122363"/>
      <a:ext cx="10515600" cy="2387600"/>
    </a:xfrm>
  </p:spPr>
  <p:txBody>
    <a:p>
      <a:r>
        <a:rPr lang="en-GB" sz="4400" b="1"/>
        <a:t>Quarterly results</a:t>
      </a:r>
    </a:p>
  </p:txBody>
</p:sp>

a:off

The offset of the shape's top-left corner from the top-left of the slide, in EMUs.

a:ext

The extent, meaning width (cx) and height (cy), also in EMUs.

a:r and a:t

A run of text and the text itself. Formatting that changes mid-sentence starts a new run, which is why a heading with one bold word contains three runs.

sz="4400"

Font size in hundredths of a point. This is 44pt. Text uses a different unit from geometry, which is a genuine wrinkle in the format.

This is what "editable" means, concretely. The word "Quarterly" is in the file as characters. Anything that can read XML can find it, count it, translate it or replace it. A flattened export has none of this: the shape tree contains one picture, and the words exist only as coloured pixels inside a PNG in ppt/media.

Sources: [1]

Every position and size in DrawingML is an integer number of English Metric Units. One EMU is 1/914400 of an inch and 1/360000 of a centimetre.

The odd-looking constant is deliberate. 914,400 is the lowest common multiple of 100 and 254, multiplied by 72. That single choice means hundredths of an inch, millimetres and points all divide into it exactly, so a document can be authored in centimetres in one locale and inches in another with no floating-point drift and no rounding error accumulating across a slide.

It is also why generating slides programmatically is more exacting than it looks. Every measurement taken in pixels or points has to be converted into an integer EMU, and a conversion that rounds in the wrong direction on each of twelve elements produces a slide where nothing quite lines up.

Sources: [2] [1]

Three levels, each inheriting from the one above.

1. The slide master defines the background, the placeholder positions and the default text styles for a family of layouts.
2. A slide layout inherits from the master and specialises it: title slide, title and content, two content, and so on.
3. A slide inherits from one layout and overrides whatever it needs to.

Overrides are stored locally on the slide. This is the mechanism behind the most common frustration in PowerPoint: you change a font on the master, and some slides do not follow. Those slides have a local override written into their own XML, set at some point by someone selecting text and picking a font directly, and a local value always wins.

Unpacking the deck makes this visible. If slide7.xml contains a typeface name and the others do not, you have found your exception, and you have also found the reason template compliance is hard to enforce by eye.

A deck with many masters is worth checking for a different reason: each one carries its own layouts, and decks assembled by pasting slides from several sources accumulate them. It inflates the file and it is why the layout gallery sometimes offers the same layout four times.

Sources: [1]

1. 1

   Find out why the file is enormous

   List the archive sorted by size. If ppt/media dominates, the fix is image compression, not deleting slides. If ppt/fonts dominates, you embedded all characters of a very large font.

2. 2

   Extract every image at full quality

   The files in ppt/media are the originals as they went in. This is the cleanest way to recover a photo whose source you lost, and it beats screenshotting the slide.

3. 3

   Prove whether a deck is really editable

   Search ppt/slides for a phrase visible on screen. Present means real text. Absent means the slide is a picture.

4. 4

   Rescue a deck PowerPoint refuses to open

   Unpack it and look for a truncated or empty XML part. A single corrupt slide can often be removed, along with its entry in presentation.xml and its relationship, leaving the rest of the deck recoverable. Always on a copy.

5. 5

   Diff two versions of a deck properly

   Unpack both and compare the slides folders. XML diffs show exactly which shape moved and which run of text changed, which no visual comparison will tell you reliably.

Sources: [4] [1]