Anthropic's docs are explicit: on Free, Pro and Max, publishing makes an artifact publicly available to anyone with the link. Org-only sharing is a Team and Enterprise feature. Here's what that means if you're an individual sending work to one named client.
You built something good in Claude. A pricing model, an interactive brief, a small tool that answers the exact question your client keeps asking. It's finished.
You want to send it to one person.
Open the sharing options on Pro or Max and the choice is narrower than you'd expect. Anthropic's help centre is direct about it:
Publishing (Free, Pro, Max): Makes your artifact publicly available. Anyone with the link can view and interact with it.
Organisation-scoped sharing — described as making the artifact available within your organisation only, with viewers signed into a Team or Enterprise account — is documented against those plans, not individual ones.
So the shape is: everyone, or nobody. There's no "this one client."
It's tempting to read a missing option as a gap someone forgot. This one has a reason, and understanding it saves you from waiting for a fix.
Organisation-scoped sharing works by checking whether a viewer belongs to your organisation. That requires an organisation — a membership list, an identity provider, an admin who decides who's in it. Team and Enterprise have all that. An individual Pro account has none of it, which means there's no set to check membership against.
So the platform offers what it can model: the artifact is inside your account, or it's on the open internet. Both are coherent. The case that falls between them — one specific person, who has no relationship with your account and never will — is the one a workspace product has the hardest time expressing, because that person is by definition not in any workspace.
If this feels familiar, it's the same shape as ChatGPT Sites, where the access levels stop at your workspace boundary. Two different products, arriving at the same edge, for the same structural reason.
The natural instinct is to publish, send the link, then unpublish once they've looked. Worth reading the documented behaviour first, because it doesn't work like a toggle:
Once you unpublish an artifact, you cannot publish that same artifact again.
And if the artifact used persistent storage, Anthropic documents that unpublishing permanently deletes the associated storage data, both personal and shared.
That's a one-way door, and it's a strange one to walk through by accident while trying to tidy up after a client review. We've written about what unpublishing actually does and why republishing isn't available separately — the short version is that "publish now, retract later" is not a privacy strategy you can lean on.
Export the artifact as one self-contained HTML file, drop it in, and get an unguessable no-index link with a password and an expiry if you want them. The viewer signs into nothing.
The sharing constraint applies to the artifact as a platform object. It doesn't apply to the work.
Ask Claude for the finished thing as one self-contained HTML file — all CSS and JavaScript inlined, no external dependencies it can't reach. The prompt can be as blunt as: "rewrite this as a single self-contained HTML file with all CSS and JavaScript inlined." What comes back is the same interactive page, in a form that isn't governed by anyone's sharing model.
From there it's an ordinary file, and you choose the access rules: who can open it, whether it needs a password, when it stops working, whether search engines can see it. That's a mundane set of choices, which is the point — the difficulty was never technical, it was that the decision wasn't yours to make while the work lived inside the platform.
The mechanics of the export, and how the same flow works from ChatGPT's canvas, are covered in privately sharing a Claude or ChatGPT artifact with a client.
Two honest limits.
If the artifact needs a backend, it needs a backend. Anything calling a server, using connector access, or relying on persistent storage tied to the artifact will not survive being turned into a static file. That's not a hosting problem you can shop around — build it as an app and deploy it as one, on Vercel or Netlify or wherever your stack lives.
If your reviewers are all inside a Team or Enterprise org, use the org sharing. It's the right tool: viewers are authenticated, access follows your membership list, and you don't have to think about link hygiene at all. This whole article is about the case where the person you're sending to isn't in that list and isn't going to be.
For everything else — a consultant sending a client a model, a designer sending a stakeholder a prototype, anyone whose reviewer will never be a member of anything — the fix is to stop asking the platform for a permission it doesn't have a concept for, and hand over a file instead.
Sharing a chat creates a snapshot anyone with the link can open. Unsharing disables that link. Neither of those is the same as 'not indexable', and the difference caught a lot of careful people in July 2026. Here's the mechanism, where to check your own shares, and when you need noindex to be a property of the link itself.
Two ways to put a password on a static page without running a backend — client-side encryption you set up yourself, or a hosted gate you don't. What each actually protects, and which fits a page you're handing to one person.
A short-lived link reads as a feature for one-off reviews and a bug for permanent references. The shape of the engagement decides which one the file needs.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.