How to Share Claude HTML Artifacts as a Live Preview URL

Neurobin — Thu, 25 Jun 2026 03:33:26 +0000

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:

PreviewShip MCP docs

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.

DEV Community: Neurobin