Claude Artifacts: Create Documents and Mini-Tools Without Code

What Claude Artifacts Actually Are

Claude Artifacts are standalone pieces of work that open in a dedicated window to the right of your chat instead of scrolling past inside it. The content lives in its own space, keeps a version history, and — when it is a web tool — runs live in your browser while you look at it.

The practical difference is ownership. A chat reply is something you read and then copy somewhere else before it disappears up the thread. An artifact is a thing you keep, hand to someone, and change later without rebuilding it from scratch. If you have read our guide to Claude AI for professional work, this is the feature that most changes what a session is for.

Switch The Capability On First

Before anything else: Claude Artifacts no longer work unless Code execution and file creation is switched on. On a personal plan you will find it under Settings, then Capabilities. On a Team or Enterprise account an Owner turns it on for everyone under Organization settings, then Capabilities.

This is the single most common reason a reader follows a guide like this one, types a perfect request, and watches an ordinary paragraph appear instead. The feature is not broken and the prompt is not wrong — the capability is simply off. Anthropic’s official Claude Help Center guide to artifacts puts this notice at the very top of the page, which tells you how often it comes up.

Two features sit behind a paid plan, and it is worth knowing which before you design something around them.

So the honest answer to “is this a paid feature” is no — building is free. If you want a tracker that remembers what people ticked last week, or a tool that reads your calendar, that is where the paid Claude plans start to matter.

Why Claude Opens A Panel

Claude Artifacts appear on Claude’s own judgement, not on a button you press. That is exactly why the behaviour feels random until you know the rule. Four things push a response into a panel:

1. It is substantial and self-contained — typically more than fifteen lines
2. You are likely to edit it, iterate on it, or reuse it elsewhere
3. It stands on its own without the surrounding conversation
4. You are likely to want to come back to it later

Read those four together and a pattern emerges. Claude is asking whether you want a thing or an answer. Most professionals accidentally ask for an answer while picturing a thing.

The second version does not contain more technical language. It contains a noun — a calculator — that somebody could pick up and use. That is the whole trick, and it is the same instinct behind writing prompts for deliverables rather than topics.

The Deliverable Brief, Explained

The Deliverable Brief is the approach we teach at PromptPeakAI for this exact moment: four short lines you write before pressing enter, which reliably turn a request into a built tool rather than a description of one.

• The thing — name the finished item, not the technology behind it
• The user — who opens it, and on what device
• The moves — what it must let them actually do
• The limits — what it must not include or assume

Here is the brief as a reusable shape. Fill the four bracketed slots and it works for almost anything you would otherwise have asked a developer for.

Build me [name the finished thing: an interactive checklist, a pricing calculator, a one-page policy document].

Who uses it: [who opens it and in what situation — a new starter on their first morning, a client during a video call].

What it must let them do: [the specific actions — tick items off, drag a slider, filter by month, print it cleanly].

What it must not do: [the boundaries — no jargon, no made-up figures, nothing that assumes they have used this before].

Make it a standalone tool I can use straight away, not an explanation of how to build one.

That last line is doing real work. It removes the ambiguity about whether you wanted advice, and in practice it is the difference between a panel and a paragraph more often than anything else in the brief.

Three Tools Worth Building First

Rather than a long menu of what Claude Artifacts can do, here are three that earn their keep immediately for most office roles. Each takes a couple of minutes and replaces something you are probably doing by hand.

Sales and consulting work generates the same email loop endlessly: you send a static quote, the client asks what happens if they halve the volume, you rebuild the quote. A calculator ends the loop by letting them answer that themselves while you are still on the call.

Build an interactive pricing calculator I can share screen with during a client call.

Who uses it: a prospective client with no finance background, watching me demo it on a video call.

What it must let them do: drag a slider for monthly volume, drag a slider for service tier, and see the monthly total, the annual total, and the effective unit cost update instantly.

What it must not do: no made-up benchmark figures, no small print, nothing that needs explaining before they can use it.

Make it a standalone interactive tool, clean and readable on a shared screen.

The standard onboarding checklist is a document nobody updates and nobody can see the state of. A tracker with visible progress changes the dynamic — the new starter knows where they are, and you can ask about the two unticked items rather than all twenty.

Build an interactive onboarding checklist for a new starter's first month.

Who uses it: someone on day one who has never worked here, opening it on a laptop.

What it must let them do: tick items off, see three grouped sections for Day one, Week one, and Month one, and see a progress bar for how far through they are.

What it must not do: no internal acronyms, no tasks that assume system access they may not have yet.

Make it a standalone interactive tool, warm in tone and calm to look at.

This one surprises people, because it involves no interactivity at all. Ask for a policy in ordinary chat and you get an unformatted wall you then rebuild in Word. Ask for it as a document artifact and you get headings, a summary box, and a clean table you can export. The same logic applies to writing HR policies with AI generally.

Build a one-page remote working policy as a formatted standalone document.

Who uses it: every employee, most of whom will read it once on a phone.

What it must let them do: skim it in under two minutes, find the core rule in the first paragraph, and check the specifics in a short table at the end.

What it must not do: no legal boilerplate, no hedging language, nothing longer than a single page.

Make it a standalone formatted document, not a chat reply.

One thing worth knowing early: Claude Artifacts created inside a conversation do not appear in that sidebar automatically. Publishing is what files them there. Until then, they live in the chat that made them — which is a good argument for keeping related builds inside a Claude project so you can find them again.

Refining Without Starting Over

The instinct when a Claude Artifacts build is not right is to rewrite the whole request. Resist it. Each round of changes creates a new version and keeps the old one, so refining is cheap and reverting is easy.

What makes refinement work is naming a specific fault rather than a general feeling. Claude cannot see what irritated you, and “make it better” gives it nothing to act on — the same diagnostic habit that underpins refining AI output without starting over.

Three mechanics are worth knowing. In a formatted document you can highlight a passage and choose Edit with Claude to change it in place, without describing which bit you mean. If something breaks, a Try fixing with Claude button appears near the error and hands over the details for you. And a version selector lets you step back through earlier drafts when a change made things worse.

Change one thing about the tool in the panel.

The problem: [describe exactly what you saw or could not do — the progress bar does not move when I tick a box].

What I want instead: [the specific behaviour — it should update immediately and show a percentage].

Leave everything else exactly as it is.

Publishing, Sharing, And Who Sees What

This is where Claude Artifacts stop being a private convenience and start being a governance question, and it is where most guides go quiet. The rules differ depending on what kind of account you are on, and two of them are irreversible.

On a personal plan — Free, Pro, or Max — you publish, which makes the artifact publicly available to anyone holding the link. They do not need a Claude account to open it or use it. On a Team or Enterprise account you share instead, which restricts it to people logged into your organisation. Work created on a business account cannot be published publicly at all.

Now the part that catches people out. When you share an artifact inside an organisation, viewers also gain access to the attachments and files in the conversation that created it. If you built a dashboard by uploading a spreadsheet of real client data, sharing the dashboard shares the spreadsheet. Treat the whole conversation as the thing you are handing over — the same instinct we apply in our guide to using Claude safely at work.

Two more rules worth writing down. Unpublishing is permanent — once you unpublish an artifact you cannot publish that same one again, and any data it had stored is deleted with it. And if you build on somebody else’s published artifact by copying their code into your chat, treat it exactly like a file from an unknown sender. The same caution that applies to prompt injection risks in your inbox applies here.

Connecting Artifacts To Other Tools

On a paid plan, Claude Artifacts can reach outside the browser. They can store data between sessions — which is what turns a checklist into a tracker that remembers what your team ticked — and they can connect to services like calendars, task tools, and chat platforms through the Model Context Protocol.

Both have honest caveats. Stored data only works once an artifact is published, caps out at 20 MB, and holds text only. Connections need each person to authenticate for themselves, even on a shared artifact. If the underlying standard is unfamiliar, our explainer on what MCP actually is covers it without the engineering vocabulary.

What Artifacts Still Cannot Do

The demos make Claude Artifacts look more finished than they are. Four limits are worth setting expectations around before you promise anything to a colleague.

The realistic promise is narrower than the marketing but still substantial: you can now build the small internal tool that was never worth a developer’s time, in the gap between two meetings. Most managers will tell you that describes a surprising amount of what their team actually needs.

When Artifacts Go Wrong

Four problems account for nearly everything people hit with Claude Artifacts in the first week. None of them require technical knowledge to resolve.

If a build keeps failing in the same place, the usual cause is scope rather than syntax. A tool that calculates, charts, filters, and exports is four tools in a trench coat. Ask for the calculation first, get it working, then add the chart — the second request builds on a version that already runs, which is a much easier job than building all four at once.

Where To Take This Next

The fastest way to make Claude Artifacts stick is to pick one thing you currently rebuild by hand every month and turn it into a tool this week. A quote, a checklist, a status summary — anything you have made more than three times.

• Switch on the capability before you write a single word
• Write the four lines, including the limits line most people skip
• Use the thing yourself before showing anyone else
• Decide publish, share, or neither before you click anything

If your builds start leaning on data rather than logic, the natural companion skill is getting the visuals right — our guide to creating charts with AI pairs well with the dashboard end of this. And Anthropic’s official guide to publishing and sharing artifacts is the page to check whenever the sharing rules matter more than usual.