Search for whether Claude artifacts can save data and you get two confident, incompatible answers. A widely ranked limitations guide, last updated February 2026, says "everything resets when you close the chat. There's no way to save state between sessions or persist user data." Anthropic's official help center says artifacts "can store data across sessions, enabling stateful applications like journals, trackers, and collaborative tools," with a 20 MB storage limit per artifact.

Both cannot be right. The resolution is mundane: the feature changed in October 2025 and the top guides did not. Artifacts can persist data now, under specific conditions, with failure modes quiet enough that people lose data without noticing. I checked the official docs and the announcement timeline to pin down what survives, scenario by scenario.

Why the top answers disagree

Artifacts launched in June 2024 with no persistence of any kind, and most of the web's answers were written for that version. In June 2025 Anthropic added AI-powered artifacts you can publish and share. An October 21, 2025 update to the same announcement added the line that matters: "Artifacts now support MCP and persistent storage."

The guides outranking the official docs predate or ignore that update. The p0stman guide still states artifacts "can't connect to databases, APIs, or save data," which was true in 2024 and is now wrong on all three counts. The ShareDuo guide, updated May 2026, correctly says localStorage fails in the sandbox, then claims real persistence requires "a hosted backend," never mentioning the built-in storage feature. Stop reading at either one and you will either give up on persistence or build a backend you might not need.

You refresh the page

For a draft artifact, the one sitting in the panel next to your chat, a refresh wipes everything the app held at runtime: React state, JavaScript variables, and anything the app thinks it saved. The help center is explicit about that last part: "Persistent storage is only available for published artifacts. During development and testing, storage operations will not succeed until the artifact is published." A journal app can look like it is saving entries while you test it, and none of those writes land anywhere.

For a published artifact on a paid plan, data written through the storage feature survives a refresh. The artifact's code survives the refresh in both cases, because the code lives in your conversation, not in the running page.

You reopen the artifact tomorrow

Two different things can persist, and most of the confusion comes from conflating them. The artifact itself, meaning the code or document Claude generated, is saved with your conversation and listed in the artifacts space in the sidebar. It will be there tomorrow, next month, and in a new conversation.

The app's data is a separate object with stricter conditions. Per the help center, it comes back tomorrow only if all of these hold: the artifact is published, you are on Pro, Max, Team, or Enterprise (free plans cannot use persistent storage, and it works on web and desktop only), the data is text (no images, files, or binary), and it fits in 20 MB per artifact. Miss any one of those and tomorrow's session starts empty, without an error message explaining why.

You try localStorage anyway

This is the silent failure people keep reporting. Artifacts run in a sandboxed iframe; Simon Willison's writeup describes localStorage and outbound fetch being restricted by CSP headers and the iframe sandbox mechanism. Claude's own artifact system instructions, surfaced on Hacker News in May 2025, are blunter: "NEVER use localStorage, sessionStorage, or ANY browser storage APIs in artifacts. These APIs are NOT supported."

Claude usually avoids generating such code, but when it slips through, or you paste in code from elsewhere, the writes fail without a visible error. The app renders, the save button responds, and the data goes nowhere. The official help center does not document this restriction at all, which is presumably why "my tracker forgot everything" threads keep appearing.

You unpublish the artifact

This is the sharpest edge in the feature, documented in one sentence of the publishing guide: "Unpublishing also permanently deletes all associated storage data (both personal and shared) if the artifact used persistent storage." No export step, no documented grace period. A second surprise sits on top: "Once you unpublish an artifact, you cannot publish that same artifact again."

Put together, the design has an odd shape. The only state in which artifact data persists, published, is also the state you cannot leave without destroying that data. If a shared tracker holds three weeks of your team's entries, unpublishing deletes all of them, permanently, and republishing the same artifact is not an option.

A visitor uses your published artifact

Anyone can view a published artifact and use its basic functionality without a Claude account. Sign-in is required for advanced features, including the AI-powered parts, and when a visitor's click triggers a Claude prompt, it is billed against their own account, not yours.

For data, storage runs in one of two modes. Personal storage means "each user maintains their own private data": a visitor's journal entries live in their own bucket, invisible to you. Shared storage means "all users see and interact with the same data," and first-time visitors get a confirmation dialog warning that their input will be visible to others. In both modes the data hangs off your published artifact, so if you unpublish, your visitors' data is deleted along with yours.

The truth table

What Persists? Conditions
The artifact itself (code, document) Yes Saved with your conversation and artifacts space
In-memory state (variables, React state) No Gone on refresh or close, always
localStorage / sessionStorage No Blocked by the sandbox, often fails silently
Storage writes in a draft artifact No "Will not succeed" until published
Storage in a published artifact Yes Paid plan, 20 MB per artifact, text only
Stored data after unpublishing No Permanently deleted, personal and shared
A visitor's data (personal mode) Yes Private per user, deleted if you unpublish
Shared-mode data Yes One pool everyone sees, until unpublish

The docs state the 20 MB per-artifact limit but say nothing about an account-wide cap; I could not verify whether one exists.

Keeping the data you care about

A few habits cover most of the risk. First, ask Claude to add an export button to any artifact that accumulates data; a "download as JSON" or CSV button works inside the sandbox and produces a file outside the whole system. Second, export before you unpublish, every time; deletion is permanent. Third, if the app depends on storage, publish early and test the published version, since draft writes do not succeed.

Fourth, export before major revisions: iterating on an artifact rewrites its code, the docs say nothing about what happens to existing entries across updates, and I treat every significant edit as a potential reset. If what you want preserved is the artifact as a permanent site rather than its data, that problem has a cleaner solution, covered in Turn a Claude Artifact into a Real Website.

When you have outgrown artifacts

Artifact storage is a real feature with narrow walls: text only, 20 MB, paid plans, and a lifetime fused to the publish state of one artifact inside one vendor's interface. The moment you want data that outlives those conditions, the shape you are looking for is a real database behind a real URL that the agent can keep writing to.

Caipi is my product and that is the shape it provides: agents (Claude, ChatGPT, anything that speaks MCP) write pages, dashboards, and small SQLite-backed apps into a hosted workspace at caipi.ai, where the data sits in an actual database with no unpublish trapdoor. The longer argument for why a running, maintained artifact beats a static snapshot is in The Leap From Documents to Tools.

Everything above was checked against Anthropic's official documentation and announcement pages in June 2026. The third-party claims are quoted with their last-updated dates; this feature has changed once already and will change again.