Why Every AI Deck Tool Breaks on Export (and How Kinsy Doesn't)

By the Kinsy team · Published 10 July 2026

You've seen it. The deck looked immaculate in the browser. You pressed Export, opened the .pptx before the meeting, and there it was: a headline wrapped onto a third line, bullets that became a picture of bullets, a font that isn't the font. This post explains precisely why that happens — and the architectural decision that makes it not happen.

Two media that pretend to be one

A web page and a PowerPoint slide look similar and are opposites. The web is a flow medium: content has no fixed height, boxes stretch to fit text, layout is computed at view time by whatever browser is looking at it. A slide is a fixed-geometry medium: a canvas of exact dimensions where every shape has hard coordinates, computed once, by the authoring tool.

Nearly every AI deck generator is a web app that designs in the flow medium — HTML and CSS — because that's what web apps are made of. The "slide" you admire is a div. Export to .pptx is therefore a translation between media, and translation is where everything breaks.

The four classic export failures

1. Text reflow

Browsers and PowerPoint measure text differently — different line-breaking rules, kerning, hinting, and line-height arithmetic. A sentence that fits on two lines in Chrome can need three in PowerPoint. Every box that depended on the two-line measurement is now wrong: text collides with the shape below, or overflows the slide entirely. This is the single most common breakage, and it's unfixable in the general case as long as the design was authored in browser metrics.

2. Font substitution

The web can serve any font to any viewer; PowerPoint can only use fonts installed on the opening machine — unless the file embeds them, which most exporters don't. So the exporter either restricts you to a dozen "safe" fonts, or ships a file that silently swaps your typeface for Calibri on your client's laptop, changing every measurement on every slide (see failure #1, recursively).

3. Rasterisation — the screenshot in a trenchcoat

When a web element has no PowerPoint equivalent — a gradient card, a CSS chart, an unusual shape — exporters take the easy exit: render it to a PNG and paste the picture onto the slide. The slide now looks right and is dead. Your "bullets" can't be edited, your chart's numbers can't be updated, and the file your client tries to tweak fights back. Some tools rasterise entire slides this way. If you can't click into a text box, you're holding a screenshot in a trenchcoat.

4. Approximated geometry

Flow layouts don't have coordinates until a browser computes them, so the exporter must invent PowerPoint coordinates — freezing one particular rendering and hoping. Variable-height cards get cropped or squeezed into 16:9; overlaps and z-ordering shift; spacing that was calculated turns into spacing that was guessed.

The fix is architectural, not incremental

None of these are bugs a converter team can patch away. They're the cost of authoring in one medium and delivering in another. The only complete fix is to stop translating: author in the delivery medium.

That's Kinsy's entire rendering philosophy:

• Slides are born as PPTX. Kinsy's design engine composes every slide server-side directly in PowerPoint's coordinate system — real text frames, native shapes, exact positions. There is no HTML original to betray.
• The preview is a render of the file. What you see in the browser is generated from the .pptx, not the other way round. Approve the preview and you've approved the actual file — they cannot disagree, because they are the same artefact.
• Fonts are embedded, and licensed for it. Kinsy's themes use open-licensed (OFL) typefaces embedded in the file, so the deck opens with the designed type on any machine — no substitution, no reflow, and no licensing awkwardness when the file travels.
• Geometry is designed within slide physics. Layouts are composed to PowerPoint's fixed canvas from the start — text measured with the renderer that will display it — so nothing needs to be cropped, squeezed, or guessed at export time.
• Everything stays an object. Headlines, bullets, labels, shapes: all native and editable. AI-generated imagery is an image, as it should be; your words never are. Speaker notes travel in the file too, in PowerPoint's own notes pane.

"Why don't the others just do this?"

Fair question. Because it's expensive, and because it constrains design. Authoring in PPTX means running a real rendering pipeline on servers instead of borrowing the user's browser, and it means every layout must be expressible as PowerPoint objects — no CSS tricks, no reflowing cards, no web-only flourish. Tools that were web products first would have to rebuild their design systems from the file up. We could start there, so we did. The result is a smaller, more disciplined set of themes than a template marketplace — and a file that simply does not break.

How to audit any deck tool in five minutes

1. Generate a content-heavy deck — long bullets, a chart, a distinctive font.
2. Export to .pptx and open it in desktop PowerPoint, ideally on a machine without design fonts installed.
3. Click every text element. Does it select as text, or as a picture?
4. Compare line breaks against the browser preview, slide by slide.
5. Check the fonts dialog: is your typeface present and embedded, or substituted?

Any tool that survives all five is authoring in the delivery medium. We built Kinsy so that it would — run the audit on us first.