About 10 minutes, most of it MCP configuration
Claude Artifacts to BinHTML
Take HTML that Claude generated and publish it as a link your recipients can open without a Claude account, with visibility controls and version history.
Do not migrate if
Migrating has a cost and it is not always worth paying. If one of these describes your situation, stay where you are.
- You are still iterating in the conversation and nobody outside it needs the output yet.
- Claude's built-in sharing already reaches every person who has to see the artifact.
- The artifact is disposable and does not need to outlive the session.
Before you start
- A BinHTML account and an API key.
- Claude Code, Claude Desktop, or another MCP-capable client if you want the agent to publish directly.
- The generated HTML, either as a file on disk or as content the agent still holds.
Steps
01
Connect the remote MCP endpoint
Add https://binhtml.com/mcp as a remote MCP server in your client and authenticate with your API key. The MCP documentation has the exact configuration for each client. Once connected, the agent gains a publish tool it can call on its own.
02
Tell the agent to return a link, not a wall of HTML
Add an instruction to your project or system prompt: when the deliverable is an HTML document, publish it to BinHTML and reply with the share URL. This is the change that turns a chat artifact into a handoff.
03
Or publish the file directly from a script
If the HTML already exists on disk, for example from a Claude Code run that wrote a report, the REST API is the simpler path and needs no MCP setup.
Publish a Claude-generated file
Language: bash. Replace $BINHTML_API_KEY with a key from your settings.
# Reads report.html from disk, publishes it, prints the share URL. jq -n \ --arg title "Weekly report" \ --rawfile html ./report.html \ '{title: $title, visibility: "unlisted", sourceHtml: $html}' \ | curl -sS -X POST https://binhtml.com/api/v1/artifacts \ -H "Authorization: Bearer $BINHTML_API_KEY" \ -H "Content-Type: application/json" \ -d @- \ | jq -r '.urls.share'04
Group a multi-part handoff into a project
When a run produces several documents, publish them with the same projectName and then create one project share link. Reviewers get a single URL that indexes the whole set.
Create a project share link
Language: bash. Replace $BINHTML_API_KEY with a key from your settings.
# One link covering every artifact published into the project. curl -sS -X POST https://binhtml.com/api/v1/projects/share \ -H "Authorization: Bearer $BINHTML_API_KEY" \ -H "Content-Type: application/json" \ -d '{"projectName": "Weekly reporting"}'05
Set visibility before you send the link
Unlisted is the default and is right for most review handoffs. Use private on Pro when only your account should be able to open it. Both are noindex.
Verify the migration
Work through these before you remove anything from the old tool. A migration is finished when someone other than you has opened the new link successfully.
- A person with no Claude account can open the share URL.
- The artifact renders the same as the preview did inside Claude.
- The agent returns the URL in its response instead of pasting the HTML.
- Re-running the agent updates the existing artifact rather than creating duplicates, if you passed the artifact id.
Known gotchas
Artifacts that relied on the host environment
If the HTML expected something the Claude preview provided, it will need to be self-contained before it renders correctly anywhere else.
Read the document before publishing it
Model-generated HTML can contain content pulled from files or the web. BinHTML sandboxes rendering, but sandboxing does not stop you publishing something you did not intend to share.
Agents will happily create duplicates
Without an artifact id to update, every run creates a new artifact. Store the id, or publish into a named project so at least the set stays organised.
Questions about this migration
How do I migrate from Claude Artifacts to BinHTML?
Publish the artifact HTML through the remote MCP endpoint or the REST API so the agent returns a share URL as part of its answer.
How long does migrating from Claude Artifacts take?
About 10 minutes, most of it MCP configuration. The steps on this page cover creating an API key, publishing one document to confirm the output, switching repeat publishing to version updates, and verifying the result before you retire the old links.
When should I not migrate from Claude Artifacts?
You are still iterating in the conversation and nobody outside it needs the output yet. Claude's built-in sharing already reaches every person who has to see the artifact. The artifact is disposable and does not need to outlive the session.
Will the share link change when the content is updated?
No. Publishing a new version against an existing artifact id updates the content behind the same URL, so anyone already holding the link keeps working access.
Next steps
- API reference for every field and error code used above.
- Plan limits so a migration does not stall on a size or retention cap.
- All migration guides if more than one workflow is moving.
- Frequently asked questions for anything this guide did not cover.