To host an HTML file, upload it to a static hosting service, which stores the
file and serves it at a public address. Include every file the page references,
such as stylesheets, scripts, and images. Name the main file index.html so
visitors reach it without typing a file name.
Opening an HTML file on your own machine shows it only to you. The address
starts with file:// and points at your disk, so nobody else can reach it. To
share the page you need a host: a machine that is always on, holds your files,
and hands them to anyone who asks for that address.
What counts as "the page"
This is where most first attempts go wrong. Hosting guides say "upload your HTML file", and a page is rarely one file.
Open your HTML in a plain text editor and look for what it points at:
<link> for stylesheets, <script> for JavaScript, <img> for pictures, and
any fonts. Each of those is a separate file with its own path. On your machine
those paths resolve against your own folders, so everything looks right. Upload
the HTML on its own and every one of those paths breaks. The page arrives as
unstyled text, and it looks like the host failed when nothing failed at all.
Keep the whole folder together and upload it as a unit. The structure inside has to stay exactly as it was, because the paths inside your HTML are written against it.
Why the file is called index.html
index.html is the convention hosts follow for "show this when someone opens
the address with no file name after it". Name your main page that, and a visitor
reaches it by typing your address alone. Name it home.html and they get a
directory listing or an error until they type the file name themselves.
What a static host does, and where it stops
A static host stores your files and serves them as they are. Nothing runs on the server: no database, no application, no build step. That is why static hosting is fast, cheap to operate, and hard to break.
It is also the limit, and worth knowing before you choose. If your page needs to store what a visitor submits, hold a secret such as an API key, or run code that never reaches the browser, a static host alone will not do it. A contact form that emails you needs something to receive the submission. A page that charges money needs something the customer's browser cannot read. Those need a service behind the page, not a different way of uploading it.
Your options: four ways to host an HTML file for free
Every path below starts free and ends with a public address. They differ in what they ask of you first: an account, a repository, a drag into a browser window, or an agent that already has the folder.
GitHub Pages
Free static hosting served straight from a GitHub repository. You need a GitHub
account, and on the free plan the repository has to be public. Push the folder
with git, or upload the files through GitHub's web interface, choose the
branch to publish from, and the site appears under a github.io address or a
domain you own. It fits a portfolio, a project page, or anything you want to
keep beside its source code. The trade-off is that git becomes part of every
change, and GitHub's terms frame Pages as a project showcase rather than a
storefront; the comparison against Birta walks through
where that line falls.
Netlify Drop
Drag your finished folder onto the Netlify Drop page in a browser and it is live on a generated address within seconds. No git, no build settings. To keep the site and update it later you claim it with a free Netlify account. One thing worth knowing before you rely on that address: Netlify's own documentation now says a drop made without signing in is password-protected until you claim it, so what the anonymous drop actually hands over is not quite the link most write-ups describe. It fits a one-off page you need online right now. The trade-off is that Netlify is a developer platform, so every later update is either another manual drag or a move onto its git-based workflow, and the dashboard carries far more than a single page needs. Static.app works the same drag-and-drop way; the comparison with Birta is about who maintains the site after the first upload.
Tiiny Host
Upload a zip or a single HTML file and get a link under tiiny.site. There is a
free tier with limits, it can connect a domain you own, and its built-in
analytics go deep. It also shares PDFs and other documents, so it fits someone
who wants one place for files of every kind, not just a website. The trade-off is that the free address
belongs to Tiiny Host, so it cannot move with you if you change hosts later;
the side-by-side with Birta covers versions, analytics, and
what a migration involves.
Birta
Built for the case where an AI agent made the page. You connect the agent you already use, such as Claude Code, Cursor, Codex, or ChatGPT, and it sends the folder to Birta and hands back the live address. Every successful publish is kept as a version you can roll back to. The free tier covers up to 50 projects of 25 MB each, keeps a small Birta badge on the page, and holds back your own domain for the paid plans. It fits a page an agent built and will keep changing. The trade-off is that Birta only serves static sites, and if no agent is in your workflow, one of the three options above is the more direct route.
Not sure which fits? The seven questions hiding inside "where do I host this" sort them out.
Publishing from a coding agent
If a coding agent built the page, it can publish it too. The agent packages the finished folder with the referenced files already in the right places, which removes the failure above. Then it sends the folder to the host and reports the live address. The starting point matters less than it seems, though if the page currently lives inside a Claude artifact there is a step before this one. And if there is no finished page yet, only a folder of notes and images, the agent can write the pages first and publish those.
Changes work the same way. You describe what to change, the agent edits the page and publishes again, so there is no separate upload step to remember and no stale copy sitting on the host. Each published version is kept, so a change that turns out wrong can be rolled back rather than rebuilt.
That last part is worth checking wherever you publish, because it does not come with the connection. InstaPods keeps a deploy history too, for example, but in its dashboard rather than in the tools its connector hands an agent.
Once the page is live, point your own domain at it and visitors see your name in the address. How the agent connects in the first place is one open standard rather than a separate integration per tool.
If that sounds simpler than what you have been told deployment involves, it is worth reading why the usual answer is about something else entirely.
Send the file, get a live address
Point your agent at Birta and publishing an HTML file works the way it should have from the start.