Artifact sharing fails: "This version can't be shared publicly" persists across republish and new artifacts

Same error here, adding a reproduction data point.

Error: "This version can't be shared publicly. Publish a new version or change the shared version, then try again." when switching General access from "Only you" and clicking "Share publicly".

Environment:

• Claude Code CLI on macOS (darwin), artifact published via the Artifact tool from a CLI session
• Personal account (gmail), viewing at claude.ai/code/artifact/<id>
• Artifact: fully self-contained static HTML (inline CSS, native mermaid fences), no capabilities declared, no MCP connectors

Tried, all failed with the same error:

1. Republished a new version to the same URL (with a version label) — error persists
2. Published the same file under a new filename → brand-new artifact at a fresh URL — error persists on first share attempt
3. "Shared version" dropdown shows "Latest" and is greyed out/disabled, so the error's own suggestion (change the shared version) is not actionable

Renders fine for the owner; only public sharing is blocked. Happy to provide artifact IDs privately if useful.

Hitting this on a personal Max account with CLI 2.1.220. Same error across four republished versions and two separate artifacts, including one published with capabilities explicitly cleared and the runtime contract bumped to latest, so it isn't a stale version or a connector declaration. The docs say a public link is the only way to share an artifact on Pro and Max and that no admin management applies on those plans, which means there is no External sharing toggle for an individual account to turn on. Looks like the org-level external-sharing flag is being evaluated against the auto-created personal org, where it defaults off and has no admin UI. If that's the cause, public sharing is unreachable for every Pro and Max user rather than being a per-artifact problem.

same error

Super annoying. I see this too.

same here, Claude Max account

Another failed workaround: reducing size from 7mb to 0.39 MB

Another: publishing by overwritting a past artifact that was sharable also doesn't work

Bisected this today and found at least one concrete trigger — it is content-based, not account- or org-level.

A raw, unencoded data:image/svg+xml,<svg …> URI anywhere in the artifact source blocks public sharing.

In my case it was a one-line emoji favicon:

<link rel="icon" href='data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><text y="14" font-size="14">🧭</text></svg>'>

How I narrowed it

Published one artifact per variant and tried Share → "Anyone with the link" on each:

| variant | shareable |
|---|---|
| trivial control page | ✅ |
| full report, prose only (67 KB, no JS, no data) | ❌ |
| first half of sections | ❌ |
| second half of sections | ❌ |
| everything except the TL;DR | ❌ |
| TL;DR only | ❌ |
| 20 KB stylesheet only | ✅ |
| the favicon line only — 144-byte page | ❌ |

Then isolating what about it:

• data:image/svg+xml;base64,<base64> → ✅ shares
• raw data:image/svg+xml,<svg …> in <link rel="icon"> → ❌
• the same raw SVG URI in an <img src> → ❌

So it's the unencoded SVG markup inside a data: URI — not SVG as such, not favicons, not the <link> tag. My guess is the publish-time scanner treats inline SVG markup as active content (SVG can carry script).

Fix

Base64-encode the SVG data URI, or drop the <link rel="icon"> entirely (Claude Code's Artifact tool has a favicon parameter that sets the tab icon anyway). Base64-encoding that single URI and changing nothing else made a 1.4 MB report share immediately.

Ruled out

Artifact size (6.9 MB, 1.4 MB and a 144-byte page all failed), the capabilities declaration, window.claude.* runtime references, and the page's prose. The failing PATCH /api/frame/perm/<id> returns 409.

@kristianward416 @ouell @darmawan01 @mirzaromi @trauts2 @sandrods — worth grepping your sources for data:image/svg+xml, (comma, not ;base64,). Several of you mention Mermaid diagrams; Mermaid renders to SVG at runtime rather than in the source, so that may well be a different trigger and I haven't tested it. But if any of you have an inline SVG data URI in the file, that alone is enough to reproduce.

Also worth fixing on the product side: the error message points at "publish a new version", which cannot help when the cause is in the content itself. Naming the offending construct would have saved a lot of guessing.

---
Investigation run by Claude (Opus 5) in Claude Code, posted by @Butanium.
Co-Authored-By: Claude <noreply@anthropic.com>

another time republishing worked, there was somehow a transient error

Another data point: removing a Mermaid diagram fixed sharing for me, and my source never contained an SVG data URI.

One artifact with a single <pre class="mermaid"> ER diagram refused to share. I replaced that diagram with a static HTML/CSS table, changed nothing else, republished to the same URL, and "Anyone with the link" worked immediately. Published size went from 3.2 MB (almost all of it the Mermaid runtime injected at publish time) down to ~38 KB.

I can't say whether Mermaid as such is the trigger. Removing the block also removed the injected bundle, and the only two <svg occurrences anywhere in the published page were inside that bundle, in code that builds SVG by string concatenation:

return'<svg xmlns="http://www.w3.org/2000/svg"'+r+">"+e+"</svg>"

So it's consistent with @Butanium's theory extending to SVG markup inside a JS string rather than only in a data: URI, but I have not run the isolating test (a page with an inert SVG string and no Mermaid) to confirm. Posting in case someone else has already ruled that in or out.

Practical workaround either way: if a diagram is the only blocker, hand-writing it as HTML/CSS restores sharing and drops several MB at the same time.

Can confirm — same fix worked for me. Had a Field Manual–style spec page (architecture + ER + 4 sequence diagrams, all inside <pre class="mermaid"> blocks, ~all text, no images, no raw data:image/svg+xml, anywhere in my source). Public sharing failed with the same "This version can't be shared publicly" error, and persisted across republishing to the same URL and to a fresh URL under a new filename.

Rebuilt all four diagrams as static HTML/CSS (a routing-table layout for the component diagram, entity cards + a relationship table for the ER diagram, numbered procedure lists for the sequence diagrams) and removed every <pre class="mermaid"> block — nothing else changed. Republished to the same URL and "Anyone with the link" worked immediately.

This lines up with @sandrods's finding — the Mermaid runtime bundle injected at publish time builds its output via SVG string concatenation, and that seems to be enough to trip the same scanner as a raw inline SVG data: URI, even with zero literal SVG markup in the authored source. Worth the product team confirming whether the scanner runs against the rendered page (including injected runtime bundles) rather than just the authored source .

Another data point: for me this is format-specific to inline AVIF, with no SVG or Mermaid involved.

Same minimal page each time — static HTML, inline CSS, no scripts — differing only in the one inline image:

| Probe | Inline media | Media bytes | Page size | Shares publicly? |
| --- | --- | --- | --- | --- |
| no image at all | none | — | 1.3 KB | ✅ yes |
| one AVIF | image/avif | 1,978 | 3.7 KB | ❌ no |
| one PNG | image/png | 26,577 | 35.8 KB | ✅ yes |
| one JPEG | image/jpeg | 2,175 | 4.0 KB | ✅ yes |

Same result on the real document: it failed with two animated AVIF clips inline (370 KB), and shared as soon as I swapped them for JPEG stills (125 KB).

Two things that fall out of this:

• Size isn't the trigger. The 3.7 KB AVIF page fails while the 35.8 KB PNG page passes with 13× more media.
• SVG isn't the trigger either, so the Mermaid reports above may be one instance of something broader. SVG ✗, AVIF ✗, PNG ✓, JPEG ✓ would be consistent with an allowlist that AVIF just isn't on. WebP would be worth checking too.

Also tried, all still blocked: republishing to the same URL, publishing under a new filename to get a fresh artifact, and contract: "latest".

Environment: Claude Code CLI 2.1.228, macOS 15.6.1, published via the Artifact tool, no capabilities declared. Owner-side rendering is fine in every case — only the public toggle is blocked.

Data point: base64-encoded SVG blocks too, and converting it to PNG fixes it

Building on @Butanium's SVG finding, with two things I think are new: the base64 form of an SVG data URI blocks as well, and there's a clean A/B isolating the format from everything else on the page.

Setup. A single-page HTML report (~0.6 MB, inline CSS and JS, no external assets) that embeds six publisher logos as data: URIs — three image/svg+xml;base64, three image/png;base64. Published from Claude Code's Artifact tool on macOS.

| build | embedded media | shares publicly? |
| --- | --- | --- |
| six logos: 3 SVG (base64) + 3 PNG | 24 <img>, 6 data URIs, 0.60 MB | ❌ no |
| same page, logos suppressed | 0 images, 0.31 MB | ✅ yes |
| same page, all six logos rasterised to PNG | 24 <img>, 6 data URIs, 0.60 MB | ✅ yes |

Rows 1 and 3 differ only in image encoding — same markup, same script, same six logos rendered, same page size. So it isn't image count, page weight, or <img> usage: it tracks the SVG data URIs specifically.

Worth flagging that these were data:image/svg+xml;base64,…, not the raw unencoded form reported earlier in this thread. So the trigger is wider than raw SVG.

The error message is the expensive part, whatever the check decides.

This version can't be shared publicly. Publish a new version or change the shared version, then try again.

It names a remedy that cannot work, and it points at the wrong subsystem. Following it, I published two more versions, then minted three separate artifacts, then concluded public sharing was disabled for the account — which is the same conclusion the original report and at least two commenters here reached. It's wrong, and nothing in the UI can tell you so.

What broke it open was noticing that other artifacts on the same account shared fine. That single observation kills the account-level theory, and the error message actively steers you away from making it.

I also spent a while on a wrong content theory: with six publisher logos on the page, "this looks like brand impersonation" is a very plausible read, and removing all six does make the page shareable. But that experiment confirms the bundle, not the cause — the six logos differed from the working page in imagery, format, count and size at once. Only splitting the bundle found the dimension that mattered, and it was the least interesting one.

Even if blocking these formats is intentional, an error naming the content — this page embeds an SVG data URI, which can't be shared publicly — would turn a multi-hour bisect into a one-line fix. As it stands, the message costs everyone who hits it a pile of throwaway artifacts, which they then can't delete from the CLI (#70254).

Workaround, if you're stuck: rasterise any inline SVG to PNG. I pull logos through Wikimedia Commons' thumbnailer, which renders SVG→PNG on request, so it was a one-line change and the page looks identical at the size the images actually display.

I got the same publish to public blocked in Claude Design artifact. Here is what i did: Download then zip from claude design, put into claude code and give it a /goal to find all things blocking from making it public also give a tool like browserforce or agent-browser for claude to verify it in real browser (because we'll only know when we get the below error message) and ask to write each to a artifact-publishing.md as rules list.

Here are some insights:

A. Blocks "Anyone with the link" (share refused)

Symptom: switching General access to "Anyone with the link" silently reverts to
"Only you" with *"This version can't be shared publicly. Publish a new version or
change the shared version, then try again."*

1. A pre-encoded data: URI in source. A fully percent-encoded

data:image/svg+xml,%3Csvg%20width%3D… string (~1.3 KB) inside a <script>
reads as an obfuscated payload to the content scanner. One is enough to make
the whole file un-shareable. Confirmed both directions: that line alone →
blocked; the same block minus that line → public.
Fix: keep the SVG readable and encode at runtime —
url("data:image/svg+xml,${encodeURIComponent(SVG)}") — or inline <svg>.

1. Same pattern inside vendored libraries. Shopify's polaris.js carries 4 of

them for its ::-webkit-resizer grip. Neutralising only those (→
background:none) flipped a still-blocked build to public. Check what you inline,
not just what you wrote.

### B. Blocks rendering (page loads blank / placeholders visible)

The sandbox CSP:

default-src 'self';
script-src 'self' 'unsafe-inline' 'unsafe-eval' blob:;
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
img-src 'self' data: blob:;
font-src 'self' data: https://fonts.gstatic.com;
connect-src 'self' https://fonts.googleapis.com https://fonts.gstatic.com;

1. Only ONE HTML file is published — every relative path (./runtime.js,

assets/*.png) 404s.

1. No off-host requests — unpkg (React/ReactDOM/Babel), cdn.shopify.com,

image CDNs all refused. Google Fonts is the only allowed host.

1. data: scripts are refused; blob: scripts are allowed. 'unsafe-eval'

IS allowed, so template/JSX runtimes work once their deps are inlined.

1. Runtime-lazy fetches survive a "looks fine" first glance. A component

imported lazily (fetched as a sibling .html) 404s, and that one screen renders
empty while everything else is correct. Same for icon fonts/sprites that a
component library fetches on demand.

1. A base64 data: URI cannot go inside a style string if your runtime parses

style by splitting on ";" — background-image:url(data:image/png;base64,…)
gets cut at the semicolon → ERR_INVALID_URL, image silently blank. This only
appears after you localise the asset (the remote URL had no semicolon).
Fix: URL.createObjectURL(new Blob([bytes])) — blob URLs have no semicolon.

### C. Operational gotcha

1. A public share is pinned to one version. Republishing does NOT update the

public link — viewers keep seeing the old build ("sharing pinned version N").
The version picker is disabled while public, so: set access to
"Only people with access" → then back to "Anyone with the link" (re-scans and
re-pins). Re-check the share control after every republish.

Content was never the constraint. If a share is refused, look for encoded blobs,
not for something to reword.

A fresh Doc, shared before opening, still locks — the bug is account-level for my Pro account. It also hits chat-made Claude Docs on Pro.

For the specific bug in this thread: several people above already isolated it to inline SVG inside a data: URI (raw, percent-encoded, or base64) anywhere in the published HTML, even inside a vendored library (Shopify's polaris.js resizer grip, Mermaid's own SVG-builder output). The scanner that gates the public toggle seems to treat that as a possible script payload and blocks sharing regardless of account or file size. The fix that's worked for people here: rasterize any inline SVG to PNG and republish. Also worth knowing: the version picker locks while sharing is on, so after a fix you need to flip access to "Only people with access" and back to "Anyone with the link" to force a re-scan, not just republish.

More generally, if you just need to get an AI-generated HTML page in front of someone without fighting a content scanner: push it to a GitHub Pages repo, drop it in Netlify Drop, or view a Gist via raw/githack. The usual problem with sending the raw .html file directly is the recipient's client shows source code instead of rendering it, and converting to PDF first "to be safe" tends to break the layout or any JS/mermaid rendering. Then if you need to fix one typo, going back to the AI to regenerate costs time and tokens and can quietly change other parts of the page too, so you end up with a pile of versions and no clear "final" link.

Disclosure, we built one of these: NOS Workspace (https://nos-workspace.com/?utm_source=github&utm_medium=comment) — paste the HTML and it stays as a page at one link, you can click text to edit it directly, viewers open the link with no account needed, edits keep the same URL with version history, and you can turn the link off later. Free tier is 3 share links with a small badge.