Claude Code wrote the file. Now a teammate or a client has to see it working — and the obvious options each solve a different half of that. An honest split across GitHub Pages, Notion, paste-style hosts, an internal server, plain email, and a private link, judged against the five things people actually ask for.
Claude Code writes the file into your working directory and it opens fine when you double-click it. The awkward part is the next step: someone else has to look at it — a teammate, a client, a person who is going to make a decision from it — and file:///Users/you/project/index.html means nothing on their machine.
The options people reach for are not really competing. They each solve a different half of the problem, and the reason the choice feels hard is that the halves are rarely named out loud.
Whenever this question gets asked properly, the same list appears. It is a good list, so it is worth using as the scoring rubric rather than inventing one:
No single option wins all five. What follows is which one wins which.
Wins: version history. Comfortably.
Nothing else here is close. Every save is a commit, every change is a diff you can read, branches let two versions exist at once, and the whole record is yours to take elsewhere. If requirement 3 is the one that actually keeps you up, stop reading comparisons and put it in a repo.
Pages then publishes it, assets and all, at a stable address. Requirements 1 and 4 come along free.
Where it falls down is requirement 5, and it falls down hard. "Just look at the PR" is where the conversation ends with a reviewer who does not write code. Pages setup is also a one-time cost that someone technical has to pay, and on the free plan the repository is public — which collides with requirement 2 whenever the work is a client's.
We wrote the longer version of this trade-off in GitHub Pages vs a private link.
Wins: the wrapper around the artifact.
If what you need is context — here is what this is, here is what changed, here is what I want you to look at — Notion is very good and the reviewer probably already lives there.
It is not an HTML host, and it is worth being blunt about that rather than fighting it. Embedding a working page with its own scripts and styles inside a Notion page is not a reliable operation, and the failure is silent enough that you find out from the reviewer. Notion holds the explanation; something else has to hold the artifact.
Wins: time-to-first-link.
For one file that you will never touch again, this is the correct amount of infrastructure and everything else on this page is ceremony. Drag, drop, copy URL, done, no account.
The friction shows up against requirements 3 and 4. Many of them mint a new URL per upload, which is completely fine on day one and quietly awful by Thursday, when the link in your client's inbox is showing version one and you are on version four. If you know in advance that the thing will change, that is worth weighting more heavily than the ten seconds you save on the first upload.
Wins: when it already exists.
If your company runs nginx and the audience is on the intranet, dropping the folder into a served directory is fast, free, and answers requirements 1, 2, and 4 without a signup. This is a real answer and it comes up more often than the tool-comparison genre admits.
It stops being an answer the moment the reader is outside — a client, a contractor, someone on their phone at home — or the moment "we should stand one up for this" enters the sentence.
Wins: nothing to set up, and it is honestly underrated.
If the page is genuinely self-contained — CSS, JS, and images inlined, nothing referenced from outside — attaching it works, and for a one-shot look it is hard to justify anything more.
Two failure modes, both worth knowing before you rely on it. Some mail clients and mobile viewers render the markup as text instead of showing the page, and you will not find out until they tell you. And an attachment is a copy: the moment you fix something, the version they have is wrong and there is no way to reach it.
Already have the HTML? You can try the private-link shape on this page in about ten seconds — no account needed to look at what comes out.
Wins: requirements 1, 2, 4, and 5 — the "someone else has to look at this and it is going to change" cluster.
This is the shape miinideck is built around, so read this section knowing that.
Drop the file or the zipped folder and you get an unguessable URL. Assets come along because the whole bundle is unpacked and served with its paths intact, so requirement 1 stops being your problem. The page is off search by default and the address is not guessable, which is the working answer to requirement 2. Updating replaces the contents at the same address rather than minting a new one, so the link you already sent stays correct — requirement 4. And the reviewer opens a URL with no account and no git, which is requirement 5.
There is also a review mode: anyone with the link can leave comments pinned to the page without signing up, and you can export the thread as markdown to hand straight back to Claude. That covers the loop the question is usually really about — replacing a published file without git and getting notes back from someone who does not have a terminal open.
Where it loses: requirement 3. There is no revision graph here. The database keeps room for versions, but there is no UI that lets you browse them, diff them, or roll one back — so if you need to answer "what did this look like on Tuesday," this is not the tool that answers it, and GitHub is. That is a real gap, not a positioning statement.
| Assets intact | Not public | Version history | One stable URL | Review without git | |
|---|---|---|---|---|---|
| GitHub + Pages | yes | paid plans only | best in class | yes | no |
| Notion | not an HTML host | yes | page history, not code | yes | yes |
| Paste-style host | varies | usually public | no | often a new URL each time | yes |
| Internal server | yes | inside the network | no | yes | yes, if they're inside |
| Email the file | only if inlined | yes | no | no link at all | yes |
| Private link | yes | yes | no | yes | yes |
Ask what happens after they open it.
Nothing happens — you were proving a build renders, settling something in a thread, checking your own work on a phone. Email it or paste it somewhere. Anything more is overhead.
They reply, and it changes — you are in the loop this whole question is about. You want one address that survives the iteration and a reviewer who does not need an account.
It becomes a project — other people will edit it, it needs a real history, it will outlive this week. Put it in git. That is what git is for.
It needs a backend — a database, an API key that cannot sit in the browser, auth. None of the six options above are the answer. Reach for Vercel, Netlify, or Cloudflare Pages and give it a real runtime.
The mistake worth avoiding is not picking the wrong one. It is picking on time-to-first-link — because that is the only dimension you can feel in the first minute, and it is the one that matters least by the third revision.
GitHub Pages publishes a public, git-tracked site to the open web. A private unguessable link delivers a self-contained page to specific people. Here is the honest split — by who reaches it, what the URL is for, and where the work lives — so you pick the right one instead of bending one to fit.
Static hosts are metered on the assumption a human edits a few times a day. An agent doesn't work that way. Which hosts count builds, which count deployments, which count nothing — and where the bill actually comes from.
Cloudflare Pages is a public, global CDN site — built to be found and to scale. A private link is built to reach a named audience and nobody else. They solve opposite halves of "I made a page, now what." Here's the honest fit for each, where the backend boundary sits, and how to pick in one question.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.