# Claude Artifacts Explained: What They Are and How to Use Them

> Claude Artifacts turn Claude's output into live, shareable pages. What they are, the exact sandbox limits measured in August 2026, and why a live artifact can never be your source of truth.

Clawnify Resources · https://www.clawnify.com/resources/claude-artifacts-explained · 2026-08-17

## What Claude Artifacts are, and the sandbox they run in
Claude Artifacts are standalone documents, apps and web pages that Claude creates in a panel beside the conversation, rather than as text inside it. Ask for a dashboard, a calculator, a report or a landing page, and the result opens as a working page you can use, keep, revise and share by link. The short version: a chat reply is something you read, an artifact is something you use.

Artifacts launched in June 2024 and became substantially more capable in 2026, when they gained the ability to read live data. Every limit described in this guide was measured directly on 17 August 2026 rather than repeated from other write-ups, because several of the most commonly repeated claims about artifacts turn out to be wrong.

Every artifact runs as a self-contained page inside a locked-down sandbox on claude.ai, with its own URL, its own version history, and a strict security policy deciding what it may reach. That policy explains almost every question people ask about artifacts, and it is rarely written down. Three lines carry most of the weight: connect-src 'self' means an artifact cannot call an external API at all, frame-src 'self' means it cannot embed an external website, and frame-ancestors means it cannot be embedded in your own site either.

So an artifact is not a hosted web app in the normal sense. It must carry everything it needs inside itself: inlined CSS, inlined scripts, images embedded as data URIs. That is a deliberate safety boundary, not an oversight, and it is what makes an artifact safe to open from a stranger.
## Claude live artifacts and the connector model
Live artifacts are artifacts that display current data instead of a fixed snapshot, using runtime capabilities Claude grants the page when a viewer opens it. This is the change that made artifacts genuinely useful in 2026, and it is why the network restrictions are less limiting than they first appear.

An artifact still cannot call an external API directly. What it can do is ask the Claude runtime to call one of the viewer's own connectors on its behalf. The page resolves a capability, discovers which connectors the reader actually has, and calls a tool.

Three properties of this model matter. Calls run with the viewer's credentials, not the author's, and the page never sees a token. The reader must already have that connector installed, so the page shows real data for them and a degraded state for everyone else. And a page that declares connector access cannot be shared publicly, which makes it a tool for a team rather than a marketing page.

The enthusiasm for this is well deserved. You can hand a colleague a link and they see their own numbers, with no deploy, no accounts to provision and no permissions layer to build. A manager sees what a manager may see. A junior sees what a junior may see. The page itself never had the keys.
## The consequence nobody is discussing: a live artifact cannot be a record
A live artifact renders different content for different viewers by design, which means it can never serve as a shared record of what is true. This follows directly from the permission model everyone is praising, and it is the part missing from the current conversation.

Think about what a shared dashboard link actually is once data resolves per viewer. Two people open the same URL. They see different numbers. Both sets are correct. Neither person is shown any indication that the other saw something else.

For access control that is exactly right, and genuinely hard to build any other way. For anything that has to be agreed on, it is a trap. You cannot cite it, because "the dashboard says 12,400" is not a checkable statement when the dashboard is a function of who opened it. You cannot audit it, because there is no server-side render of what any given person was shown. You cannot reconcile a disagreement, because two people looking at conflicting figures have no mechanism to discover that their views differ, let alone why.

The practical rule: use a live artifact when the reader needs to see their own current state, and produce a static export when a number needs to be quoted, filed, sent to a client or argued about later. Those are different jobs, and the same link cannot do both.

This is also the honest limit on the claim that you no longer need software for dashboards. The reporting layer really can collapse into a link. What does not collapse is everything that makes a number defensible: how it was collected, when it was captured, who saw which version, and what it said last quarter.
## Does localStorage work in Claude Artifacts?
Yes. localStorage, sessionStorage and indexedDB all work inside a published artifact. Cookies are the thing that silently fails.

This is worth stating plainly because the opposite is widely repeated. A common claim is that browser storage is blocked in artifacts and fails silently. That was not true when tested on 17 August 2026 with a probe page written for exactly this question: localStorage, sessionStorage and indexedDB each accepted a write and returned the value on read, while a cookie assignment threw nothing and the cookie was simply absent afterwards.

The practical guidance follows. Client-side state that should survive a refresh can use localStorage. Anything built on cookies will fail without raising an error, which is the harder bug to find because nothing anywhere reports a problem.

Most other artifact failures also trace back to the sandbox rather than to a bug. A blank page usually means something tried to load a blocked external resource. Missing images mean remote URLs, which never load. Fonts falling back mean a linked CDN. Failing API calls mean the network rule, which has no page-level workaround. Downloads doing nothing mean the viewer sandbox blocking a download the page started itself. If a page works when opened locally but not as an artifact, it is almost always one of these.

Verify any of it yourself rather than trusting a claim, including this one. Ask Claude for a page that writes a value to each storage API and reads it back, then open it and look. The whole test takes two minutes, and it is the right response to any confident assertion about a sandbox that changes.
## Artifacts vs Projects, Claude Code and ChatGPT Canvas
These get confused constantly because all of them produce something that persists. Artifacts are the output: a page or document Claude produced, versioned and shareable by link. Projects are the input: a workspace of files, instructions and context Claude draws on across many conversations. Claude Code is the workshop: an agent working directly in your real codebase, running commands and committing changes.

A useful rule: if the thing should end up in git, use Claude Code. If it should end up in a link you send someone, use an artifact. If it is context Claude should remember next time, put it in a Project.

Against ChatGPT Canvas, the difference is intent. Canvas is oriented toward collaborative editing of documents and code, with inline suggestions and revisions. Artifacts are oriented toward producing a finished, runnable page, and they add a shareable URL, version history and the connector model. Neither is strictly better: if you are drafting prose or refining a function, Canvas suits it; if you want a working tool at the end, artifacts suit it.

Using them needs no special syntax. Ask for the artifact rather than the code, because "build me a pricing calculator for three tiers" produces a working tool while "write the HTML for a pricing calculator" often produces a code block. Give it your real content, since placeholder data produces a demo you then have to redo. Iterate in place, because version history keeps the old versions. And ask for it self-contained, so nothing depends on a font CDN, a remote image or an external API.

On sharing: every artifact has its own URL and is private by default, and sharing sends the page rather than the conversation that produced it. You can make one publicly viewable, with the exception that a page declaring connector access cannot be made public, because it would run against each viewer's private connections. Artifacts are managed and deleted from your artifacts gallery, and deleting a conversation does not remove the artifact it produced.
## What we learned building one, and where artifacts stop
We built a live artifact that reads data out of a running production app through a connector. Three findings are worth passing on.

Error handling is most of the work. Connector calls fail routinely and each failure has a different fix: the connector is not installed, credentials lapsed, an admin policy blocks it, or the app itself returned an error. Collapsing those into one "something went wrong" message hides the single action that would repair the page. Branch on the error code and tell the reader what to actually do.

Payload size will bite you. The app's list endpoint was written as SELECT *, so every record arrived carrying a large text column it did not need. Six records came to 147KB. Pulling that across the connector on a timer froze the viewer's browser tab outright. A single uncached read, discarding unused fields on arrival, fixed it completely. A list endpoint should return a list projection, not the whole row.

Check the sandbox yourself before designing around it. Several constraints we expected to hit turned out not to exist, and one we did not expect did. Ten minutes with a probe page saved a rewrite.

Artifacts are the fastest route from a request to a working, shareable thing, and the connector model makes them genuinely useful for internal tools rather than only demos. They are still not a hosting platform, and the sandbox makes sure of that. The moment a tool needs its own domain, real authentication, a durable record of what it showed and when, or scheduled work, it needs to live somewhere built for that. An artifact is a great way to show your team what a tool should do. A deployed application is how it runs every day afterwards, and how you can still prove next quarter what it said today.

Content Security Policy and storage behaviour measured from published artifacts on 17 August 2026. Both are worth re-checking before you quote them: the sandbox changes, which is exactly why claims about it should be tested rather than repeated.