How to host an HTML file online for free (4 ways that work)

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, and 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. To share the page you need a host, a machine that is always on, holds your files, and hands them to anyone who asks.

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. Though when an agent wrote it, it usually is: 70.5% of the sites we measured are a single file.

Open your HTML in a text editor and look for what it points at: <link> for stylesheets, <script> for JavaScript, <img> for pictures, any fonts. Each is a separate file with its own path. On your machine those paths resolve against your folders, so everything looks right. Upload the HTML alone and every path breaks: the page arrives as unstyled text and it looks like the host failed when nothing did.

Keep the whole folder together and upload it as a unit, with the structure inside exactly as it was, because the paths in 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. 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. 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 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 an account, and on the free plan the repository has to be public. Push the folder with git or upload 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. Fits a portfolio, a project page, anything you keep beside its source. The trade-off: git becomes part of every change, and GitHub's terms frame Pages as a project showcase rather than a storefront, which the comparison against Birta walks through.

Netlify Drop

Drag your finished folder onto the Netlify Drop page and it is live on a generated address within seconds. No git, no build settings, and you claim it with a free account to keep it. One thing before you rely on that address: Netlify's own documentation says a drop made without signing in is password-protected until you claim it, so what the anonymous drop actually hands over is not the link most write-ups describe. Fits a one-off page you need online now. The trade-off: every later update is another manual drag or a move onto its git-based workflow. Static.app works the same way, and 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. A free tier with limits, a domain you own can be connected, 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. The trade-off: the free address belongs to Tiiny Host and cannot move with you, and the side-by-side with Birta covers versions, analytics and migration.

Birta

Built for the case where an AI agent makes the page. Describe it in Birta's chat and its agent builds and publishes it, or connect the agent you already use, Claude Code, Cursor, Codex or ChatGPT, and it sends the folder and hands back the live address. Every successful publish is kept as a version you can roll back to. The free plan includes your own domain and keeps a small Birta mark on the page. Fits a page an agent built and will keep changing. The trade-off: static sites only, and for a file that is already finished one of the three options above is more direct. For one page that one person has to open today, skip the hosting question and share the HTML file as a link instead.

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. It packages the finished folder with the referenced files already in the right places, which removes the failure above, 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. Two starting points get their own walkthrough because what breaks in them differs: code you want to turn into a link, where the missing stylesheet is the usual failure, and a site that arrives as a ZIP archive, where it is the wrapping folder.

Changes work the same way. You describe what to change, the agent edits the page and publishes again, so there is no separate upload to remember and no stale copy on the host. Each published version is kept, so a wrong change rolls back rather than being rebuilt. Worth checking wherever you publish, because it does not come with the connection: InstaPods keeps a deploy history too, 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, and if that sounds simpler than what you have been told deployment involves, the usual answer is about something else entirely.

Common questions