Export AI-Generated Slides as One HTML File
How single-file HTML export works for AI-generated slides, what gets embedded, how to test offline, where to host it, and what tradeoffs to expect.
Author: Variant Team. Variant is built by a small team working on HTML-native presentation tools, MCP workflows, and agent-editable decks.
Short answer: export the deck as a self-contained HTML file when you want the slides to open anywhere a browser exists. The file can carry the markup, styles, fonts, images, and speaker-friendly behavior without requiring a hosted editor.
That makes HTML export useful for AI-generated decks because the source stays inspectable until the moment you ship. You can let an agent build the first version, fix the parts that need taste, then hand off one portable file instead of a folder of dependencies.
This guide covers what gets embedded, how to test offline, when to host the result, and what can still go wrong. You can open the working sample here: download the single-file HTML export deck.
#Quick answer
- Export the deck as one self-contained
.htmlfile. - Confirm CSS, fonts, images, slide navigation, and small scripts are bundled into that file.
- Test it offline before sending it.
- Use HTML for browser-native sharing and hosting, PDF for fixed review, PPTX for PowerPoint handoff, and JSON for programmatic workflows.
- Keep editing in the source deck, then re-export when the deck changes.
#What "single file HTML" actually means
A single-file HTML presentation is one .html document that boots a working slide deck when you double-click it. No assets/ folder next to it. No external script tags pointing at a CDN. No font that quietly falls back to Times New Roman because the WiFi dropped.
To get there, the export has to inline a few categories of stuff:
- CSS. All stylesheets become
<style>blocks in the head, including any utility classes the slides use. - Images. PNG, JPG, SVG, and WebP get base64-encoded into
data:URIs and dropped in place ofsrcattributes. SVGs can also be inlined as raw markup, which is sometimes smaller. - Fonts. Web fonts are pulled, base64-encoded, and embedded inside
@font-facerules. This is the part most "export to HTML" tools quietly skip. - JavaScript. Slide navigation, key handlers, transitions, any small interactive bits — all inlined as
<script>tags. No<script src="...">pointing somewhere on the internet. - Slide structure. Each slide is a section in the document, usually with a CSS-driven layout that scales to the viewport.
What stays out (or should): hosted video, large analytics SDKs, and anything that genuinely needs the network (live API calls, embedded iframes from third parties). More on that later.
The result is one file, often somewhere between 500 KB and 8 MB depending on how image-heavy your deck is. You can attach it to an email. You can put it on S3 with a public URL. You can throw it on a thumb drive. It just works.
#Why one file matters for AI-generated decks
When you generate a deck with an AI agent, you usually iterate. A lot. The agent edits a slide, you tweak a headline by hand, you ask it to redo the chart, you paste in a new screenshot. Each round of that produces a new state of the deck.
If the export format is a folder of files with relative paths, every iteration is a packaging problem. You zip it, you unzip it on the other end, the relative paths break, the fonts don't load on someone else's machine. Plus you can't really email a folder.
A single HTML file collapses that into one artifact. The "current state of the deck" is one file. You can:
- Drop it in Slack and the recipient opens it instantly in their browser.
- Commit it to a repo as a versioned snapshot.
- Diff two versions of the same deck (it's just text and base64, which
git diffhandles, even if the diffs aren't pretty). - Hand it to a non-technical reviewer who has zero tools installed beyond a browser.
For AI-coded decks specifically, this matters more, because the source format is already HTML and CSS. The export isn't a translation step; it's mostly a bundling step. There's no "AI made a slide, then we converted it into PowerPoint, then we exported it to HTML, then we opened it in a browser" chain of conversions where each step quietly mangles something.
#The Variant workflow
Here's the path most people take.
1. Generate or build the deck. Either prompt Variant ("twelve-slide deck on Q2 product roadmap"), generate it from your Claude Code session over MCP, or start from a blank deck and build slides yourself. Each slide is real HTML and CSS the whole way through.
2. Refine on the canvas, edit code when useful. Move things around visually, fix wording inline, tweak a chart. If you want to do something the canvas doesn't expose easily, flip to the code tab and edit the HTML/CSS directly. Canvas and code stay in sync, so you don't have to pick a side.
3. Export. Open the export menu, choose "HTML (single file)", and download. That's the whole thing.
If you're driving Variant from Claude Code over MCP, the equivalent is asking the agent to export. The MCP exposes a deck.export tool that takes a deckId and a format. Something like:
You: Export the current deck as a single HTML file and save it to ~/Desktop/q2-roadmap.html.
Claude: [calls deck.export with format: "html"]
[saves the returned file to disk]For a fully scripted flow (CI, a daily report, an agent that ships decks to stakeholders), the MCP config looks like this:
{
"mcpServers": {
"variant": {
"transport": "http",
"url": "https://app.variant.art/mcp",
"headers": {
"Authorization": "Bearer ss_..."
}
}
}
}Then the agent can list decks, pick the right one, export it, and email it (or drop it in S3, or commit it to a repo). The HTML output is the same whether you click Export in the UI or call the tool.
#How to test that "self-contained" is actually self-contained
This is the part most people skip and then regret. A file can claim to be self-contained and still secretly hit the network for a font or a script. Here's a five-minute test that catches almost everything.
1. Open it offline. Disconnect from WiFi (or open it in a browser profile with the network disabled via DevTools). If anything looks wrong — missing font, broken layout, blank image — you've found a leak.
2. Watch the Network tab. Open DevTools, go to the Network tab, hard-reload the file. The only request should be the HTML file itself, and maybe the favicon. If you see requests to fonts.googleapis.com, cdn.jsdelivr.net, or any image host, something didn't get inlined.
3. Try it on a different machine. Especially one that doesn't have your fonts installed. This catches the "Helvetica Neue is on every Mac, but not on your CFO's Windows laptop" bug.
4. Test the navigation. Click through every slide. Try arrow keys. Try fullscreen (usually F or Esc to exit). If you have any animations or transitions, watch them once.
5. Print preview. This is a sneaky-good test. Print preview surfaces a lot of CSS bugs that don't show up in normal viewing — odd page breaks, content getting cut off, fonts substituting. If your deck might also get printed or PDF'd from the browser, this matters.
If anything fails: in Variant, the export pulls from the same source as the canvas, so a "missing on export" issue is usually a "this asset wasn't really uploaded, just linked" problem. Check the deck's asset list, re-upload anything that's still pointing at an external URL, and re-export.
#HTML vs PDF vs PPTX vs JSON: when to use which
Variant exports to four formats. They're not interchangeable.
HTML (single file) is the right default for sharing. It preserves your real layout, your fonts, your animations, and looks the same on every device. It's the only format that keeps interactive elements working. The downside: some corporate environments are nervous about random .html attachments, and not everyone knows to open it in a browser.
PDF is the right pick for archive, contracts, board packets, anything that needs to be printable and forever. It loses interactivity and any motion. Animations collapse to whatever the final frame looks like. Fonts get embedded automatically by the PDF spec. Use it when the deck needs to be a frozen artifact.
PPTX is for the stakeholder who lives in PowerPoint and is going to want to nudge a logo two pixels to the left. The conversion is reasonably faithful, but it's a translation, not a copy: complex CSS layouts get approximated, and some web-only effects don't survive. If your deck is going to be edited in PowerPoint after export, build with that constraint in mind from the start.
JSON is for programmatic use. It's the deck's source data — slides, layout, content, references to assets. Use it if you want to version-control a deck, diff it meaningfully, generate variants programmatically, or hand it to another tool. It's not for humans to read in a meeting.
For most "send this to someone" cases, HTML is the right choice. For "the legal team needs to file this", PDF. For "a teammate needs to make last-mile edits in PowerPoint", PPTX. For "I'm building a tool around this", JSON.
#Hosting options for a single-file deck
Once you have the HTML file, you have a lot of choices.
- Email attachment. Works if it's under your provider's attachment limit. Most decks fit; image-heavy ones might not.
- Static hosts. S3 with a public URL, Cloudflare R2, GitHub Pages, Netlify, Vercel — drop the file, get a URL, share it. Set the
Content-Typetotext/htmland you're done. - Slack / Notion / Linear. Upload the file. Slack will preview it (sort of), Notion treats it as a download. None of these render the deck inline, so the recipient downloads and opens.
- Internal wiki. Same story. Attach the file, link to it.
- Self-host. Put it behind your own auth if it's sensitive. Single file, single route, easy.
One trick worth knowing: if you host the file at a URL, you can append #5 or whatever slide-anchor convention your deck uses to deep-link to a specific slide. Useful when you're sending someone "just look at slide 12" and don't want them clicking through eleven slides first.
#What doesn't fit in one file (and what to do about it)
Self-contained doesn't mean unlimited. A few things genuinely don't belong inlined:
- Hosted video. Embedding a 200 MB MP4 as base64 turns your "single file" into a single 270 MB file. Better to host the video separately and embed a
<video>tag pointing at a URL — accept that your deck now needs the network for video to play. - Live data. If a chart updates from an API, the chart freezes the moment you export. Either pre-render a snapshot into the export or accept that the live version only works in the canvas.
- Third-party iframes. Anything embedded from another origin (Figma frames, YouTube, Loom) is a network dependency by definition. Keep them, but know what breaks offline.
- Analytics. Don't embed tracking scripts in a deck you're sending out. They probably won't load anyway, and you don't want to be the person whose deck phones home from someone else's laptop.
For most decks, none of this matters. For media-heavy decks, the right pattern is "HTML for the deck, separate URL for the heavy media."
#Limitations to know about
Worth being honest about.
- File size grows fast with high-res images. Consider compressing images to ~1600px wide before uploading; you almost never need more for slide rendering.
- Custom fonts add real weight. A typical web font is 50-200 KB per weight; if you have four weights of two families, that's a megabyte of just font data.
- Some browser extensions interfere with locally-opened HTML files. If a deck looks weird in someone's browser, ask them to open it in incognito.
- Print/PDF rendering of an HTML deck depends on browser print CSS, which is its own quirky world. If print fidelity matters, export to PDF directly from Variant rather than printing the HTML.
#A note on editability
One thing the HTML export does that PDF and PPTX can't: you can open the file in a text editor, find a typo, fix it, save, and reopen. It's not the most pleasant editing surface — base64 image data is everywhere — but for a one-character fix five minutes before a meeting, it's fine.
For real edits, take the deck back into Variant (or ask the agent to make the change) and re-export. The point of generating slides with AI is that you're never locked out of the source. You can always go back, edit a single slide, and ship a new version. Don't regenerate the whole deck to fix one bullet.
#A useful test
If you want to see what a Variant export actually looks like, make a small deck, click Export, pick HTML, and open the file with your network turned off. If you're already in Claude Code, point the MCP server at https://app.variant.art/mcp and ask it to create and export a short deck.
Then inspect the file. Search for a headline. Open it in a browser. Send it to yourself. The whole point of a single-file HTML export is that the boring parts should be boring.
#Related reading
#FAQ
How big does a typical single-file HTML deck end up? Most decks land between 500 KB and 5 MB. Image-heavy ones with embedded fonts can hit 10 MB or more. If yours is bigger than that, the culprit is almost always uncompressed images or several font weights you're not really using.
Will my deck look identical on someone else's machine? Close to it, yes. The major variables are screen size and browser. Layouts are designed to scale, so a 13" laptop and a 27" monitor both render reasonably. Across browsers (Chrome, Safari, Firefox, Edge), differences are usually subtle — a 1px nudge here, a font-rendering quirk there.
Can I edit the HTML file directly after export? You can, and it'll work for small fixes. But the file is optimized for delivery, not editing — base64 blobs make it ugly to scroll through. For real changes, edit in Variant and re-export.
Does the exported HTML need an internet connection to display? No. That's the whole point. Open it on a plane, in a basement, on a conference WiFi that just died. As long as you haven't embedded external video or third-party iframes, the deck is fully offline.
How does HTML export compare to PDF for sharing? HTML preserves layout, fonts, and any motion or interactivity. PDF freezes everything but is universally readable in any reader. If your deck is mostly static text and you need archive/print fidelity, PDF. If it's visually rich or interactive, HTML.
Can I export from Claude Code without opening the Variant UI? Yes. With the Variant MCP configured, ask Claude Code to export a deck and it calls deck.export, returning the file. You can script this for CI, scheduled reports, or any agent workflow.