Blog

Codex | 11 min read | 2026-04-25 | Updated 2026-04-26 | By Variant Team

Use Codex to Generate Editable Presentation Decks

A Codex workflow for generating editable HTML/CSS presentation decks, reviewing the source, cleaning up visuals, and exporting to HTML, PDF, or PPTX.

Author: Variant Team. Variant is built by a small team working on HTML-native presentation tools, MCP workflows, and agent-editable decks.

Short version: ask Codex for slide source, not a final binary deck. Have it write HTML and CSS in small, reviewable pieces, then move the result into a visual editor where you can fix typography, replace weak visuals, and export the version people actually need.

Codex is strongest when the deck behaves like code. It can create a template, patch a section, keep styles consistent, and explain what changed. It is much less fun when you ask it to manufacture a PPTX directly and hope the archive opens.

This post uses a simple launch deck workflow: prompt, template, slide batches, visual cleanup, and export. You can inspect the finished example here: download the Codex editable launch deck.

#Quick answer

  • Ask Codex for HTML/CSS slide source, not a PPTX file.
  • Generate one template first, then generate slides against that template in small batches.
  • Review the deck in a browser before moving it into a visual editor.
  • Keep the output editable: real text, CSS variables, named sections, and no flattened text images.
  • Export to HTML, PDF, or PPTX only after the deck has survived a human pass.

#Why HTML is the right format for Codex slides

Codex was trained on a lot of code. It's confident with HTML, CSS, and a moderate amount of vanilla JS. It is not confident with the binary internals of a .pptx file, and you don't want it there anyway: PPTX is a zip of XML with strict ordering rules, and one wrong tag breaks the whole archive.

Two practical consequences:

  1. Ask for HTML, not PPTX. A slide as <section> markup with inline CSS variables is something Codex can produce reliably and you can read at a glance.
  2. Treat each slide as one file or one section. Don't ask for "a 30-slide deck" in one shot. Ask for one slide template, then iterate. You'll get better layout, less hallucinated content, and a much easier diff when you want to change something.

The bonus: a slide that's HTML can be opened in any browser, version-controlled in git, diffed in a PR, and re-rendered by any tool that understands a <section> tag. Including Variant, which treats single-file HTML as a first-class deck format.

#The workflow at a glance

Here's the loop I'll spend the rest of the post on:

  1. Define the deck's shape (audience, sections, look) as a short brief.
  2. Have Codex draft a slide template and a content schema.
  3. Generate slides one at a time or in small batches.
  4. Open the result in a presentation editor for visual review.
  5. Hand-edit anything Codex got wrong instead of regenerating from scratch.
  6. Export to HTML, PDF, or PPTX depending on where the deck is going.

The whole thing usually fits in 30 to 60 minutes for a 10 to 15 slide deck, including the part where you stop and rewrite a headline you don't like.

#Step 1: write a brief Codex can actually use

Don't say "make me a deck about our Q2 launch." Codex will produce something technically correct and emotionally beige.

Give it the same brief you'd give a junior designer:

Audience: senior engineers at series B startups.
Goal: get them to try the new SDK.
Sections: problem, what's new, demo, pricing, CTA.
Tone: confident, dry, no marketing fluff.
Look: dark background, monospace headlines, one accent color.
Constraints: 16:9, 1920x1080, single HTML file per slide,
no external CSS, no JS frameworks.

A brief like this gives Codex two things it normally lacks: a target reader and a visual constraint. The constraints matter more than people think. "No external CSS" forces it to keep the slide self-contained, which makes the file portable. "1920x1080" gives it a coordinate system instead of guessing.

Codex CLI session with a structured deck brief
Codex CLI session with a structured deck brief

#Step 2: ask for one template, not a deck

Your first prompt should produce a single slide template that you'll reuse. Something like:

Write a single HTML file for one slide in the deck described above.
Use the "section heading" layout: a large title, a one-line dek,
and a small footer with the section number and deck title.
Inline all styles in a <style> tag.
Use CSS custom properties for colors, type scale, and spacing.
Output the full file. No commentary.

You should get back something like:

<!DOCTYPE html>
<html>
<head>
  <style>
    :root {
      --bg: #0b0b0d;
      --fg: #f5f5f4;
      --accent: #ff5b1f;
      --type-display: 96px;
      --type-dek: 28px;
    }
    body { margin: 0; background: var(--bg); color: var(--fg); }
    .slide { width: 1920px; height: 1080px; padding: 120px; box-sizing: border-box; }
    /* ... */
  </style>
</head>
<body>
  <section class="slide">
    <p class="eyebrow">02 / The new SDK</p>
    <h1>Ship in five lines.</h1>
    <p class="dek">Our new client wraps the auth handshake so you don't have to.</p>
    <footer>Q2 Launch ยท Section 02</footer>
  </section>
</body>
</html>

Save this file. It's now your template. Every other slide in the deck will inherit those CSS variables and that layout vocabulary.

#Step 3: generate the rest of the slides against that template

Now you ask Codex to produce more slides that follow the same conventions. The trick is to keep the template in context and ask for one slide at a time, or two or three if they're closely related.

Using the same CSS variables and layout system as slide-02.html,
write slide-03.html. It's a "before / after" code comparison.
Left column: the old way, four lines of fetch + JSON parsing.
Right column: the new SDK, one line.
Use a monospace font for the code blocks.
Output the full file.

A few things help:

  • Paste the template file into the prompt every time you start a new section. Codex's memory of "the deck so far" is unreliable. Your file system is reliable.
  • When you change a CSS variable in one slide, decide if it's a global change. If yes, do a search-and-replace across all the files. If no, scope it locally.
  • If a slide gets weird, throw it away and regenerate. Don't argue with Codex about layout. It's faster to restart.

#Step 4: open the deck somewhere visual

Codex will get the structure right. It will not always get the *feel* right. Headlines that read fine in a code editor look cramped at 1920 wide. The accent color you specified looks orange in your terminal and looks pumpkin on a projector.

This is where a visual pass earns its keep. Open the HTML in a browser first. Put it full screen. Walk through the deck like you're actually presenting it.

If you're using a presentation editor that lets you edit HTML slides directly, this is the moment to move the generated slide source into that editor. In Variant, that means creating a deck and using the Code tab or an MCP workflow such as slide.replace from a supported agent to put the HTML into real slides. Once the deck is in the editor, you can:

  • Drag a headline two grid units to the left to fix the optical center.
  • Pick a new accent color from a color picker instead of editing a hex value six times.
  • Replace a placeholder image with a real screenshot.
  • Tweak a chart's axis labels without regenerating the slide.

The canvas and the code stay in sync. If you nudge a title on the canvas, the CSS updates. If you edit the CSS by hand, the canvas re-renders. That two-way binding is what keeps the deck editable instead of locked to whatever Codex emitted on its first try.

Codex-generated slide loaded in Variant with source visible
Codex-generated slide loaded in Variant with source visible

#Step 5: hand-edit, don't regenerate

This is the part most people miss when they use AI to make slides. If one word is wrong, fix the word. Don't regenerate the slide. Don't regenerate the deck.

Generic AI deck tools train you to think of the slide as a black box: you describe it, the model produces it, and if it's wrong you describe it again. That works for first drafts and falls apart for revisions. By the third "make the title smaller and move the chart up" you've lost everything else you liked about the slide.

Before and after source edit on a Codex-generated slide
Before and after source edit on a Codex-generated slide

Code-native slides flip that. The slide is just a file. You can:

  • Open the file and change the word.
  • Ask Codex (or any agent) to make a *targeted* edit: "in slide-05.html, change --accent to #3b82f6 and nothing else."
  • Use git to track every change and revert one without losing the others.

This is also where an agent-editable deck format starts to matter. If you're using Variant, you can point an MCP-capable agent at the deck and ask for edits at the slide level: edit slide 5, replace the chart on slide 8, duplicate slide 3 and change the headline. The agent edits HTML in place. You don't have to throw the deck away to fix a typo.

#Step 6: export

Once the deck looks right, you export. The format depends on where it's going:

  • Single-file HTML. Best for sharing a link, embedding in a docs site, or handing off to a teammate who'll keep editing. Everything is inline: styles, fonts, base64 images. One file, double-click to open.
  • PDF. Best for email attachments, printed handouts, or anywhere the recipient won't have a browser. Loses interactivity, keeps layout exact.
  • PPTX. Best when the recipient lives in PowerPoint or Keynote and wants to keep editing in their tool. Variant exports a real .pptx with text frames, not flattened images, so the slides remain editable downstream.
  • JSON. Best when another tool will consume the deck programmatically. The slide structure, content, and styles come through as data.

A typical handoff: I export to HTML for the team review (everyone has a browser, nobody has the same PowerPoint version), and to PPTX for the executive who's going to add their own slide at the end.

#A worked example: a 10-slide launch deck

Here's a concrete pass, start to finish, for a fictional SDK launch deck.

  1. Brief. Six lines, like the one above. Audience, goal, sections, tone, look, constraints.
  2. Template. One slide. Section heading layout, dark background, orange accent. Save as slide-02.html.
  3. Title slide. Ask Codex for slide-01.html, a centered title and subtitle on the same dark background. 90 seconds.
  4. Problem slide. A two-column slide: a chart on the left, three bullets on the right. Codex draws a placeholder bar chart in inline SVG. I'll replace it with a real chart later.
  5. What's new. Three feature cards in a row. Each card is the same component, different copy.
  6. Demo. A code snippet, syntax-highlighted with a small Prism include. I told Codex to use Prism specifically because I know it works as a single inline script.
  7. Before / after. The slide from earlier.
  8. Pricing. A three-column pricing card layout. Codex got the layout right and the prices wrong. I edited the prices by hand.
  9. FAQ. Two columns of question / answer pairs. Codex generated plausible questions; I rewrote two of them.
  10. CTA. Centered headline and a single link. The link is a real URL I typed in myself.

Total time: about 45 minutes. About 15 of those were Codex generating, 30 were me reading and tweaking. The deck shipped as a single HTML file plus a PPTX export for the salesperson who wanted to add a closing slide.

#What about a direct Codex MCP integration?

Honest answer: I haven't shipped a tested direct integration between Codex and Variant's MCP server, and I don't want to claim something I haven't run end to end. The Variant MCP server is built against the standard MCP transport, so any MCP-capable client should be able to talk to it. But Codex's MCP support has been moving, and I'd rather you use the workflow above than wire something fragile.

If you're already using Claude Code as your agent, the MCP path is well-trodden: point Claude Code at Variant's MCP server and it can create decks, edit slides, and export, all from inside your agent session. For Codex, the safe move today is the file-based workflow: generate HTML, review in a browser, move the good source into your editor, edit, export.

I'll update this post when there's a Codex MCP path I'd actually recommend.

#Limitations and tradeoffs

A few honest caveats:

  • Charts. Codex draws plausible-looking SVG charts, but the data is made up. Always replace the placeholder with a real chart, either by hand or by piping in real data and asking for a targeted regeneration.
  • Brand fonts. If your brand uses a custom font, Codex won't have it. You'll need to inline the font file or load it from your CDN. Specify this in the brief.
  • Dense layouts. Codex is fine with one or two columns. Three-column dashboards with mixed content tend to need hand layout. Use the canvas for these.
  • Animations. You can ask Codex for CSS transitions and they'll mostly work. Anything more complex (a JS-driven build sequence) is faster to write yourself than to prompt for.
  • Image generation. Codex doesn't generate images. Use a separate tool for hero images, then drop them into the slide.

None of these are blockers. They're the seams where you stop prompting and start editing. That's the point of keeping the slides in code: the seams are visible.

#Where Variant fits

If the file-based workflow above sounds appealing but the "open in a visual editor" step is the part that's missing for you, that's where Variant fits. It treats HTML/CSS slides as the working format, gives you a canvas and a code tab that stay in sync, and exports to PDF and PPTX when you need to leave the browser. There's an MCP server if you're working with Claude Code or another MCP client; for Codex, the file-based handoff in this post is the way to go today.

If you want to try it, take one Codex-generated slide and recreate or replace it in Variant, then see whether the canvas/code split makes cleanup easier. That's the test. Not a demo deck. A slide you actually need to fix.

#FAQ

Can Codex generate a whole 30-slide deck in one prompt? It can try, but the result will have layout drift, repeated content, and a couple of slides that broke halfway through. You'll spend more time fixing it than you saved. Generate a template, then generate slides in small batches that share the template's CSS.

What about Codex generating PPTX directly? Possible but fragile. PPTX is a zip of XML with strict schema rules, and one malformed tag corrupts the file. You're better off generating HTML, then exporting to PPTX from a tool that has a tested PPTX writer. Variant does this; so do a few headless HTML-to-PPTX libraries.

How do I keep brand consistency across slides Codex generates? Pull all your brand decisions into CSS custom properties at the top of the template: colors, type scale, spacing, accent. Then every slide that uses the template inherits them. To rebrand, change the variables in one place.

Can I use this workflow with another agent like Claude Code or Cursor? Yes. The HTML-first workflow is agent-agnostic. Claude Code has the additional benefit of working with Variant's MCP server directly, so you can skip the file handoff and have the agent create and edit the deck in place.

What if I want to start from a PowerPoint template instead of generating from scratch? Use the PowerPoint template as a visual reference, not as magic input. Pull out the concrete parts Codex can use: colors, fonts, slide dimensions, spacing rules, and a screenshot of one representative layout. Then ask Codex to build an HTML template that follows those rules. It won't be a perfect clone, but it will be editable.

How do I version-control a deck made this way? Commit the HTML files to git like any other code. Diffs are readable, blame works, and you can branch a deck for a "exec version" and a "internal version" without copy-pasting the whole thing.