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.
The problem with local HTML artifacts
When Claude generates HTML, you usually get one of three things:
- A single self-contained HTML file
- A small static folder with CSS, JavaScript, and image assets
- A source project that needs to be built first, such as Vite, Next.js, Astro, or another frontend setup
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.
What a good preview workflow should do
A good preview workflow for AI-generated HTML should be boring in the best possible way:
- Take the exact artifact Claude generated or built
- Publish it to a public HTTPS URL
- Preserve linked CSS, JavaScript, images, and fonts
- Let reviewers open it without installing anything
- Make it easy to replace the preview when the artifact changes
That workflow works especially well for:
- AI-generated reports
- HTML prototypes
- Landing page drafts
- Client demos
- Small internal tools
- Static examples for docs
- UI states that are easier to review in a browser than in a screenshot
Option 1: Paste or upload the HTML
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
Option 2: Publish from the command line
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
Option 3: Let Claude Code publish the preview
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:
- Generate the HTML
- Build the static output if needed
- Deploy the result
- Return a URL for review
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.
A small checklist before sharing the URL
Before sending the preview to someone else, check these details:
- The page has a real
<title> - The layout works on desktop and mobile
- External images and fonts load correctly
- Buttons and links do not point to localhost
- The page does not expose private API keys or internal data
- The artifact is the built output, not the source project
- The preview URL opens in a private browser window
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.
When this workflow is better than a full deployment
This live-preview workflow is not a replacement for production hosting.
It is best for artifacts that need fast review:
- "Can you check this report?"
- "Does this landing page copy make sense?"
- "Is this generated UI close to what we want?"
- "Can the client open this without installing anything?"
- "Can I share this prototype in a Slack thread?"
For long-lived production apps, use your normal deployment pipeline.
For throwaway or review-focused HTML, a lightweight preview URL is usually enough.
Final thought
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.