You asked Claude for a sign up sheet, a tracker, a poll. It works in the chat. Then you send it to four people and the answers do not add up, or you come back on Monday and the page is empty. Nobody told you why.
The short version: artifacts do have persistent storage, and it comes with four conditions attached. If all four hold, use it. If one of them does not, the page needs to live somewhere else. This page is the honest map of both.
The four conditions, from Anthropic's own help centre
All four of these are quoted from the Claude help centre article on artifacts, read on 9 September 2026. No blog numbers, no guesses.
- A paid plan. "Persistent storage for artifacts is available on Pro, Max, Team, and Enterprise plans on Claude web and desktop." A visitor on the free plan is not the issue: the owner has to be on a paid plan for the artifact to have storage at all.
- Published. "Persistent storage is only available for published artifacts. During development and testing, storage operations will not succeed until the artifact is published." This is the one that makes people think it is broken: it fails silently while you are still building.
- Text only. "Text-only input, no images, files, or binary data."
- 20 MB. "20 MB storage limit per artifact." Generous for a list, a wall for anything that collects uploads.
Storage can also be personal, where each viewer keeps their own data, or shared, where everyone sees the same records. That pair of modes is the right design and Hostus copies it, under the names per_reader and shared.
So why does the data disappear?
Three different failures get described with the same sentence, "it did not save". They have different fixes.
| What you see | What is happening | Fix |
|---|---|---|
| Works while you build, empty for everyone else | Storage does not run before the artifact is published | Publish it, then test |
| Each person sees only their own entries | Personal storage, not shared | Ask for shared storage explicitly |
| Everything is gone the next day | The page kept state in the browser, not in storage | State in a browser stays in that browser. It has to be written somewhere both of you can read |
That last row is worth sitting with. Anything a page keeps in the visitor's own browser is invisible to you, to the next visitor, and to the same person on their phone. It is not a bug, it is what browser storage is. A shared list needs a place outside the browser.
Where to put the page when the conditions do not hold
1. Hostus, if you want the page to be a link you own
Drop the HTML file Claude wrote you into Hostus and you get a URL. If the page uses the hostus.data SDK, it stores records against the document: visitors write, everyone reads, nobody logs in and there is no key in the page. The free plan stores up to 1,000 records per collection, which is a long way past a supper club, and the page is a file you can download and take elsewhere. This is the option to pick if the page has to work for people who are not you, on any plan.
Three of them are live right now, and the data in them is real:
- An RSVP list: type your name and it appears for everyone.
- A poll: one vote per person, results move as you watch.
- A shared checklist: tick something and the next visitor sees it ticked.
2. Artifact storage, if you are on a paid plan and the page lives in Claude
If all four conditions hold and you are happy for the page to be opened inside Claude, this is the shortest path: no export, no upload, no second tool. Pick it when the audience is you and your team, and the page is not something you need to send to a client on your own domain.
3. A form service, if you only need submissions
Formspree, Web3Forms and friends collect what people type and email it to you. They are a good fit when the page does not need to show the collected data back to visitors. The moment you want a live count on the page, you are back to needing storage.
4. A real backend, if this became software
Accounts, permissions, exports, invoices. When the thing you are building has those, none of the options above are what you want, and that is fine. Most sign up sheets never get there.
The prompt that gets you a page with real storage
Paste this into Claude, with the connector on. It writes the file and publishes it in one go.
Make me a sign up page for the March supper: someone types their name, picks coming or not coming, and the list shows everyone who has signed up so far, live for every visitor.
Use the hostus.data SDK so the entries are stored on the document itself: data.watch("rsvps", render), data.add("rsvps", {name, going}). No backend, no localStorage, no keys in the page. One HTML file. Then publish it to Hostus and give me the link.If you do not have the connector yet, ask for the file and drop it into Hostus by hand. Same result, one more step.
Good to know before you switch
Hostus stores records as key and value inside one collection per document, capped at 8 KB per record and 20 collections per page. It is the right size for a list, a tally, a checklist or a small CRM. It is not a database with queries and joins, and we would rather tell you now than have you find out at record four hundred.
The other honest limit: the page has to be hosted on Hostus for the storage to work, because the identity of each reader is resolved by the server. Download the HTML and open it from your desktop and the list will be empty. The file is still yours, and any host will serve it, but the data part is ours to run.