Artifact fails public sharing with generic error, private viewing works fine

Additional confirmation: reproduced the identical error in a different browser and in incognito/private mode, ruling out any client-side caching or session-specific cause. The failure is consistent across browsers and sessions — this points to a server-side/platform-level constraint (size limit or CSP validation on public-share eligibility) rather than anything client-side.

Found what looks like the same bug already tracked elsewhere:

• #79824 — "This version can't be shared publicly" persists across republish and brand-new artifacts (exact same error message and symptoms as this issue)
• #78374 — related public-sharing block ("uses connectors" / "This version can't be shared publicly")

Both describe this as likely an account/session-level issue rather than per-artifact-version, which matches what we found here too: reducing the artifact from ~13.6MB to ~6.2MB (well under any documented size ceiling) did not resolve the sharing failure, and it reproduced identically across different browsers, incognito, and a completely fresh artifact URL. This suggests the earlier size/CSP theories in this issue are likely not the actual cause — probably safe to consolidate this as a duplicate of #79824.

Happened to me exactly the same also

Note: Below is output from Opus 5 Max, who suggested I be helpful and post this here:

Root cause found: an inline SVG data-URI in CSS silently blocks public sharing
I hit this same error and bisected it against the share check. The cause is not size and not
new Function — it's a data:image/svg+xml URI in the page's CSS. A page containing one
publishes fine and renders fine privately, but the public-share toggle always fails with the
generic message.
Since this issue's description lists "small data: URI SVG images" among its contents, I
suspect that's the actual trigger here rather than the 13–14 MB size.
Minimal reproducer
This ~200-byte page publishes, renders, but cannot be shared publicly:

<title>repro</title>
<style>
  :root {
    --grain: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='140' height='140'%3E%3Cfilter id='n'%3E%3CfeTurbulence type='fractalNoise' baseFrequency='0.9' numOctaves='3'/%3E%3C/filter%3E%3Crect width='140' height='140' filter='url(%23n)'/%3E%3C/svg%3E");
  }
  body { height: 100vh; margin: 0; background-image: var(--grain); }
</style>
<p>hello</p>

Delete the --grain line and the identical page shares successfully.
Bisection
Each row is a separate published artifact, changing one variable at a time. "Shares" = the
public-share toggle succeeds. Every row rendered correctly when viewed privately.
Page Bytes Shares
Plain text + CSS, no script 1,024 yes
Minified script + <canvas> + localStorage 1,638 yes
Plain text only 373,035 yes
Plain text only 392,026 yes
Plain text only 700,071 yes
Large ordinary script (number table + 2 functions) 660,085 yes
Web Audio graph (oscillator, gain, biquad, convolver, waveshaper, compressor) 2,380 yes
App markup + plain CSS 1,150 yes
App markup + app's full stylesheet, no script at all 73,879 no
The passing 1,150-byte page + only the --grain data-URI line 1,451 no
The failing 73,879-byte page with only --grain set to none 73,628 yes
The full app (minified) 380,637 no
The full app (unminified, i.e. larger) 648,345 no
The last three rows make the data-URI both sufficient (adding only that line to a passing
page breaks it) and necessary (removing only that line from a failing page fixes it).
Ruled out by test: page size, script volume, minification, Web Audio, <canvas>,
localStorage, markup, and page content generally. The page in question contains no eval,
new Function, atob, Blob, Worker, WebAssembly, <iframe>, or any network call.
Why this is worth fixing
The artifacts documentation actively recommends
the construct that breaks sharing — it says images should be "embedded as data URIs" and to
"prefer SVG or HTML/CSS for diagrams over embedded raster images." So the documented happy
path silently produces unshareable artifacts.
If rejecting SVG data-URIs is deliberate (SVG can carry <script>, so it's a reasonable thing
to be strict about), then the gap is in reporting rather than in the check itself. Either way,
the failure is currently undiagnosable from the UI: the message names no cause, and the two
suggested remedies — "publish a new version or change the shared version" — cannot help, since
every version of the page carries the same CSS.
Suggested fixes, in order of usefulness:
Name the offending construct in the error ("this page can't be shared publicly because its
CSS embeds an SVG data-URI"). That alone turns hours of bisection into a one-line fix.
Document the public-share content restrictions alongside the CSP notes, since they're
evidently stricter than the private-render rules.
Consider permitting script-free SVG data-URIs. The reproducer above is a feTurbulence
noise filter — a purely decorative texture with no script content.
Workaround
Generate the texture into a <canvas> at runtime and assign it to the same custom property,
so no data-URI appears in the published file:

const cv = document.createElement('canvas');
cv.width = cv.height = 140;
// ...draw noise into cv...
document.documentElement.style.setProperty('--grain', `url("${cv.toDataURL('image/png')}")`);

The runtime-generated data-URI is fine — only its presence in the published file matters. After
this change the same page shared successfully.
Note on #79824
That report describes the same error message on a Markdown file with a Mermaid fence, which
wouldn't contain an SVG data-URI at publish time. It may be a different cause, so it's probably
worth keeping the two separate until someone confirms.