Prompt patterns to ship portable, self-contained HTML from any AI tool (2026)

You ask Claude to build a one-page report. The output renders perfectly in the artifact panel. You download the file, email it to the client, they open it in their browser — half the chart components fail to load because their hotel Wi-Fi blocked the CDN, the Google Font fell back to Times New Roman, the data section reads "Loading..." because the fetch call to your dev environment 404s from their network.

The model did exactly what AI tools default to: built modular HTML using the standard web-dev conventions. Those conventions assume a development environment with internet and a backend. The deliverable lives somewhere else.

The fix isn't a different tool — it's a different prompt.

Modular HTML vs portable HTML

Two different shapes of the same output:

Modular HTML is what AI builders default to. CSS lives in a separate file or a CDN-loaded framework (Tailwind, Bootstrap). JavaScript pulls libraries from CDNs (unpkg, cdn.jsdelivr, esm.sh). Fonts load from Google. Images sit on a remote host. Data comes from a fetch call to an API. The page is small (a few KB of markup) and loads the rest at runtime.

This shape is correct for a project that will get deployed. The CDN cache is shared across visitors; the API is the source of truth; the modularity lets you update one piece without redeploying the whole site. Build-tool ecosystems are built around this assumption.

Portable HTML is one file with everything bundled. CSS as inline <style>. JavaScript as inline <script>. Fonts embedded via base64 or substituted with system stacks. Images base64-encoded. Data hardcoded as JSON at the top of the script. The file is larger (a few hundred KB to a few MB) and runs the same with no network connection.

This shape is correct for delivery — sending a file to one client, hosting at a private link, opening on a flight. The cost is file size; the win is "it just works wherever it lands."

The four prompt patterns

1. "Single file" — set the constraint upfront

The first sentence of the prompt sets the shape. Most AI tools default to modular unless told otherwise.

Build this as a single self-contained HTML file. One .html, no external files, no build step. The output should be one chunk of HTML I can save and open directly in a browser.

Across tools:

• Claude artifacts — the artifact panel already produces a single HTML block; this prompt prevents Claude from splitting into multiple files.
• v0 — without this, v0 defaults to React+Next.js multi-file output; with it, v0 produces a vanilla HTML page.
• Lovable / Cursor / Bolt — same effect; these tools lean toward multi-file project scaffolds and need the explicit single-file framing.

2. "Inline all assets" — name what counts

"Self-contained" is ambiguous to AI tools. Being specific about which externals to inline produces cleaner output than a vague "make it self-contained":

All CSS inline in a <style> block (no external stylesheets, no Tailwind CDN — if you need utility classes, generate the specific rules and inline them). All JavaScript inline in <script> blocks (no src="https://..."). All fonts using a system font stack (no Google Fonts links). All images base64-encoded inline (for small icons under 50KB) or use inline SVG for graphical elements.

The verbosity is the point — the model gets a concrete checklist instead of an abstract goal, and the output reflects each clause.

3. "Hardcode the data" — kill the fetch dependency

The hardest one to catch on review, easiest to specify upfront:

Hardcode all data as a JSON literal at the top of the script. No fetch calls, no API requests, no loading from external sources. If the page shows charts or tables, the source data should be visible at the top of the file as a constant the rest of the code reads from.

For a report or dashboard, this turns the page into a snapshot — the data is correct as of the moment of generation. Updates require a regenerate, which is usually the right shape for a deliverable (vs a live dashboard which is a different kind of artifact).

4. "Verify portable" — let the model check itself

Adding a final clause asking the model to audit its own output catches the cases where the model's first pass slipped:

Before finishing, scan the HTML once more. Confirm there are no https:// URLs in <script src>, <link href>, <img src>, or @import statements. Confirm no fetch( calls. Confirm no font loads from Google or other external hosts. If any of these are present, replace them with inline equivalents.

Most AI tools handle this well — the audit step is a separate pass, and the model catches the things it would have caught on its own if it slowed down.

Combined into one prompt

For the kind of one-shot generation that matches a client deliverable:

Build [the thing] as a single self-contained HTML file:

1. One .html file, no external files, no build step.
2. All CSS inline in a <style> block; no Tailwind CDN — generate the specific rules and inline them. No external stylesheets.
3. All JavaScript inline in <script> blocks; no src="https://...".
4. Fonts via system font stack only; no Google Fonts or other web fonts.
5. Images base64-encoded inline or as inline SVG; no external image hosts.
6. All data hardcoded as a JSON literal at the top of the script; no fetch, no API calls.

Before finishing, scan once more: no https:// URLs in any src/href, no fetch(, no external font loads. Replace any you find with inline equivalents.

This works essentially unchanged across Claude, ChatGPT, v0, Lovable, Cursor, Bolt. Each tool may produce slightly different output shapes (Claude tends to be more conservative, v0 more design-forward, Cursor more code-focused) but the portability comes through.

When modular output is what you want

These prompts shift toward portable; that's not always the right direction.

For projects that will get deployed, modular HTML is faster, smaller per visitor, and easier to maintain. The CDN cache pays off across thousands of visitors; the build step optimizes the bundle for production; the modularity supports team edits. AI tools default to modular for good reason.

The split:

• Delivery to a specific person — portable HTML, one file, private link. The portable prompt is the right starter.
• Deploy to a public URL — modular HTML, build step, deployment pipeline. The default AI prompt is the right starter.

Most workflows have both shapes. The portable prompt is one of the patterns in the kit, not the only pattern.

When the portable pass didn't catch everything

For Claude artifacts specifically, the retroactive self-contained checklist covers the five things that slip past even an explicit portable prompt — CDN scripts, Tailwind CDN, external fonts, external images, and fetch calls. The audit step in the prompt above catches most of them; the checklist is the second-pass safety net.

Once the file is genuinely portable, the delivery channel decision is its own question — private link for one specific receiver, public host for reach, attachment when you know the device.