A Claude artifact looks self-contained inside the chat and often isn't. The five things that quietly stay external — CDN scripts, Tailwind, fonts, images, fetch calls — and how to inline each.
You download the Claude artifact. The file size is reasonable — 18 KB, maybe 40. You email it to the client. The client opens it on their laptop, on hotel Wi-Fi, and the page renders blank for ten seconds before half the styling appears.
What happened: the file referenced three CDN URLs that were either slow, blocked by a corporate proxy, or rate-limited. The artifact was self-contained in Claude's chat because Claude's chat loaded the CDNs. On the client's machine, those externals are a different network path.
The fix is mechanical. Once you've done it twice, the third time takes a single prompt back to Claude.
When Claude builds an artifact, the model has a few reasonable defaults that all assume an internet-connected, low-friction environment. Five of them are worth checking on every export.
The most common: a <script src="https://cdn.jsdelivr.net/..."> or unpkg.com/... line near the top of the file. Loads a charting library, a UI framework, a date picker.
In Claude's chat, the CDN loads fast and reliably. On the client's machine, the load depends on:
The fix is to inline the library — paste the actual library code into a <script> block. For a 30 KB charting library, the file grows by 30 KB; for a 200 KB dependency, that's the cost of portability.
Tailwind CDN (<script src="https://cdn.tailwindcss.com">) is convenient and not built for production use. It generates the utility classes at runtime in the browser, which means:
The portable fix is to compile Tailwind to a static CSS file and inline it. The compile step is one Tailwind CLI command:
npx tailwindcss -i input.css -o output.css --content "./artifact.html"
That produces a small CSS file (a few KB after purge) with only the classes the artifact uses. Inline that into a <style> block, remove the CDN script, the file is portable.
For a simpler path, ask Claude: rewrite this with the Tailwind classes converted to inline styles or a static CSS block, no Tailwind CDN. The output is verbose but bulletproof.
A <link rel="stylesheet" href="https://fonts.googleapis.com/..."> line at the top adds a font from Google Fonts. The artifact looks right in Claude's chat. On the client's machine, the font request goes to Google; if the network blocks it (China, some corporate networks), the page falls back to a system font and the layout breaks.
Three options, in order of robustness:
-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif — works everywhere, no external request, fonts adapt to the OS.@font-face rule. Adds 30–80 KB but the font is guaranteed.The artifact might use <img src="https://..."> pointing at an image host (Unsplash, Imgur, the user's own server). Same fragility as the font case: works when the host responds, breaks when it doesn't.
For small images (icons, logos, illustrations under 50 KB), base64-encode and embed inline:
<img src="data:image/png;base64,iVBORw0KGgo..." />
For larger images, either accept the external dependency (and document it), or bundle them as a sibling file the client has to keep alongside the HTML — at which point the portability win is mostly gone.
For pure-icon needs, inline SVG is the cleanest path: the icon is a few hundred bytes of inline markup, no network request, scales perfectly.
This one isn't fixable by inlining — if the artifact uses fetch('/api/data') to load data at runtime, that endpoint has to be live wherever the file opens. Three ways to handle:
For most Claude artifacts that are meant to be sent to a client, the snapshot path is the right shape. The client doesn't want a live API they have to authenticate against; they want the analysis as of last Friday.
If the data comes through a Claude connector rather than a plain fetch, the snapshot path isn't just preferable — it's the only one that travels. A connector-backed artifact can't be shared to a public link on any plan, so the export decision is worth making before you build the page, not after.
Once the artifact is self-contained, drop the HTML at a private link in under 60 seconds — no card, no account, 7-day self-destruct. Useful for testing the file actually renders correctly on a network other than your own.
For most artifacts, the entire fix is a single follow-up prompt back to Claude:
Rewrite this artifact as a single self-contained HTML file. No external CDN scripts, no Tailwind CDN — replace with inline styles or a static CSS block. No external font imports — use a system font stack. No external image URLs — base64-embed any images under 50 KB. No fetch calls that require a live backend — hard-code any data the artifact uses. The output should be one HTML file that opens correctly with no network connection.
Claude handles this cleanly most of the time. The output is verbose (especially after the Tailwind inline conversion) but reliable. For artifacts that genuinely need a backend, Claude will flag it and ask whether to snapshot the data — accept the snapshot and the file becomes portable.
Not every artifact should be inlined to be portable. The case where the live version is the point:
For these, the artifact stays online and the delivery channel is a hosted URL — the AI builder's own deployment, a private link to a deployed version, or a screen-share session. The export-to-self-contained path is for the case where the deliverable should land as a one-time file.
Once the HTML is self-contained, the hosting question is the same channel decision as for any AI artifact — public host for reach, private link for delivery to a specific audience, attachment when the recipient is expecting it on a device you know.
For most consultant, freelance, and agency use cases — where the deliverable is for one client and not meant to be public — a private-link host fits. Drop the inlined HTML, get an unguessable URL, send the link. The export work pays off the moment the client opens the file on a network you haven't tested and the page renders cleanly anyway.
Solo plan ($4.99/mo) makes the link permanent — useful when the artifact is meant to live in the client's inbox as ongoing reference, not a 7-day window. Studio plan adds custom domain so the URL is on the team's own subdomain.
For an artifact that you've already taken through the inlining pass once, the next ones go faster. Three checks before sending:
https:// and fetch( — any hit should be deliberate.)If all three pass, the artifact is portable. From there, the delivery channel decision is its own question.
Portable isn't the same as finished, though. Artifacts tend to arrive structurally correct and a little flat, and a few animation prompts close most of that gap before the client ever sees it — worth doing before the export, since the polish pass is easier in the tool than in the file.
The attachment arrived, nothing was blocked, and your recipient sees markup instead of the page. That's three different email failures people keep merging into one. Here's which one you hit, and why the fix isn't a different attachment.
Upload an .html file to Drive, open it, and you get a wall of markup instead of the page. Nothing is broken — Drive is doing exactly what a filing cabinet does. Here's the mechanism, the workarounds people try, and what actually renders it.
Email providers cap attachments around 20-25MB. The fix when the file is bigger isn't to compress harder — it's to send the URL instead.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.