The artifact works in the chat, publishing succeeds, and the link opens to nothing. Three different failures produce that same white screen, and one thirty-second check tells you which one you have.
You published the artifact. Claude said it worked. You opened the link to check, or your client did, and there it is: a white screen. No error, no message, nothing to click. Just an empty page where the work should be.
The frustrating part is that the artifact still renders perfectly in the chat. So the work isn't gone — something between "it exists" and "they can see it" quietly failed, and a blank page is the least informative way a browser can tell you so.
Three genuinely different things produce that identical white screen. They need opposite responses, and guessing wrong wastes an afternoon.
Before changing anything, open the published link in a private / incognito window, on your own computer.
That window has no session, no cookies, and no account — which is exactly the condition your recipient is in. It turns a vague "it doesn't work for them" into a fact you can act on.
Then, in that same window, do two things:
Ctrl/Cmd + U). You're answering one question: did a document arrive at all?F12, or right-click → Inspect → Console). You're looking for the first red line.Those two answers put you in exactly one of the three branches below.
The document arrived. The browser started reading it and stopped. This is the most common of the three, and the console will usually name the cause in a single line.
What it's almost always about: the artifact is less self-contained than it looks. Inside the chat, Claude renders it in an environment that already has things loaded. On a published page it's a plain document in a plain browser, and anything it merely referenced now has to actually arrive from somewhere.
The usual suspects, in rough order of frequency:
<script> and everything after it never runs.fetch() to an API that worked from the chat's context and doesn't from a plain page — a key that isn't there, or a service that won't answer a browser request from an unknown origin.The fix isn't to republish; it's to make the file genuinely self-contained. The five things that most often stay external — and how to inline each — are laid out in the Claude artifact export checklist. Working through that turns "apparently self-contained" into actually self-contained, which is also what makes the file portable to anywhere else.
If the private window renders it correctly but your recipient still sees nothing, you don't have a rendering problem. You have a scoping problem: the link assumes whoever opens it is you, inside the account or session that built the thing.
This is its own failure mode with its own set of causes across the different AI tools, and it's covered in full in why your AI share link won't open for them. The short version: a link that works inside the tool and dies outside it was a window into your session, not an address for the work.
Worth ruling out early, because it looks identical from your side and needs a completely different fix.
If the source in the private window is essentially nothing — no markup, no trace of what you built — then the document never got served. Your file isn't the problem, because your file never made it into the response.
This one is genuinely not yours to fix. There are public bug reports describing stretches where published artifacts returned a blank screen broadly, including minimal test cases small enough that author error wasn't a plausible explanation. The tell is easy: make a fifteen-line artifact, publish it, open it in a private window. If that is blank too, you've stopped debugging your own work.
When you're in this branch, retrying the toggle is the one thing that reliably doesn't help. Check the platform's status page, and in the meantime deliver the work by a route that doesn't run through the publishing pipeline at all.
All three branches share one exit: stop waiting on the publish button and get the work out as a file.
Ask Claude for the artifact as a single self-contained HTML file, download it, and host that file on a link you control. You're then serving something you hold, which changes a few things at once — the link survives the conversation being deleted, it doesn't depend on anyone's publish pipeline being healthy today, and you can replace the contents later without reissuing the URL.
If the artifact refuses to publish at all rather than publishing blank, that's a related but distinct error with its own diagnosis — see what "this version can't be shared publicly" actually means.
Being precise here matters more than being encouraging, because "host it somewhere else" is good advice for exactly one of the three causes.
It helps when the artifact went blank because something external got blocked. Some hosts serve user-uploaded HTML under a strict content policy that refuses external scripts — which turns any artifact that loads a CDN library into a white screen. miinideck doesn't do that: the viewer allows external scripts, styles, fonts, and API calls, on the reasoning that the person who wrote the page is the person uploading it. An artifact that pulls Chart.js or Tailwind from a CDN runs.
It doesn't help when the artifact needs a server. Authenticated outside users, a database it writes to, a secret key that can't sit in the browser — that isn't a page, it's an application, and it needs a platform that runs your backend. Vercel and Netlify are the right tools for that job and they're good at it. A static host doesn't replace them.
And it doesn't help when the code is simply broken. A genuine JavaScript error throws on every host equally. Fix the file first; the hosting question comes after.
For the case where it does fit — a finished, self-contained page that specific people need to open — putting it on a private link is a drop and a paste. The link is unguessable and not indexed by search, so it goes to the people you send it to and nowhere else. Password and expiry are available on every account tier, and one always-on link is included free; Free covers files up to 10MB, Solo ($4.99/mo) 25MB with permanent links, Studio ($14.99/mo) 50MB with a custom domain.
A blank published page is one symptom with three unrelated parents, and the private window tells you which parent you have before you change anything:
| What you see in a private window | What broke | What to do |
|---|---|---|
| Your markup in source, white screen | The artifact's own JS died | Read the console; inline what's external |
| Renders for you, blank for them | Link is scoped to your session | Deliver it as a file on an open link |
| Empty source, nothing served | Upstream of your file | Check status; export and route around it |
The one habit worth keeping: check the link the way your recipient will, in a window that isn't logged in as you, before you send it. It costs thirty seconds and it catches two of the three before anyone else sees a white screen with your name on it.
The message is about Anthropic's side, not yours, and it usually clears on its own. The risk isn't the outage — it's what people press while waiting. Here's the safe order of operations, and how to get the work out of the artifact while you wait.
You built something in Claude, came back weeks later, and it's gone. Usually it isn't deleted — it's sitting inside a conversation you can no longer find. Here's how to get it back, and the one case where it really is unrecoverable.
Artifacts stop appearing and every guide says the same four generic fixes. Here's the order that actually separates a setting on your side from an outage on theirs — starting with the one documented cause that produces total failure.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.