Deep dive · 10 min read

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

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.

Side by side: the slide you approve in the browser, and the same slide after translation to PowerPoint — the headline rewraps, spacing shifts, and the hatched parts arrive as flattened pictures rather than editable text. What you approve on screen Text, image and layout as designed export What opens in PowerPoint Title rewrapped · hatched parts arrive as pictures, not text
The translation tax, in one frame: text remeasured, fonts substituted, hatched parts flattened to pictures — the four failures below, all at once.

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 uses whatever the opening machine happens to have installed. So most exporters either restrict you to a dozen "safe" fonts, or ship 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.

Why this is a genuinely hard problem

None of these four are bugs a converter team can patch away, because they interact. Match PowerPoint's text behaviour and you've constrained which typefaces you can offer. Guarantee the typefaces and you've constrained the layouts. Refuse to rasterise — keep every element a live object — and you've given up the one escape hatch that hides the other three failures. Every deck tool sits somewhere on this trade-off surface, and most quietly optimise for "looks right in the browser", because the browser is where the demo happens. The export happens after the subscription starts.

Solving all four simultaneously — editable objects, faithful type, exact geometry, and a preview that never lies — is the hardest engineering problem in this product category. It isn't a converter with better settings. Getting it right took us longer than deck generation itself, and defending it is where most of Kinsy's engineering effort lives today.

What Kinsy guarantees instead

We're deliberately not going to publish how our rendering pipeline works — it's the most valuable thing we've built. What we will publish is the guarantee, because every part of it can be tested from the outside:

How to audit any deck tool in five minutes

  1. Generate. A content-heavy deck — long bullets, a chart, a distinctive font.
  2. Export and open. 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 has done the work. We built Kinsy so that it would — run the audit on us first.

Keep reading

Export one. Open it. Click the text.

100 free credits — about one full deck. The .pptx will behave.

Make a deck free