Claude artifacts hosting

How to host a Claude artifact on your own domain

Three steps. The first two happen on this page and touch nothing but your browser; the third is two commands that your agent can also run for you, in the same session that made the artifact.

1. Get the file. Copy the artifact code out of the chat, or use the download option in the artifact panel, and paste or drop it here. What you want is one complete HTML document — if what you have is a React component, ask for a single-file HTML version.
2. See what does not travel. The frame renders the file outside the canvas, so CDN scripts prove themselves and canvas-only calls fail visibly. The notes name each one by line: a window.claude call, a missing viewport, an http image that a secure host will drop.
3. Publish it. Save it into a folder as index.html, take a free handle with clize claim, and deploy the folder with clize deploy. The result is an HTTPS URL on a name you control, which you can point at your own domain whenever you want.

An artifact is one HTML file — unless it is not HTML at all

Everything the canvas shows you is either a self-contained HTML document or a React component, and only the first kind is a thing a browser can open. A single-file artifact carries its own doctype, head, styles and scripts, so hosting it is genuinely just moving the bytes: paste it above, see it render outside Claude, deploy the folder. A React artifact is a module — it starts with an import or an export default — and a browser has nothing to do with a module on its own. The checker tells the two apart on the first line rather than leaving you with a blank frame.

If you have the second kind, the fastest fix is to ask for the first: request a single-file HTML version of the same thing in the chat, and paste that. The alternative is to build the shell yourself — a document, React and ReactDOM from a CDN, and JSX either compiled ahead of time or rewritten as React.createElement calls — which is real work for a page you wanted in one step.

What Claude’s own sharing gives you, and what it does not

Publishing an artifact inside Claude is a real option and is worth knowing precisely, because the reasons to host it yourself are not the ones people usually assume. According to Anthropic's help centre, checked on 4 September 2026: someone without a Claude account can view and interact with any published artifact without signing up, and is prompted to sign up only for advanced features such as AI-powered capabilities. Artifacts created on Team or Enterprise accounts can only be shared inside that organisation and cannot be published publicly. The Remix button no longer exists; copying the code into a new chat replaces it.

So the honest comparison is not "they make your visitors sign in". It is about whose page it is. A published artifact lives at a claude.ai address, inside Claude's own chrome, on Claude's release schedule; personal plans can also embed it elsewhere, but the artifact still runs from their side. You cannot put it on tools.yourdomain.com, you cannot give it your own <title> and social card in search results, you cannot add analytics or a redirect, and if your account is on a Team or Enterprise plan you cannot publish it to the outside world at all. Hosting the file yourself is how you get an address that is yours — and it costs nothing.

Do the React and Tailwind CDN scripts still work once you host it?

Yes — and you can verify it in the frame above rather than taking anyone's word for it, because that frame is not inside Claude either. A <script src="https://cdnjs.cloudflare.com/…"> or <script src="https://cdn.tailwindcss.com"> is an ordinary cross-origin script tag; it does not need permission from the page's own host, so React, ReactDOM, Chart.js, Three.js and the rest keep loading from wherever they loaded before. Load the example above and you are watching React render from a CDN, outside Claude, right now.

Four things do change, and they are the ones worth knowing before you publish:

The first two are notes; the third is a blocker and the checker marks it as one. If a feature genuinely needs a model behind it, the honest options are your own endpoint with your own key, or leaving that feature in the chat where it already works.

Publishing without leaving the session that made it

The file was produced by an agent, so the publishing can be too. Clize is a CLI and MCP server that the same session can call, which means the whole trip from "here is your artifact" to "here is your link" happens in one conversation, with no browser tab and no account anywhere else:

$ npm i -g @clize/clize && clize install
      $ clize login
      
      $ clize claim splitbill
      ✓ splitbill.clize.app is yours; the placeholder site is in place.
      
      $ clize deploy ./artifact --domain splitbill.clize.app
      {
        "host": "splitbill.clize.app",
        "url": "https://splitbill.clize.app",
        "files": 1,
        "notFound": "spa (auto)"
      }

clize install wires the same commands into Claude Code, Codex and any agent that reads skills or MCP, so you can also just ask for it in words. The deploy takes a folder, so save the artifact into one as index.html first — the mechanics of that, and the pre-flight for hand-written files, are on put an HTML file online free. To swap the free handle for a name you own, register or import it with Agent Domains and deploy to that instead; the files do not change. And if you would rather look before you publish, the HTML viewer renders the same file at phone and tablet widths.

$ npm i -g @clize/clize && clize install
$ clize claim yourname
$ clize deploy ./artifact --domain yourname.clize.app