Prompt patterns for a single-file interactive chart or dashboard from AI (2026)

You ask an AI tool for "an interactive sales dashboard." Thirty seconds later you are looking at a clean grid of charts, a date filter, a metric toggle. It looks shippable. You download the file, send it to a stakeholder, they open it — and they see a white page with three empty rectangles where the charts should be.

Nothing is broken on your screen. That is the specific trap a chart sets. Most AI outputs fail in one place; a dashboard fails in two, and both are invisible from where you are standing. The library that draws the chart came from a CDN their corporate network blocks. The numbers came from a fetch() to your dev server that returns nothing from their browser. You did not ship a broken chart. You shipped a frame with no picture in it, and you had no way to see the picture was missing.

The fix is not a better model. It is five specific instructions in the prompt, given before the first generation — each one aimed at one of the two ways the picture goes missing.

Pattern 1 — Choose the rendering path on purpose

"Make me a chart" lets the AI pick how the chart gets drawn, and it almost always reaches for a CDN-loaded library, because that is the web-dev default. You want to make that choice yourself, because the right path depends on what the chart actually needs to do.

There are three, and they are not interchangeable:

• Inline SVG, no library. For static charts — a bar chart, a line, a donut that just sits there. The AI writes the SVG paths directly. Nothing to load, smallest possible file, renders on a plane.
• One inlined library. For interactive charts — hover tooltips, click-to-toggle series, animated transitions. You need a library, but exactly one, and its code lives inside the file.
• A server-backed app. For live data, saved filters, or anything per-user. This is not a single file, and this article is honest about that — see Pattern 4.

Name the path in the first sentence:

Build a single-file bar chart of this data using hand-written inline SVG — no charting library, no canvas, just SVG elements I can open directly in a browser.

That one clause removes the most common failure before it happens.

Pattern 2 — Inline the library, do not link it

When you do need interactivity, the default output links the library from a CDN: <script src="https://cdn.jsdelivr.net/npm/chart.js">. On your machine that resolves instantly. On a locked-down network, or on a flight, it is a blank chart and a console error nobody reads.

Use Chart.js for the interactive charts, but paste the full minified Chart.js source inline in a <script> block — do not link it from a CDN. The finished file must contain zero src="https://..." references. If the library is too large to inline, switch to hand-written SVG instead and tell me.

The escape clause matters. D3 and Plotly are heavy; if inlining one would bloat the file past what you want to send, you would rather the model fall back to SVG than quietly link a CDN. Compact libraries like Chart.js or uPlot inline cleanly for most dashboards.

Pattern 3 — Hardcode the data as a snapshot

This is the second invisible failure, and the one a chart is uniquely prone to: a chart with no data does not error, it just draws nothing. The AI loves to scaffold a fetch('/api/metrics') because that is how real dashboards get their numbers. Your file has no /api/metrics. On your screen the call may even resolve against a dev server you forgot was running — which is exactly why this one survives your own review and dies in the recipient's browser.

Hardcode all data as a single JSON constant named DATA at the top of the script. Every chart and table reads from DATA. No fetch calls, no API requests, no CSV loading, no external data of any kind. Paste my numbers in directly.

This turns the dashboard into a snapshot — true as of the moment you generated it. For a deliverable, that is usually exactly right: a quarterly report, a campaign recap, a pitch metric. To update it, you paste new numbers and regenerate. The constant at the top doubles as the one place anyone can correct a value by hand without reading the chart code — useful when a stakeholder spots a wrong number and you want to fix it in ten seconds.

If you genuinely need numbers that move on their own, you are not building a file anymore — you are building a live dashboard with a data source behind it, and Pattern 4 draws that line.

Pattern 4 — Keep interactivity browser-only, and name the boundary

Here is the honest part. A lot of "interactive" lives happily in one file, and a little of it does not.

Works in a single file, all browser-side:

• Date-range and category filters that slice the hardcoded DATA
• Metric toggles, tab switches, expandable rows
• Sortable, searchable tables
• Hover tooltips, drill-down by click, animated transitions

Does not fit in a single file:

• Data that refreshes from a live source
• Filters or annotations that persist for the next visitor
• Anything gated behind a login
• Writing back to a database

That second list needs a server. If your dashboard needs it, build it on a platform made for it — Vercel and Netlify both give you serverless routes and a database next to the page, and that is the right tool for a live, multi-user dashboard. Forcing it into one HTML file fights the format.

The prompt that keeps you on the right side of the line:

All interactivity runs in the browser against the hardcoded DATA constant — filters, toggles, sorting, tooltips. No server calls, no persistence, no login. If anything I asked for actually needs a backend, stop and tell me which feature it is instead of faking it.

That last sentence is the valuable one. It stops the model from shipping a filter that looks like it saves and silently forgets.

Pattern 5 — Make the model audit its own file

AI tools handle a verification pass well — it is a separate read, and they catch on the second look what they missed on the first.

Before finishing, scan the whole file once. Confirm: no https:// in any src or href, no fetch( or API calls, no external fonts, and that every chart reads from DATA. List anything you find and replace it inline. Then tell me the final file size.

The file-size line is a quiet tell. If an inlined-everything dashboard comes back at 4 KB, the data or the library did not actually make it in — which is the same blank-frame failure, caught early.

The combined prompt, scaling up

For a static chart, Patterns 1, 3, and 5 are enough. For a small dashboard, stack all five:

Build an interactive metrics dashboard as a single self-contained HTML file.

1. Inline SVG for static charts; for interactive charts use one library (Chart.js or uPlot), pasted inline — no CDN links.
2. All data as a JSON constant DATA at the top of the script. No fetch, no API.
3. Filters, toggles, sorting, and tooltips run entirely in the browser against DATA.
4. If any feature needs a backend, stop and name it instead of faking it.
5. Before finishing, scan for external URLs, fetch calls, and external fonts; replace any inline; report the final file size.

This carries essentially unchanged across Claude and ChatGPT canvas, v0, and the rest. Each produces a slightly different shape — v0 leans React, Claude leans conservative — but the single-file, inline-everything framing holds.

Once the file is genuinely self-contained, it is just an AI artifact you can open anywhere. Drop a dashboard at a private link and the viewer needs no account; the same applies to any interactive calculator or other one-file build you want to deliver instead of host on a public URL. The prompt that bundled everything at the start is what makes that delivery boring — in the good way.