Claude artifacts vs projects — what each one is for

The one-sentence version

Artifacts = output. Projects = memory.

When Claude builds something you can see — a calculator, a landing page, a PRD, a dashboard — that's an artifact. When you want Claude to remember your brand guidelines, your product context, and your preferred tone across every future conversation, that's what a project carries.

The confusion is understandable: Anthropic rolled out both features around the same time, and the names don't make the distinction obvious. But once you see them clearly, the choice of when to reach for each one is easy.

What Claude artifacts are

An artifact is the thing Claude renders in a side panel when you ask it to build or write something self-contained. The panel shows a live preview — a working mini-app, a formatted document, a chart you can interact with — and updates in place each time you ask for a change.

Claude creates an artifact automatically when the output is substantial, self-contained, and better seen than read as code — roughly 15+ lines of independent output. The types:

• HTML/CSS/JS pages — prototypes, calculators, landing pages
• React components — interactive UI mockups, data tools
• Markdown documents — PRDs, briefs, one-pagers
• SVG images — logos, diagrams, simple illustrations
• Mermaid diagrams — flowcharts, architecture maps, user flows
• Code snippets — scripts, functions, config files

A newer addition: Live Artifacts (rolled out April 2026) are dashboards that stay connected to a data source and refresh every time you open them, rather than being a frozen snapshot at the moment of creation. Useful for recurring KPI views or pipeline trackers you revisit weekly.

What Claude projects are

A project is a persistent workspace that stays loaded across every conversation you start inside it. Before projects existed, every new Claude chat started from zero — you'd re-paste your PRD, re-explain your writing style, re-upload last week's research. Projects eliminate that.

Inside a project you can set:

• Custom instructions — tone, constraints, role ("you're my product copywriter; always write for a technical audience")
• Knowledge documents — your PRD, brand guide, competitive research, code architecture doc (up to 200,000 tokens of context)
• Conversation history — past chats in the project stay accessible, so Claude can pick up threads

Team and Enterprise users can share a project with teammates, which is what makes it a team knowledge base rather than a personal shortcut.

One practical note: the context window in a project fills up as you add more documents and conversations. If you upload your entire codebase and then start a chat, you'll have less room for the conversation itself. Prioritize the documents Claude actually needs for the work you're doing there.

Side-by-side comparison

The only row where artifacts clearly win: shareability. A project stays yours. An artifact can be published to a link that anyone can open in a browser, no Claude account required. That's the handoff mechanism projects don't have.

How they work together — the real workflow

The strongest workflow is to use both. A few concrete examples:

The PM's product project. You create a project, upload your current PRD, product strategy, and user personas. You set a custom instruction: "When I ask for copy, write at a 7th-grade reading level and lead with the user benefit." Now every chat inside that project has that context loaded. When you ask Claude to draft a feature announcement, it builds a Markdown artifact shaped by your brand voice — without you re-pasting anything.

The maker's side-project project. You create a project for your app with the architecture doc and design system as knowledge documents. Each chat produces artifacts — components, page layouts, config files — that Claude generates knowing your stack. You don't explain what framework you're using on every message.

The one-off build without a project. You don't need a project for every artifact. If you just want a quick calculator or a throwaway chart, start a regular chat, ask Claude to build it, get the artifact. Projects pay off when you're doing repeated, context-heavy work.

Where each one runs short

Neither tool handles the full workflow on its own.

Artifacts fall short on review. Once you publish an artifact — click the Publish button, get a claude.ai link — your recipient can view it and interact with it. What they can't do: click a specific element and leave a note pinned to that spot. Feedback has to travel sideways: a screenshot, a Slack message, a voice note. Then you re-explain those notes to Claude in a new session and start another iteration. For a maker or PM trying to get sign-off on something, that's the part that grinds.

Projects fall short on handoff. You can share a project with teammates on a Team or Enterprise plan. But a project can't be handed to a client, a freelancer, or a stakeholder who isn't in your Anthropic org. There's no public link, no guest access. If your collaborator is outside your team, projects don't reach them.

The timing gap. An artifact is tied to a session. If you build something, close the tab, and come back later, the artifact is gone from view — though you can rebuild it from the chat history. The artifact isn't a stable, versioned URL that persists and updates in place. For work that goes through multiple rounds of revision, the lack of a permanent link you can iterate on is a real friction point.

The distinction people most often miss

The most common confusion is treating artifacts and projects as substitutes — as if you choose one or the other.

You don't. Artifacts are always produced inside a conversation, whether that conversation is in a project or not. Projects just mean Claude starts that conversation already knowing what you told it last time.

The cleaner mental model: think of a project as a briefing that never expires, and an artifact as what Claude produces after it's been briefed.