"It works in my Claude artifact" is the new "works on my machine." The AI built the page in one prompt, the demo lands, and then someone asks for a link they can keep.
You can give them one, with a catch that arrived in September 2026. An artifact made in a chat since September 16 has Share: the link opens only for people signed in to Claude. Publish, the public URL anyone opens and uses without an account, is left for legacy artifacts made before that date.
What you handed over is a page on Anthropic's domain, inside Anthropic's frame. No address of your own, no second page, nothing running behind it, and by default the next chat you open builds a new artifact rather than updating that one. You gave away a link, not control. Enough to show someone your work, not enough to hand over a website.
What Share and Publish actually do
Claude creates an artifact when what it is producing is, in Anthropic's words, "significant and self-contained, typically over 15 lines." It starts private, in a panel beside the conversation, and Anthropic's help centre says everything you make is saved to the Artifacts tab in your sidebar. The broader guide to Claude Artifacts maps the regular, AI-powered, Claude Code and Cowork live versions of the term; this page stays with the ownership question.
Share is the action for current artifacts on every plan. You choose Can view, Commenter or Can edit, and send the link to anyone, invite people by email, or, on Team and Enterprise, open it to the organisation. The rule that matters here: "People without one can't open a shared artifact, even with the link." The one is a Claude account.
Publish survives only for legacy artifacts, on Free, Pro and Max. A published chat artifact is the exception to the account rule: "Anyone with the link can view and use it without a Claude account," which is exactly why that link felt like a website when you sent it. New legacy artifacts cannot be made, so for anything built today the link you send stops at the Claude sign-in. Publish and Share get used interchangeably in conversation. They are not the same setting.
Where the artifact actually lives
Two things worth separating, because the guides answering this question blur them.
Artifacts from a Claude conversation are the familiar ones: ask for a page, it appears in the panel, you press Share, or Publish on a legacy one. Sharing by link is available on the free plan as well as Pro, Max, Team and Enterprise.
Artifacts from Claude Code are a different feature with the same name.
Claude Code publishes a page from your session
to a URL like claude.ai/code/artifact/5fbea6f3-…, loaded from a sandboxed
*.claudeusercontent.com origin. That needs Pro, Max, Team or Enterprise, a session
signed in to a claude.ai account, and Anthropic's own API as the model provider, not
Bedrock, Vertex or Foundry.
What that link is and what it can hold is the guide's subject.
This page stays with what neither kind of artifact gives you: an address of your own.
Five things the artifact does not have
Its own address
No custom domain option. The link lives where Anthropic puts it, and every visitor reads Anthropic's name before yours. Anywhere else this is one DNS record, and what pointing your own domain involves is a short procedure, just not one that exists here.
A second page
An artifact is one self-contained page, and a React component artifact is under the same rule as plain HTML and CSS. Anthropic is precise about the consequence: "Relative links do not resolve, because nothing is deployed alongside the page." Multi-section artifacts use in-page anchors rather than separate files, so the moment the design needs an About page, the format is out.
Anything behind the page
The published page runs under a strict Content Security Policy that "blocks scripts,
stylesheets, fonts, and images loaded from any other host, along with fetch, XHR, and
WebSocket calls." Styles and scripts are inlined, images embedded. And nothing runs behind
it: the page "can't store data submitted through a form or authenticate viewers itself."
A limit of the format rather than a knock on Claude, because a plain static site cannot do those things either, including one published through Birta. A form that receives submissions needs a service behind it wherever the page is hosted. That is a property of static hosting.
A life outside the chat that made it
The one that surprises people. From the Claude Code documentation: "Without the URL, a new session always creates a new artifact rather than updating an existing one." Keep the link and you can point a new session at it. Lose it, and your next conversation builds a stranger. A thin version of editing a live site by re-prompting instead of redeploying, where the tool stays attached to the site rather than a chat.
Unpublishing a legacy artifact goes one way only: "Once you unpublish an artifact, you cannot publish that same artifact again," and doing so "permanently deletes all associated storage data."
An owner who is you
On Team and Enterprise plans an organisation Owner controls one External sharing toggle, and turning it off "blocks access through existing public links", every link already handed out, at once. Owners can also set a retention policy that deletes artifacts automatically.
None of this is Anthropic behaving badly. It is what being a guest in somebody else's product looks like.
- The address. Anthropic's domain, fixed. Against: your own domain, once you point it.
- Pages. Exactly one. Against: as many as the site needs.
- Changing it. Ask Claude, if you still have the URL. Against: ask your agent, and the previous version is still there.
- Who can switch it off. You, an organisation Owner, or a retention policy. Against: you.
- Undoing a mistake. Unpublishing a legacy artifact is permanent. Against: roll back to a recent published version.
- What a visitor needs. A Claude account for a shared artifact; nothing only for a published legacy one. Against: nothing.
When the artifact is exactly the right answer
Most pages competing for this question want the answer to be "never." It is not.
Anthropic's own framing is the useful one: an artifact is "a capture of work, not an application." Judged as that it is very good, and frequently better than a website:
- walking a reviewer through a change, with notes beside the relevant lines;
- laying four versions of a layout side by side so somebody can pick one;
- a dashboard built from data the session already had;
- a page with sliders on it, so you can feel a value instead of arguing about it;
- anything you will not maintain past Thursday.
For those, a real site is overhead. You would be buying a domain to host a conversation.
The artifact stops being the right answer at a point that is not technical: when somebody other than you starts depending on the thing being there tomorrow.
What "make it a real website" actually means
Underneath, the artifact is HTML with its CSS and JavaScript inlined, so getting it out is
not the hard part: read the code and copy it. Claude Code is stricter about the shape than
the chat panel, with the published file limited to .html, .htm or .md and the
rendered page under 16 MiB.
What changes is what you are holding afterwards. It stops being a page inside an interface and becomes a folder of files: an HTML file at the root, everything it references, and a structure that has to stay intact. That folder needs somewhere to live, an address, and a way to be changed later without being rebuilt. Three separate problems, and the mechanics of solving them are a question of their own.
Plenty of routes exist: a publishing service, Netlify, GitHub Pages, a server you rent. For one page that one person has to open today, the shortest is to share the HTML file as a link: paste the copied code into Publish HTML and send the address, which opens for 24 hours. The point here is narrower: the step exists, and pressing Share or Publish is not it.
Nor is this only Claude. Gemini Canvas has the same shape: the code sits in a Code view and the share link is an app rather than a page, so publishing a Canvas build starts by copying the HTML out. OpenAI took the other route and hosts the result itself, which raises a different question: what happens to the site if you stop paying for the assistant.
One check first. If what you built needs a database, user accounts or server-side code, moving it to a static host solves nothing. Decide whether you built a site or an application first.
Where Birta fits
Birta is the narrow version of that step. From the same Claude conversation that built the artifact, the walkthrough for connecting Claude and publishing has the exact steps.
The agent that holds your finished files publishes them to a live HTTPS address, and how the connection works is an open standard your tool most likely already speaks. The last ten published versions are kept, so a wrong change rolls back rather than being rebuilt. Images and fonts travel with the site. Point your own domain at it and visitors see your name in the address.
Where Birta stops is where the artifact stops: static sites only. No database, no server-side code, no application logic. And if it seems odd that publishing a finished page is a product at all, that is a fair question with a longer answer.
Take the page out of the chat and give it an address
Paste the page into Birta's chat and its agent publishes it at an address your own domain can point to. Or connect Claude and publish from the conversation you already have.