What is a .pptx file?
A PowerPoint presentation is a collection of slides. Each slide is a canvas of text boxes, shapes, pictures, tables, and charts — each with many properties. A .pptx file is where all that content and those properties are stored.
In this explainer you will build the file yourself: from a single giant text file, to consolidated shared properties, to separate files in folders, to the actual XML inside a real .pptx ZIP package — and finally to the 5,000-page specification that makes automating PowerPoint so hard.
Use the step buttons above or the ← → arrow keys to move through the arc. On each step, try the controls and inspect the file contents you are creating.
The naive text file
You could try writing everything down in one text file. Start with one slide and one textbox, then add a second slide and watch the listing grow and repeat itself.
Slide canvas
Property listing
Consolidate repeated properties
Every slide has the same width, height, background, and font. Move those shared properties up to a presentation-level file and see exactly which lines are lifted out of each slide.
Per-slide listing
Break into folders
A 30-page deck in one giant file is unwieldy. Break it into folders: one per slide, a media folder for pictures, an embeddings folder for Excel data, and a charts folder for chart properties.
Folder tree
File contents
Select a file in the tree to inspect its contents.
It is a ZIP package
Congratulations — you have reinvented the architecture of a .pptx file. A real .pptx is a ZIP package. Rename it to .zip and the same folders appear with XML inside.
Your informal structure
Part contents
Select a file in the tree to inspect its contents.
The mapping is almost one-to-one: pictures become media, excel becomes embeddings. Layouts and masters exist too, but we are leaving those for another day.
The XML layer
This is the real slide1.xml for the “Hello world!” textbox. The position and
size numbers are not in inches — they are EMU (English Metric Units).
Drag the textbox on the mini-slide to see the XML update in real time.
Drag the textbox
Drag the box to move it. The XML above and the converter below update as you drag.
EMU ↔ inches
1 inch = 914,400 EMU 1 cm = 360,000 EMU
The real textbox starts at 5,359,675 × 3,244,334 EMU, sized 1,472,650 × 369,332 EMU. That is roughly 5.86″ left, 3.55″ top, 1.61″ wide, 0.40″ high.
Where did the font go?
The 18 pt Arial font is missing from the slide XML because it lives in a shared file.
In a real .pptx, theme font families live in ppt/theme/theme1.xml:
<a:fontScheme name="Office">
<a:majorFont>
<a:latin typeface="Arial"/>
</a:majorFont>
<a:minorFont>
<a:latin typeface="Arial"/>
</a:minorFont>
</a:fontScheme>
The honest coda
This sounds simple, but the actual implementation is a minefield.
The 5,000-page specification
OOXML was standardized by Ecma in 2006 and adopted by ISO in 2008. The main specification is over 5,000 pages — about four complete Lord of the Rings trilogies. Printed single-sided, the paper stack would be about 20 inches (50 cm) tall.
Specification stack
~20 reams of 250 pages each
Four LoTR trilogies
≈ 4 complete trilogies
Paper height
≈ 20″
~50 cm tall, single-sided
Theory 1: artificial complexity as lock-in
The Document Foundation (creators of LibreOffice) argues that OOXML’s complexity is intentionally excessive — a way to keep users inside the Microsoft ecosystem.
“Unfortunately, while an XML schema can be simple, it can also be unnecessarily complex, bloated, convoluted and difficult to implement without specific knowledge of its features. This artificial complexity is characterised by a deeply nested tag structure with excessive abstraction, dozens or even hundreds of optional or overloaded elements, non-intuitive naming conventions, the widespread use of extension points and wildcards, the multiple import of namespaces and type hierarchies, and sparse or cryptic documentation.”
— The Document Foundation, 2025
Theory 2: a 40-year-old codebase made visible
PowerPoint dates to 1987. OOXML had to represent decades of bolted-on features without breaking compatibility with existing decks. The kinder view is that the format is messy for the same reason any 40-year-old codebase is messy.
It is not just a committee design; it is years of compatibility decisions made visible in a format that should never break.
Takeaway
A PowerPoint file is a ZIP package of XML files and binary assets, organized to avoid repetition. That hidden minefield is exactly why automating PowerPoint with code — and why AI agents editing decks — is so hard.