Blog · Engineering

What's actually inside a .pptx file, and why most AI exports are pictures

A PowerPoint file is a zip of XML documents. Once you know what's in there, the difference between a real export and a screenshot becomes obvious in about thirty seconds.

The AI Slide Deck Editorial Team · · 2 min read

An iceberg with a small visible peak and a large mass below the waterline, annotated with labelled cards

Rename any .pptx to .zip, unzip it, and you get a directory tree. Slides live in ppt/slides as one XML document each. Themes live in ppt/theme. Media (genuine images, the kind that should be images) sits in ppt/media. That is the whole format, more or less, and it is worth twenty minutes of your time if you buy presentation software for a living.

The thirty-second test

Open a deck exported from any AI presentation tool. Look at ppt/media. If there is one large PNG per slide, you already know what you bought: the tool rendered a web page, photographed it, and pasted the photograph onto an empty slide. Everything else in the file is packaging.

If the media folder has as many images as the deck has slides, the deck has no text in it.

The reason is rarely laziness. It is that the slide never existed as a slide. It existed as HTML and CSS in a headless browser, and there is no honest mapping from a flexbox layout to a PowerPoint shape tree. Screenshotting is the only faithful way to preserve what the user saw.

What a real slide looks like

A native slide is a shape tree. Each shape has geometry, a fill, and optionally a text body made of paragraphs and runs. A run is a span of text with consistent formatting. This is the thing your colleague clicks into on Monday morning.

<p:sp>
  <p:txBody>
    <a:p><a:r>Q3 revenue grew 34%</a:r></a:p>
  </p:txBody>
  <a:solidFill><a:schemeClr val="accent1"/></a:solidFill>
</p:sp>

Note the fill. It is not a hex code; it is a reference to accent1 in the theme. Change the theme and every shape pointing at that slot moves with it. This is why our brand kit restyle works on an exported file and not just in our editor. The color was never written into the slide in the first place.

Why we build the document first

Our model doesn't emit markup. It emits a slide document: shapes, text runs, color roles, chart series. The editor renders that document to the screen and the exporter writes the same document to OOXML. There is exactly one source of truth, so the two cannot drift apart, and neither of them needs a screenshot.

It is a slower path to a good-looking demo and a much faster path to a file somebody can actually use.

Join the waitlist

We're onboarding in small batches so support stays fast. One email when your invite is ready.

No newsletter. Prefer the full form?