How to Turn a Claude Artifact Into a Real Website With Its Own URL

Claude built you something in an artifact: a landing page, a mortgage calculator, a small game. It works in the chat panel, and now you want it at an address you can put in a bio, an invoice footer, or a client email. The official docs stop at a share link, and most of what ranks for this question was written by a tool that wants to sell you the answer.

I publish agent-generated pages most days, so here is the full map as of June 2026: Claude's own publish button and where it stops, free static hosting on your own domain, the paste-your-artifact tools, and a fourth route where the agent writes the page straight to a hosted workspace with no copy step at all. That last one is my product, and I will flag it clearly when we get there.

What Claude's publish button actually gives you

The fastest route is built in. Open the artifact, click Publish, and Claude generates a public link in seconds. Anyone with that link can open the page in a normal browser and use it, no Claude account required for plain HTML artifacts, and publishing is available on the Free, Pro, and Max plans. Team and Enterprise accounts work differently: artifacts can be shared inside the organization but cannot be published publicly.

There is more here than people assume. After publishing you can generate an embed snippet and whitelist which domains may iframe the artifact into another site. And if the artifact calls Claude at runtime, viewers sign in with their own account and the usage counts against their subscription, not yours.

For "look what I made," this is the right answer, and you can stop reading.

Where Claude's publish link stops

The link itself is the first limit. It lives on Anthropic's domain, you do not choose any part of it, and nothing in the official docs lets you point your own domain at it. The page also presents as a Claude artifact, including a customize path that forks it into the viewer's own Claude conversation, rather than as your website.

Data is the second limit. The supported way to persist anything is artifact storage: up to 20 MB per artifact, in personal or shared mode, available on Pro, Max, Team, and Enterprise, and it only starts working after the artifact is published. Free-plan artifacts have no supported way to keep data between visits. I cover the details in a separate guide on saving data from artifacts.

The third limit is sharper than it looks: once you unpublish an artifact, you can never publish that same one again, and unpublishing permanently deletes its stored data. Treat the publish link as a share, not as hosting.

Netlify Drop: your own domain in about five minutes

If you want a URL you control, take the code out of Claude. One tip first: ask Claude to produce the artifact as a single self-contained HTML file. React-flavored artifacts need wrapping or a build step before they run outside Claude's panel, a point the dev.to comparison of deploy methods makes too. Plain HTML runs anywhere.

Copy the artifact code, save it as index.html inside a folder, and drag that folder onto Netlify Drop. This is a documented first-class flow: "You can create a new site by dragging a project folder containing your site files (like .html files)". You get an HTTPS address on a netlify.app subdomain immediately, and custom domains with SSL are included on the free plan.

Updating means editing the file and dragging the folder again. Tolerable for a page you touch monthly, tedious for one you are still iterating on.

GitHub Pages: the version that lasts

For a page that should survive years, I would rather have it in git. Create a public repository, add the artifact as index.html, and enable Pages under the repo settings. GitHub Free includes Pages for public repositories, and custom domains are supported for both apex domains (A records) and subdomains (CNAME).

Setup is maybe ten minutes the first time. What you get for it is history: every change to the page is a commit, so when Claude regenerates the file next month you can diff the versions and roll a bad one back. The cost is the same manual loop as Netlify plus a little git.

Between the two, Netlify Drop wins on speed and GitHub Pages wins on durability. Both are free, both give you your own domain, and both treat your page as what it actually is: static HTML that any host can serve.

The paste-your-artifact micro-tools

There is now a small industry aimed at exactly this question: Repaint, static.app, ShareDuo, TinyCMS, Artifact Ninja, OneClickLive. The shape is consistent. You paste the artifact code into a box, the tool wraps whatever framework pieces Claude used, and you get a hosted URL in seconds. Artifact Ninja's Show HN thread is a good snapshot of the demand.

These tools are legitimate when you want zero terminal and zero git. The tradeoff is the business model. Free tiers tend to expire or stay on the tool's subdomain, and your own domain usually sits behind a subscription: OneClickLive's free deploys expire after seven days, with a 12 euro per month plan for permanence, and static.app reserves custom domains for paid plans. You are paying monthly to skip a one-time ten-minute setup, and you are betting the micro-tool outlives your page.

How the options compare

Ranked by effort, with what each gives back:

The first four share one assumption worth examining: that the artifact is finished when you deploy it.

The copy step is the real bottleneck

In practice the artifact is rarely finished. You deploy, open the page on your phone, notice the heading wraps badly, go back to Claude, regenerate, and copy again. Each round trip is small; across the life of a real page they compound into the reason so many artifact deployments stay at version one forever.

The single-file constraint bites too. Useful pages accrete: a second page, a shared stylesheet, a data file the page reads. The moment your page starts behaving like a small tool instead of a static document (a shift I wrote about in the leap from documents to tools), pasting one file at a time stops scaling. None of the routes above exactly fail here. They just leave you as the courier between the agent that writes the code and the server that hosts it.

Skip the copy step: have the agent write to hosting directly

The remaining route removes the copy step instead of speeding it up. If the agent can write files to hosted space over MCP, then "build me a page" and "put it online" become the same instruction: the agent writes index.html into a workspace that is already serving it, and iteration is just "fix the heading," with no paste in between. Multi-file sites stop being a special case.

Caipi is my product, and this is what it does. Agents (Claude, ChatGPT, anything that speaks MCP) write Markdown pages, HTML, dashboards, and small SQLite-backed apps into a private workspace at caipi.ai, and you publish individual pages at your own URL when they are ready. There is a live demo if you want to see the shape of it. The pattern is bigger than my implementation, though: any hosted filesystem an agent can write to gives you the same property.

Which option to pick

For showing a friend the game Claude just made, use the publish button and move on. For a page that represents you or a client, copy the code out: Netlify Drop for speed, GitHub Pages for history and years of shelf life. Reach for a micro-tool when the terminal is a dealbreaker and you accept the subscription. If you are iterating with an agent on something that keeps growing past one file, skip the copy step entirely.

Whatever you choose, ask Claude for self-contained HTML before you start. It is the one decision that keeps every later option open.

Claude's publish behavior, plan gates, and storage limits in this guide were checked against the official Claude, Netlify, and GitHub documentation in June 2026. These platforms move quickly, so reverify the gates if you are reading this much later.