What Is Actually Inside a .pptx File

Take any .pptx file on your machine, rename the extension to .zip, and open it like any other archive. A PowerPoint file is not one document. It’s an Open Packaging Conventions ZIP package, the same container format Word and Excel use, holding a folder of separate XML parts that only look like a single file because PowerPoint assembles them for you on every open. Once you’ve opened one, .docx and .xlsx stop being mysterious too, because they’re built from the same container, just with a different set of parts inside.

What’s actually in the archive

Unzip it and you’ll find something close to this:

Each slide is its own XML file. There’s a master part, a layout part, and a theme part, and a minimum valid presentation needs all four kinds present, not just the slides. The whole format is defined formally by ISO/IEC 29500 and ECMA-376, which is a strange thing to learn about a file you’ve been dragging text boxes around in since high school.

The part that explains the bugs nothing else explains

None of these parts contain each other. A slide doesn’t hold its layout, it holds a reference to it, and the references live in separate .rels files, one per part, mapping an id to whatever it actually points at. slide1.xml says “my layout is relationship id 2.” slide1.xml.rels is the only place that says what relationship id 2 actually is.

That’s the part that explains bugs that make no sense if you’ve only ever seen the file through PowerPoint’s UI. If a .rels file drifts out of sync with the parts it’s supposed to point at, from a bad save, a rough merge, or a tool that edited the zip directly and missed a reference, you get a relationship id pointing at a part that no longer exists. The slide fails to render, or quietly falls back to nothing. PowerPoint may show a repair prompt or may just render the slide wrong. Either way it will not tell you that the cause is one dangling id in a .rels file. I have not tested every case, so treat this as the common pattern, not a rule.

How to actually look inside one

The whole exercise costs nothing and needs no special tool. Duplicate a .pptx file so you’re not touching the original, rename the copy’s extension to .zip, and extract it like any archive. Open ppt/slides/slide1.xml in a plain text editor and it reads like markup for anything else on the web, tags and attributes, just verbose. The relationship file for that slide sits in ppt/slides/_rels/slide1.xml.rels, and it looks close to this:

<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
  <Relationship Id="rId1" Type=".../slideLayout" Target="../slideLayouts/slideLayout1.xml"/>
</Relationships>

Every Id in that file is a name a slide’s own XML can point to. Every Target is where that name actually leads. When the two drift apart, that’s the whole bug, and now you know exactly where to look for it instead of clicking around a menu hoping PowerPoint tells you something it structurally can’t.

Slide size is a setting, not a shape

Even the page size is a small XML value rather than something baked into the geometry of every shape on the slide. It lives in <p:sldSz>, with a width and height measured in EMUs, and the two sizes most decks use are 13.33 by 7.5 inches for widescreen and 10 by 7.5 inches for the old 4:3 ratio. The ISO/IEC 29500 definition of sldSz says it is the size of the background surface shown when the slide is presented or printed. Shapes carry their own absolute coordinates. Change that one value and the shapes are measured against a canvas of a different size.

That is why a size change can make shapes drift or stretch. PowerPoint’s own resize dialog offers to scale content, so a size change inside PowerPoint behaves better than editing the value by hand.

Why this matters if you write decks as text

I make Slaide. Its .pptx export produces an editable PowerPoint file with real text, shapes, and images, per the docs. It is not a screenshot pasted onto a blank slide. I have not listed its internal parts here, so open an export yourself and look.

Where it can’t help you: importing a deck that uses charts, SmartArt, or custom art. Slaide’s import docs say that in the default hybrid mode these are rasterized, not rebuilt as editable shapes. That is a real limit of going through this format.

Next time a deck breaks in a way nobody in the room can explain, that’s usually not a metaphor. Somewhere in the zip is one id pointing at a part that isn’t there anymore.