free html server hosting

what “free html server hosting” actually means

an html file on your computer is invisible to everyone else. a browser can open it, but only the browser on that machine — a file:// path cannot be sent to anyone, and on a phone it is close to unopenable. what turns the document into something shareable is a web server: a machine that answers an http request for that file with its bytes.

historically, getting one meant renting hosting, pointing a domain at it, and uploading files over ftp. none of that has anything to do with your page. it is overhead you take on in order to get one url.

“free html server hosting” in 2026 almost never means being given a server. it means someone else runs the server and lets you put a document on it — and the useful distinctions between the options are not price, but how long the page lasts, how much ceremony stands between you and the url, and whether anything other than a browser can publish to it.

the question is rarely “where can i get a server”. it is “how little can i do and still have a link”.

ephemeral hosting vs permanent hosting

free hosting splits into two shapes, and picking the wrong one is what makes people think free hosting is a hassle.

ephemeral hosting gives you a url that expires by itself. there is no account, no dashboard, and nothing to clean up later — which is exactly right for a preview, a demo, a page you are sending to one person, or the hundred small artifacts an ai assistant produces in a week. the page you were going to delete on friday deletes itself.

permanent hosting keeps the page until you remove it. that is what you want for anything with a life beyond the conversation: a portfolio, a link page, a tool you use weekly, a document you will send again next quarter.

the second column is not an upsell of the first — it is the same page, after you decided it was worth keeping. claiming never changes the url you already sent.

who zero-config publishing is for

zero-config means there is no project to create, no framework to choose, no build to configure and no deploy to wait on. that is worth very little if you are shipping a product, and worth a great deal if the artifact is smaller than the setup it would otherwise require.

the common thread: the page is finished and the only thing missing is a url. the moment publishing takes longer than making the thing did, most of these pages simply never get shared.

workflow 1 — instant publishing by drag and drop

the fastest path, and the one that needs nothing installed and no credential at all. it works on a phone: tapping the drop zone opens the file picker.

1. 01

   drop the file

   drag your .html file onto the uploader, or tap it to pick a file. any filename works — nothing has to be renamed to index.html.

2. 02

   take the url

   the page is live as soon as the upload finishes. no build, no deploy step, no waiting for a cdn.

   https://htmlshare.net/p/abc123

3. 03

   decide whether to keep it

   the link works for 24 hours as published. if the page turns out to be worth keeping, claiming it with a free account removes the expiry entirely — same url.

workflow 2 — publishing from the api or the command line

if the html is produced by a script, a build step, or a job that runs without you, the same hosting is one http request. no sdk, no key required:

curl -X POST https://api.htmlshare.net/v1/publish \
  -H "content-type: application/json" \
  -d '{"html":"<!doctype html><h1>hello</h1>"}'

the response carries the public url, a siteId, an expiresAt, a manageToken (the only proof of ownership — keep it if you want to edit or delete the page later) and a claimUrl that turns the page permanent.

to publish a file you already have on disk, send its contents as the field:

curl -X POST https://api.htmlshare.net/v1/publish \
  -H "content-type: application/json" \
  --data "$(jq -Rs '{html: .}' index.html)"

with an api key on the request, publishes are permanent from birth, tied to your account, and can take a custom url segment instead of a random id. the same endpoints update a page’s content in place, so a nightly report can overwrite yesterday’s at a url you have already circulated.

full api reference — endpoints, keys, limits →

workflow 3 — letting an ai agent publish for you

this is the case free html hosting was quietly reinvented for. an agent writes a complete page in seconds and then has nowhere to put it, so the output comes back as a wall of markup in a chat window, or a file in a sandbox you cannot open on your phone.

connecting the mcp server gives the agent a publish tool of its own — it makes the page, publishes it, and hands you back a link:

{
  "mcpServers": {
    "htmlshare": { "url": "https://api.htmlshare.net/v1/mcp" }
  }
}

the mcp server requires an account, so pages published through it are permanent and owned from the moment they exist. agents that cannot hold a credential can still publish anonymously over the rest api above, and relay the claimUrl to you so the page can be kept.

connect the mcp server →

three things people actually host this way

a demo an ai just built. you asked chatgpt or claude for a working prototype and got a single self-contained html file back. drop it in, send the link to the person who asked for the demo, and let it expire on its own if the idea goes nowhere — or claim it if it doesn’t.

a d3 or chart.js visualization. a chart that needs javascript is not a screenshot and not a spreadsheet. the page is served as authored, so the script runs, the tooltips work, and the recipient interacts with the real thing rather than a picture of it. the data can be inlined or stored next to the page as a file.

a prototype link in a ticket, a deck, or a thread. a url pastes into jira, notion, a slide or a slack message and stays clickable for everyone who reads it later — which an attachment does not. if the prototype is going to be reviewed for months, claim it; if it is a tuesday’s idea, let the 24-hour window do the tidying.

what free includes, and where it stops

free hosting is only useful if you know its edges before you rely on it. these are htmlshare’s:

included. unlimited anonymous publishing with no account, 10 mb per document, any filename, images, fonts, css and js stored alongside the page, and the document served exactly as you wrote it — no sandbox, no rewriting, scripts and localStorage working. free pages carry one small dismissable attribution badge.

where it stops. one html document per page, not a multi-page site with a build behind it. every page is public to anyone with the url, and the only access control that exists is a password on a paid page, set from the dashboard — a gate, not secrecy. anonymous publishing is rate limited per ip (10 pages per 15 minutes, 500 per day), which no ordinary use meets. and an unclaimed page leaves public view after 24 hours, whether or not it was the one you meant to keep.

nothing here needs a card, and there is no trial to run out. if a page needs to stay, the thing that keeps it is a free account, not a paid one.

when to make a free account

publish first. the account is worth making at the point where one of these is true, and not before:

you sent the link to someone and the page needs to still be there tomorrow. you want a readable url instead of a random id. you publish often enough that having your pages in one dashboard beats hunting through sent messages for links. or an agent is publishing on your behalf and you would rather own those pages from the start than claim each one.

it is one email address and a magic link — no password, no card. claiming a page you already published keeps its existing url, so nothing you have already sent breaks.

frequently asked