What an AI PowerPoint generator actually has to build

The question behind the search is not which tool is cleverest. It is whether the thing that arrives is a file you can open and edit, or a picture of a file. Those are different products sold under one description, and the difference is decided long before anything reaches your screen — in whether the software wrote a real .pptx or rendered slides and wrapped them.

We write ours by hand: the ZIP container, the XML parts inside it, the relationships between them, byte by byte, with no library. That is why this page can describe the file rather than the marketing. Below: what is actually inside a .pptx, the mistakes that quietly corrupt one, the reader that refused every file we had ever shipped, and what waiting for a generated deck measurably looks like.

A .pptx is a ZIP, and that is the whole test

Rename a presentation to .zip and unpack it. What comes out is a folder of XML files. There is no proprietary binary blob and no secret: a presentation is a small website of documents that reference each other, standardised as ECMA-376 and readable in a text editor.

deck.pptx
├── [Content_Types].xml       declares what every part inside is
├── _rels/.rels               the way in — points at the presentation
└── ppt/
    ├── presentation.xml      slide order, slide size
    ├── slideMasters/…        the frame every page inherits
    ├── slideLayouts/…        the placeholder geometry
    ├── theme/theme1.xml      fonts and colours, named not baked
    ├── slides/slide1.xml     one XML file per slide
    ├── slides/_rels/…        what each slide points at
    ├── notesSlides/…         the speaker notes
    ├── charts/chart1.xml     a real chart, not an image of one
    ├── embeddings/data1.xlsx the spreadsheet behind that chart
    └── media/image1.png      the pictures

Almost everything that can go wrong with a generated presentation is a shortcut around that structure. Render each slide to a picture and drop the pictures in, and you get a file that opens in PowerPoint and cannot be edited in it. Fill a fixed template, and you get a genuinely editable file that is also the file everybody else received. Export only a PDF and the question is sidestepped. All three are legitimate decisions; none of them is what most people think they are buying.

We write the container ourselves, byte by byte

Our renderer runs inside a Cloudflare Worker, where there is no zip library to reach for, so the container is written in our own code: a CRC-32 checksum computed from a 256-entry table, compression through the platform's own CompressionStream('deflate-raw'), and then the three record types a ZIP is made of — a local header before every file, a central directory listing them all, and an end-of-central-directory record pointing at that list. Office is unforgiving about those layouts. A field one byte wide in the wrong place produces a file that opens nowhere.

One consequence a buyer can feel: the renderer is pure — no network, no clock, no randomness — so the same brief and the same brand produce the same bytes. That is what makes it testable at all, rather than something you check by opening the result and squinting.

Element order is a sequence, not a set

The schema behind a slide is not a bag of allowed elements. It is an ordered sequence, and a reader that meets them in the wrong order rejects the file. CT_Slide takes cSld, then clrMapOvr, then transition, then timing, then extLst — so a cross-fade written before the colour map override is a corrupt presentation, not a presentation with an odd transition. Same elements, same values, different order, and the file is refused.

The neighbouring trap is quieter and worse. A relationship target resolves against the folder of the part that declares it, not against the root of the package. A picture referenced from a Word document says media/image1.png; the same picture referenced from a slide, which sits one folder deeper, has to say ../media/image1.png. Get it wrong and the package unzips perfectly, passes every integrity check, and shows an empty picture frame. Nothing reports an error. That is the hardest class of bug in this format: the file is valid and the deck is wrong.

The one element that made Keynote refuse every deck

Keynote refused our decks outright — "The file format is invalid" — while PowerPoint opened them, LibreOffice opened them, every relationship resolved, every part had a content type, and macOS Quick Look drew a thumbnail from the same file.

The cause was one optional element. Our slides emitted p:clrMapOvr and our notes slides did not. The schema allows a notes slide to omit it. Keynote does not. Every deck this product had ever produced carried speaker notes, so every deck had been unopenable for any client on a Mac without Office. It was found by bisection, driven from AppleScript against Keynote itself: strip the notes and it opens, restore them with the element added and it opens with everything intact.

Why a generated deck so often arrives as a PDF

Because of type. Our decks name Constantia and Corbel, which exist wherever Office is installed and nowhere else. Opened in Keynote on a Mac without Office, a real deck of ours reported "this presentation has missing font" and substituted silently — a deck that was designed once and looks different in the room.

The obvious fix is to embed the fonts in the file. We tested whether that works before building it, which is the step worth copying.

So embedding is days of binary work — the embedded data is EOT-wrapped rather than raw TrueType, a detail that silently defeats anyone implementing from the spec alone — to serve, at best, the one reader we cannot test. The deliverable inverts instead. A PDF embeds its fonts always, everywhere, so every job but a single image — decks, branded documents and reports alike — stores a PDF beside the editable file: the PDF is what you forward, the .pptx is the working copy. The converter substitutes a real editorial pair on the way through — Newsreader and Source Sans 3, verified with pdffonts on a converted deck — while the .pptx keeps naming the face an Office client already has.

The PDF is strictly an addition: by the time it runs the editable file is already stored, and the converter can never turn a delivery that worked into a job that failed. If a tool offers you only a PDF, that is not a delivery-format decision. It is the answer to the editability question.

Six things to check in the file itself

Every one of these takes under a minute on a trial output, and each exists because getting it right in our own renderer was harder than expected.

Writing the file is the easy half

A valid, editable, correctly ordered package can still look like every other generated deck, and that is a separate discipline. Our style engine varies a deck along eleven axes, which the default world leaves entirely free — 52,488 combinations. A blind study of ten decks found the picture treatments distinct on only 2 of 10. One flag caused it: the photo axis declares three treatments, and six of the eight places that draw panels never reached the third, so it fell through and drew the identical rectangle. The arithmetic multiplied by three; the page varied by two. Fixed on 23 August 2026 — those six now draw a stepped edge. The study is in why AI decks look the same.

What waiting actually looks like

These are the delivered jobs in the production database, by kind, as of 23 August 2026.

Eighty-seven per cent of every job ever submitted was delivered; eight failed and two were still working when the count was taken. Four images and one report is not a sample, so those means are printed because they are what exists, not because they forecast anything. Only the deck row has enough jobs behind it to be worth planning around, and its shape — a floor around two minutes and a long tail — is set out in full in how long an AI presentation takes.

One measured detail explains a good deal of the tail. Illustrations are requested from the provider one at a time, not as a burst. Firing five at once returned four failures; the same five fired individually all succeeded first time. Serialising them is slower per deck and is the reason the pictures arrive at all. The file itself does not wait for them — it is delivered as soon as the writing is laid out, and rebuilt in place under the same link as the artwork lands.

What it costs, and what that buys

During the alpha a credit is one US dollar. A slide deck is 25 credits, a branded document 10, a data report 15, a single image 1, and ten credits are granted free on signup — enough for a whole branded document before you decide anything. Every price here is an indicative estimate rather than a quote.

What that pays for is the file described above: an editable .pptx with real text, real charts with their workbooks attached, speaker notes, your colours and your logo, plus a PDF for sending. Not a rendering of one.

What we cannot tell you

Where every number on this page comes from

If you want the engineering rather than the buying decision, the long version is next door. If you want the output, generate one on your own brand with the free credits and run the six checks on it. That is a better test than anything written here.