How to share an HTML file (the one your AI just made you)
Claude or GPT handed you a working HTML file — now what? How to turn it into a shareable link in 60 seconds, where to actually host it, why it shows as code in Slack and Docs, how the person you send it to opens it, and the one thing none of it solves yet: collaboration. From an agency that ships these every week.
To share an HTML file as a working webpage, you host it online to get a link — drag it onto a free service like Netlify Drop or Tiiny.host and you'll have a shareable URL in under a minute. Sending the raw file usually disappoints: email and Slack show it as code or strip it, and a cloud-drive link (Google Drive, OneDrive, Dropbox) often displays the raw markup instead of the page. The fast path is drag-and-drop hosting; the durable path is GitHub Pages, Cloudflare Pages, Vercel, or Supabase; and if the recipient just needs to open it locally, you zip the file with its assets and tell them to open index.html in a browser. The one thing none of these solves yet is real collaboration — commenting and co-editing the way Google Docs does — and that gap is the whole reason this is harder than it should be.
Why you suddenly have a folder full of these files
A year ago, almost nobody who wasn't a developer had a loose .html file on their desktop. Now everybody does, because Claude and ChatGPT hand them out like candy. You ask for a budget calculator, a one-page proposal, a dashboard, an interactive report — and ninety seconds later you have a single file that looks genuinely good and actually works.
Here's the uncomfortable truth about why people love them so much: it's not that HTML is technically superior. It's that the alternatives have started to feel drab. A PowerPoint deck or a Google Doc looks today the way it looked in 2014, and the thing the AI just generated looks like a small custom website. Given the choice between a tired template and something that feels bespoke and took no time to make, people pick the bespoke thing. That's the actual engine under all of this — an aesthetics arbitrage. Tools like Gamma have noticed and now pitch themselves as the alternative to PowerPoint and Slides, letting you spin up websites and docs instead of decks. Search interest tells the same story: queries for "claude artifact" have roughly doubled in the last year, and "netlify drop" — a free, drag-and-drop way to put one of these files online — is up more than tenfold.
So the demand is real and it's accelerating. The problem is that the file you were handed is a beautiful thing with nowhere to live.
Why the file doesn't "just work" when you try to share it
This is the part nobody warned you about, and it's worth naming because it's the source of all the friction: the artifact last mile. The AI solved the hard part — making the thing — and left you the last, unglamorous step of getting it in front of another human, which turns out to be where everything breaks.
Try the obvious moves and watch them fail. Email it, and most mail clients either strip the HTML or show your recipient a wall of raw code, because email was never built to render an attached webpage. Drop it in Slack, and you get a file that previews as nothing and downloads as something most people don't know what to do with. Paste a Google Drive or OneDrive link, and — this is the one that catches everyone — the file frequently opens as raw markup rather than as the page, because cloud storage serves it as text, not as a website. Google's own AI Overview, when you ask it how to share an HTML file, now flags this exact thing as a "critical constraint." When the search engine's robot is warning you about the same wall you just hit, you know it's structural.
None of this means the file is broken. It means a .html file is a webpage without a web server, and a webpage needs an address before anyone else can really see it. Everything below is just different ways of giving it one — sorted by how much effort you want to spend.
The fast path: drag-and-drop hosting (free, no account, ~60 seconds)
If you just need a link to send someone right now, use a dedicated single-file host. You drag the file in, you get a URL, you're done — no terminal, no account in most cases, no understanding of "deployment" required.
Netlify Drop is the cleanest version of this. Go to the Drop page, drag your file or your whole project folder onto it, and it returns a live, shareable URL instantly. This is the "buy" option in disguise — it's free, but you're trading a few constraints (the link is on their domain, it's public, permanence varies) for zero effort. Tiiny.host does the same with a friendlier on-ramp: pick a subdomain name, drag your HTML file (or a ZIP if it has separate CSS and images), and publish. PageDrop lets you paste raw code or upload the file for a quick public link. All three turn "I have a file" into "here's a link" faster than it takes to write the email you were going to attach it to.
The honest caveats: these links are public unless you pay, they live on a shared domain unless you bring your own, and "free" tiers come and go. For sending a client a working prototype this afternoon, none of that matters. For something you need to rely on for a year, read the next section.
The durable path: where the file should actually live
When the artifact is something you'll maintain, update, or be a little proud of, host it somewhere you control. This is the "build" half of the decision, and it's a short ladder.
GitHub Pages is the sweet spot for most people who want permanence without paying. Create a public repository, upload your file as index.html, flip on Pages in the settings, and GitHub serves it at a clean, free, durable URL. The reason this matters beyond hosting is the reason it's worth learning at all: the file now has a home with a history — every change is tracked, nothing gets lost, and you can come back to it in six months and know exactly what it is. That's a bigger idea than this article, and it's the subject of its own piece, but it starts here.
Cloudflare Pages and Vercel are the next rung — still free for this kind of thing, a little more capable, and built for files that grow into small projects. Supabase enters when your beautiful static file starts wanting a database behind it. We run client systems across this whole ladder, and the rule we use is simple: buy (drag-and-drop) until the thing proves it deserves to be built; then build it somewhere with a history. It's the same build-vs-buy logic we apply to everything in the Automaton stack.
One genuinely useful thing almost nobody knows: if you host on Vercel, collaborators can leave comments directly on the deployment through the Vercel Toolbar — pin a note to a spot on the page, reply, resolve. It is the closest thing that exists today to commenting on a live artifact. The catch is that it's built for engineering review: the person commenting generally needs access to the project and to be logged in, and approximately no one outside a dev team knows the feature is there. Which is a perfect segue to the thing this whole category still hasn't solved.
The honest asterisk: the one thing Google Docs still does that your beautiful file can't
Here is where I have to be straight with you, because the rest of the internet won't. We lost a deal over exactly this.
On an $800K-plus engagement for a major client — kept anonymous — the lead deliverable was one of these HTML files. It was good. But there was no way to comment on it, so we did what everyone does: we got on a call and walked through it line by line while the lead literally took notes on everyone's spoken feedback, then went back afterward and rebuilt the file with Claude. We did that loop more than once. By presentation day there were four versions of the file floating around Slack and no one could say with certainty which one was final. We lost the RFP — for not showing concretely enough what the finished thing would look like. And the thing I keep coming back to is that almost none of that failure was about the work. It was about the handoff. If the feedback had been async comments sitting on the file itself, the comments would have been the change log. If the file had lived in GitHub, each of us could have worked in parallel — each person, with their own AI, improving the specific pages they owned — instead of funneling every edit through one person on one call. With a real collaboration layer, it is not hard to imagine that one going the other way.
That's the asterisk on every cheerful "just host it and send the link" article, including the top half of this one: the artifact last mile has two halves, and only one of them is solved. The handoff — getting the thing to a viewable link — is a solved problem, and you just read four ways to do it. Collaboration — commenting, co-editing, knowing which version is real — is not. This is the half Google Docs quietly nailed a decade ago and never gets credit for, because it's boring. A Doc is uglier than your artifact and infinitely better at being worked on by more than one person. Beautiful-but-isolated versus drab-but-collaborative is the real trade you're making, and most people don't realize they're making it until they're four versions deep in Slack.
The current half-answers are all partial. Vercel comments are the closest, and they're dev-flavored. GitHub gives you real parallel editing and perfect version history, but it asks non-developers to learn a new world. CodePen and JSFiddle let people see and comment on the code, which is not the same as collaborating on the rendered thing. And "just paste it back into a Google Doc" works, except it throws away the entire reason you made an artifact instead of a Doc. The honest verdict for right now: if the job genuinely needs several people commenting and co-editing, the artifact still loses to the Doc, and you should pick the tool to the job rather than the tool to the vibe.
Where this goes (and it's worth saying out loud)
So here's the opinion, clearly marked as one. Whoever builds the Google-Drive-grade sharing, commenting, and collaboration layer for AI-generated HTML artifacts is going to get a lot of traction — because the demand is already here, the files are already beautiful, and the only thing missing is the boring collaborative plumbing that made Docs win. There's a real, near-term window for a product that makes commenting on a hosted artifact feel exactly like commenting on a Doc, for people who have never heard of a pull request.
The honest catch, the one any builder should price in: that window closes the day Google, Anthropic, or OpenAI decides this is a feature and ships it natively. When the same company that generates your artifact also hosts and shares it with comments built in, the standalone tool gets absorbed. So it's a land-grab with a clock on it. Which is exactly the kind of bet we find interesting — and exactly the kind we'd tell a client to size honestly before they run at it.
When you shouldn't host it at all — just send the file
Sometimes the right move is the low-tech one. If your recipient only needs to open the thing on their own machine and you don't need a link, send the file directly — you just have to send it so it actually opens as a page.
The trick is assets. If your artifact is truly one self-contained .html file, you can attach it and the person can open it in any browser. If it relies on separate CSS, images, or scripts, put the HTML file and all of its asset folders into one folder, zip that folder, and send the zip. Tell the recipient to extract it completely first, then double-click index.html, which opens it in their default browser. The single most common support question on the receiving end — "you sent me an HTML file and it's just a page of code" — is almost always someone trying to read the file in a text editor instead of opening it in a browser, or viewing it straight out of a cloud-drive preview. "Download it, then open it in Chrome or Safari" resolves it nine times out of ten.
The wrinkle: when it's not actually one HTML file
A growing share of what these tools produce isn't a single static file — it's a React or JSX component, or an artifact that quietly depends on other things to run. The tell is that double-clicking it doesn't show you the finished page. Those need a build step before they become a plain file you can host the easy way, which pushes you toward the GitHub/Vercel end of the ladder rather than the drag-and-drop end. If your "file" won't open by itself in a browser, that's your signal that you're in build-path territory, and it's worth knowing that before you promise someone a link in five minutes.
The whole decision, in one table
| Method | Effort | Permanence | Privacy | Custom domain | Collaboration |
|---|---|---|---|---|---|
| Netlify Drop / Tiiny / PageDrop | ~60 sec, no account | Low–medium | Public (free) | Paid | None |
| GitHub Pages | Low (learn once) | High | Public (free) | Yes | Parallel edits + full history (dev-flavored) |
| Cloudflare Pages / Vercel | Low–medium | High | Configurable | Yes | Vercel: deployment comments (logged-in) |
| Supabase | Medium | High | Configurable | Yes | None (it's for data, not comments) |
| Send the file / zip | Lowest | N/A (it's a copy) | Private | N/A | None |
| Paste back into a Google Doc | Low | High | Configurable | N/A | Full — but you lose the artifact |
Read that last column top to bottom and you can see the whole argument of this piece: every path that keeps the artifact beautiful gives up real collaboration, and the only row that nails collaboration is the one where you throw the artifact away. That's the gap. Until someone closes it, the move is to be honest about which half of the last mile your particular job actually needs.
Frequently asked questions
How do I share an HTML file as a link?
Host it. The fastest way is a drag-and-drop service: go to Netlify Drop or Tiiny.host, drag your file (or a ZIP of your file plus its CSS and images) onto the page, and you'll get a public, shareable URL in under a minute with no account and no code. For something you'll maintain long-term, put it on GitHub Pages, Cloudflare Pages, or Vercel instead, which give you a durable link you control. Sending the raw file by email or pasting a cloud-drive link usually fails, because those show the file as code rather than rendering it as a page.
Why does my HTML file show up as code in Slack, email, or Google Drive?
Because those tools serve the file as plain text instead of running it as a webpage. Email clients largely don't render attached HTML, Slack treats it as a generic file, and cloud-storage links often display the raw markup. An HTML file only becomes a viewable page when it's served by something that treats it as a webpage — which is exactly what a host does. To make it viewable, host it and share the resulting link rather than the file itself.
Can people comment on or collaborate on an HTML file like a Google Doc?
Not really, not yet — and this is the genuine weak spot. There's no widely adopted equivalent of Google Docs commenting for a standalone HTML artifact. The closest thing today is hosting on Vercel, where collaborators who are logged in and have project access can leave comments directly on the deployment through the Vercel Toolbar, though it's built for developer review. GitHub gives you real parallel editing and version history but asks non-developers to learn it. If your job truly needs several people commenting and co-editing, Google Docs still wins on that specific axis — so match the tool to the job.
Where can I host an HTML file for free?
Plenty of good options. For instant, no-account sharing: Netlify Drop, Tiiny.host, and PageDrop. For a durable, free, controllable home: GitHub Pages, Cloudflare Pages, and Vercel all host static HTML for free at typical personal volumes. The fast services are best for "send this now"; the platform options are best for anything you'll keep, update, or attach to your own domain.
How do I open an HTML file someone sent me?
Download it first, then open it in a web browser — right-click the file and choose "Open with," then pick Chrome, Safari, Edge, or Firefox. If it looks like a page of code instead of a webpage, you're almost certainly viewing it in a text editor or in a cloud-drive preview; opening the downloaded file directly in a browser fixes it. If it arrived as a ZIP, extract the whole folder first, then open the file named index.html.
How do I share a Claude or ChatGPT artifact?
Download it from the chat first — most artifacts can be exported as an HTML file — then treat it like any other HTML file: host it on Netlify Drop, Tiiny.host, GitHub Pages, or Vercel to get a shareable link. If the artifact is a React/JSX component rather than a single static file, it may need a build step before it can be hosted as a plain page, which points you toward the GitHub or Vercel path rather than drag-and-drop.
Can I just turn the HTML file into a PDF to share it?
You can, and for a static, read-only artifact it's a reasonable shortcut: open the file in a browser and use Print to PDF. The trade-off is that you lose everything interactive — calculators, filters, anything that responds to clicks becomes a flat snapshot. If the value of the artifact is that it does something, a PDF guts it, and you're better off hosting it for a link. If it's essentially a nicely designed read-only document, a PDF travels everywhere and previews in Slack and email, which a raw HTML file does not.
GitHub Pages or Netlify Drop — which should I use?
Netlify Drop if you need a link in the next sixty seconds and you don't care where the file lives. GitHub Pages if you'll maintain the thing, want a durable URL you control, and are willing to learn one new tool that also gives you version history and a real home for the file. A useful default: start on Netlify Drop to share it today, and move it to GitHub Pages once it proves it's something you'll keep.