Comparison · Generated surfaces

ChatGPT Visualize vs. Claude Artifacts vs. Sites

All three turn a sentence into something you can click, which is exactly why they keep collapsing into one category. The boundaries are the whole comparison.

2026-07-15By João Janini5 min readAgent-assisted

Last verified 2026-07-16. Visualize and Sites are in preview or beta and Artifacts keeps gaining capabilities, so details here may be stale. Check the primary sources before you build.

The same demo keeps happening in three products. A sentence typed into ChatGPT becomes a planet simulator with sliders. The same sentence in Claude docks a calculator beside the chat. In Sites it comes back as an app with its own URL. Same opening move, three different boundaries.

Visualize stops at understanding

Visualize is a first-party ChatGPT plugin, currently in preview. You can summon it with @Visualize, or ChatGPT can pick a chart, map, diagram, calculator, simulation, or interactive explainer on its own when that improves the answer. The conversation is part of the object: pasted data, attached files, connected sources, and earlier context all feed the controls you end up dragging. How the system fits together. What moves when this variable moves. Where the outliers hide.

The documentation draws the ceiling just as clearly. A visualization is a snapshot of what was available when it was created; it does not stay synchronized with a connector the way a live dashboard would. A follow-up can produce a replacement instead of an in-place edit. Sharing rides on conversation sharing, and Codex CLI and the IDE extension do not render the interactive result. It is closer to a high-bandwidth answer than to a deployed application, and it seems comfortable there.

An Artifact is an object with a history

Claude creates an Artifact for substantial, self-contained content: a document, code, an SVG, a diagram, a single-page website, an interactive React component. It opens in its own working pane instead of scrolling away in the chat stream; the placement announces that this content expects to be edited, reused, revisited.

The object identity is real. Edits create versions. The code can be inspected and downloaded. Published Artifacts can be shared and added to the Artifacts collection, and AI-powered ones can call a limited Claude text capability billed to each viewer's own subscription. Current paid plans can connect an Artifact to MCP services, custom servers included, and a published Artifact gets personal or shared persistent text storage, documented at 20 MB. That is a small application with tools and state, well past a static Canvas.

The constraint is the runtime: it stays Anthropic-managed, so an Artifact is never automatically a portable MCP App, a conventional repository deployment, or an arbitrary external backend.

A Site is a production deployment

Sites is where the output becomes infrastructure. OpenAI describes it as a way to create, host, refine, and share websites, web apps, and games. A Site can start from a prompt or from a compatible local project linked through .openai/hosting.json, and it persists in a dedicated Sites view.

The product model reads like deployment software. A Site separates saved versions from deployed versions, and every deployment URL is a production deployment; there is no staging tier to hide behind. Access can be private, workspace-scoped, or link-based. Durable records can bind to a relational database, uploads can use object storage, workspace or public authentication can shape the site, and runtime environment values live in Site settings. Sites owns hosting, state, access, and lifecycle. When an explanation needs a stable URL that people return to, this is the escalation path.

Compare the boundaries, not the screenshots

Screenshots of all three look interchangeable. The differences live in four questions.

	Visualize	Artifact	Site
Where it lives	Inside a ChatGPT conversation	In Claude's Artifact system, publishable into that ecosystem	A hosted project with a deployment URL
What keeps it current	Nothing; it reflects the source snapshot used at generation	MCP tool calls after user approval, plus preserved application data (short of a continuously refreshed Live Artifact)	Deployed code and backend, with persistent data services
How it is shared	Conversation sharing, so the full shared context needs review	Publishing and remixing; MCP authentication stays per user	Explicit audience and hosting controls around a production deployment
Who owns the implementation	The model generates the smallest useful interactive answer	Anthropic runs the runtime; code, versions, MCP access, and storage are exposed	A deployable application project whose source and infrastructure shape you can inspect and evolve

Three examples and an escalation

Explain an orbital system

Visualize. The value is in dragging a control and watching the relationship respond. A production URL adds lifecycle work without improving the explanation.

Build a decision calculator

An Artifact. Iterate beside the conversation, inspect the code, publish it, optionally keep small user data or call an MCP tool.

Launch a request tracker

A Site. People need authentication, durable records, uploads, and a stable address that outlives the original conversation.

Promote when it earns it

The boundaries move. A Visualize result can be refined and turned into a Site, Artifacts now reach MCP and storage, and a Site can begin as a prompt. Start with the smallest surface that fits.

Four gaps the docs leave open

Visualize export is not a deployment contract. The docs describe sharing and generation, with no stable portable runtime format.
Artifact portability is not MCP App portability. MCP access inside an Artifact does not document a way to run the same UI in other MCP hosts.
Plan and workspace controls decide what you actually get. Preview access, public sharing, connectors, and storage differ by account.
Generated output still needs review. Data assumptions, accessibility, security, and sharing boundaries are unsolved by picking a richer surface.

The actual competition

Lifecycle is the contest

For now the three products optimize different moments:

question → Visualize → interactive understanding
idea → Artifact → reusable working object
workflow → Site → hosted application lifecycle

The interesting competition is no longer which model draws the best chart. It is who gives generated software the right lifecycle: source context, iteration, data, permissions, sharing, and a path from private thought to durable product. Until someone owns that entire path, pick by the noun you are holding. A question wants Visualize. An idea wants an Artifact. A workflow wants a Site.