Claude is surprisingly good at producing useful HTML artifacts: quick dashboards, landing page mockups, product one-pagers, data reports, UI prototypes, and internal tools.
The awkward part usually comes after the HTML is generated.
You want to send it to someone, but the artifact lives in a chat, a local file, or a temporary preview. Screenshots lose interactivity. Copying code into a message is hard to review. Asking someone to download a file and open it locally adds friction.
For many small HTML outputs, the missing step is simple:
Turn the generated HTML into a real browser URL.
This article walks through a practical workflow for sharing Claude HTML artifacts as live previews.
If you want a focused version of this workflow, I also wrote a short guide here: Share Claude HTML artifacts as a live URL.
When Claude generates HTML, you usually get one of three things:
These are not the same deployment target.
A single HTML file can often be published directly. A static folder can be hosted as-is if it already contains the final assets. A source project usually needs a build command first.
The most common mistake is trying to share the source project instead of the built artifact.
For example, this is usually not what you want to publish:
my-demo/
package.json
src/
node_modules/
vite.config.ts
This is much closer to what you want:
dist/
index.html
assets/
app.css
app.js
That distinction matters because a browser can load index.html
, CSS, JavaScript, images, and static assets. It cannot run your local build system for the viewer.
A good preview workflow for AI-generated HTML should be boring in the best possible way:
That workflow works especially well for:
If Claude generated one self-contained HTML file, the fastest path is to paste or upload the file and get a live URL.
This works best when the file includes everything it needs:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Revenue Dashboard Preview</title>
<style>
body {
font-family: system-ui, sans-serif;
margin: 2rem;
}
</style>
</head>
<body>
<h1>Revenue Dashboard</h1>
<p>This is a generated static preview.</p>
</body>
</html>
This is ideal for quick review loops because there is no repository, no DNS, no build pipeline, and no app server.
If you are using PreviewShip, the upload flow is built for this kind of artifact:
Publish AI-generated HTML online
If Claude Code or another local coding agent generated a file in your workspace, the command line can be faster than using a browser UI.
For example:
npx previewship deploy ./report.html
Or, if you want a machine-readable result for scripting:
npx previewship deploy ./report.html --json
A CLI-based workflow is useful when you repeatedly generate variations:
npx previewship deploy ./experiments/pricing-page-v3.html
npx previewship deploy ./reports/weekly-growth.html
npx previewship deploy ./demos/onboarding-flow.html
The important thing is that the deployed file or folder should already be browser-ready.
For a built frontend project, that usually means:
npm run build
npx previewship deploy ./dist
The exact output folder depends on your framework:
Vite -> dist/
Astro -> dist/
Next.js -> out/ if using static export
SvelteKit -> build/ depending on adapter
If you are working inside Claude Code, Cursor, or another agentic coding tool, you can also make publishing part of the agent workflow.
A typical prompt can be:
Build the static preview, deploy the browser-ready output, and give me the public URL.
This works best when the tool has a clear deployment command or MCP integration available.
For PreviewShip, the MCP docs are here:
That kind of setup is useful because the agent can:
You still need to be explicit about what should be deployed. If the agent built a Vite app, ask it to deploy dist/
, not the raw source directory.
Before sending the preview to someone else, check these details:
<title>
That last check is underrated. If it works in a private window, it is much more likely to work for the person receiving the link.
This live-preview workflow is not a replacement for production hosting.
It is best for artifacts that need fast review:
For long-lived production apps, use your normal deployment pipeline.
For throwaway or review-focused HTML, a lightweight preview URL is usually enough.
Claude can generate the first version of an HTML artifact quickly. The real productivity gain comes when the review loop is just as fast.
If the output can be opened as a URL, people can comment on the actual experience instead of debugging file sharing.
That small shift makes AI-generated HTML much easier to use in real work.