When the page is a folder rather than one file, the hosting question changes and so do the ways it breaks. Which free hosts take a ZIP, what happens to your folder structure once they unpack it, and the four failure modes that account for almost every broken zipped site.
Hosting one HTML file is a solved problem. Hosting a folder — a page plus its stylesheet, its scripts, its fonts and a directory of images — is the same question with a different set of ways to go wrong, and almost none of the "free HTML hosting" lists cover it.
The hosts converged. Drop a ZIP on any of them and you get back a URL with your site behind it, and the differences in how they unpack are small enough that they should not drive your decision.
What should drive it is the same fork that governs single-file hosting: is this bundle meant to be found, or meant for specific people? A documentation site, a portfolio, a public demo wants reach. A client deliverable, an internal report, a design review wants the opposite — it should open for the people you send it to and stay out of search results. The full free-hosting survey works through that fork with the caps and prices in one dated table; everything below assumes you have already picked a side.
| Host | Takes a ZIP | Default posture | Sign-up | Best fit |
|---|---|---|---|---|
| Cloudflare Drop | Folder or archive | Public, indexed | None to start; claim within 60 minutes | A build you need live immediately |
| Static.app | Yes, or a folder | Public, indexed | Yes | A small public site with no build pipeline |
| Tiiny.host | Yes | Public, indexed | Yes | The simplest public multi-file page |
| EdgeOne Makers Drop | Yes | Public, indexed | Yes | A free tier with a CDN behind it |
| Netlify Drop | Folder-oriented | Public, indexed | None to publish as-is; sign in to get a build step | Dragging a build folder without touching git |
| GitHub Pages | Via a repo, not an upload | Public, indexed, source readable | Yes | A public site that outlives everything else here |
| miinideck | Yes | Private — noindex, unguessable URL | Free account, or anonymous for one file | A bundle going to specific people |
Checked against each vendor's own pages: Cloudflare Drop on 4 September 2026; Static.app, Tiiny.host and EdgeOne Makers Drop on 2 September 2026; GitHub Pages on 10 August 2026; Netlify on 16 September 2026. Everyone sets their own limits and changes them without telling us — check the vendor's site for what is current.
This is the part worth the read, because it is the same on every host and nobody writes it down.
You have a directory called mysite. You right-click it and compress it. The archive now contains mysite/index.html and mysite/style.css — but your HTML says <link href="style.css">, which the browser resolves relative to the page, and the page is being served from one level above where the stylesheet actually landed. Result: the page loads, entirely unstyled, and every image is a broken icon.
This is the single most common ZIP hosting failure and it has nothing to do with the host being bad at its job.
Most hosts handle it by silently stripping the common top-level folder, and so do we — but only when every entry in the archive shares the same first segment, which is precisely the condition under which stripping cannot damage anything. An archive holding both mysite/index.html and a stray notes.txt at the root has no common wrapper to strip, so nothing is stripped and the paths stay broken.
The habit that makes this permanently go away: open the folder, select everything inside it, and compress the selection. Not the folder.
Every host needs to decide which page the URL opens, and the rules differ. Cloudflare Drop's documentation is direct about it: the HTML file must be named index.html. Ours is more forgiving but still a rule you would rather know than discover — a root index.html or index.htm always wins, and without one the shallowest HTML file in the bundle becomes the entry page, with ties broken alphabetically so the outcome is deterministic rather than a coin flip.
Deterministic is not the same as what you wanted. If your archive contains about.html and pages/home.html, the shallower one opens, and about.html is not your homepage.
Provide an index.html at the top of the archive and the rule never applies to you.
If you zip your whole repository, you get src/, node_modules/, and files ending in .jsx or .tsx. A browser cannot execute any of that. Static hosting serves files; it does not run your bundler, install your dependencies, or transpile anything on the way out.
We detect this specifically and refuse the upload rather than publishing a blank page, because a blank page is a much worse outcome than a clear error. The fix is always the same: run the production build, then zip only the output directory — normally dist/ or build/ — containing the compiled JavaScript and CSS, with no source files and no node_modules. While you are there, make asset paths relative so they still resolve when the site is served from a sub-path.
If you built the thing with an AI tool and are not sure how to produce that output, ask it in those words: give me only the production build output folder, zipped, with relative asset paths and no source files.
This one bites game and WASM exports. A multi-threaded Unity or Godot WebGL build needs SharedArrayBuffer, and browsers only hand that out on a cross-origin-isolated page — which requires the host to send a specific pair of COEP and COOP response headers. A simple drop host generally does not, and we do not either: our viewer sends Cross-Origin-Opener-Policy but not the embedder-policy header that isolation also requires, so a threaded build will sit on its loading bar forever.
Two honest routes: re-export single-threaded, which most engines support and which behaves like any other static bundle, or use a platform where you control response headers — Vercel and Netlify both let you set them, and for a threaded WebGL build that is the right tool rather than us. Better to read that here than after uploading a 40 MB build.
A related, smaller one: encrypted archives are refused everywhere, because the contents cannot be read and therefore cannot be served. If you password-protected the ZIP itself, compress it again without the archive password. A password on the link is a different mechanism and is the one your viewer is actually asked for.
Everything above applies whichever side of the fork you are on. This part does not.
A public host's URL is fair game for search engines, which is the entire point of public hosting — and a folder-shaped site gives crawlers more surface, not less. If the bundle is a client deliverable, an unreleased design review, or an internal report, that default is working against you.
A private-link host inverts it: the bundle is unpacked and served behind a single URL that carries a noindex tag and is long enough that nobody guesses their way in, with free password protection on any tier. Internal links and relative asset paths resolve the way they do anywhere else, so a multi-page bundle navigates normally. The free tier takes a 10 MB upload, Solo 25 MB and Studio 50 MB, and — the part that matters most for anything you will revise — re-uploading a new ZIP keeps the same URL, so the link already sitting in someone's inbox opens the current build rather than last week's.
If you want to check what a bundle looks like before it goes anywhere, the ZIP viewer opens one in the browser without uploading it at all.
For the public half of the fork, the honest recommendation stays what it has always been: GitHub Pages is the better tool for a permanent public site, and it is free, and it will still be there in five years. Private delivery is a different job, not a better one.
And before any of that: zip the contents, not the folder. It is one habit and it removes the most common failure on this list.
Every list of free HTML hosts assumes you'll sign up. If you won't, the field narrows to a handful — and each one charges you for it in a different currency. Which hosts genuinely need no account, what you give up, and when signing up is the cheaper trade.
Twelve ways to put a single HTML file online for free — GitHub Pages, Netlify, Cloudflare, Vercel, Tiiny, Neocities, Static.app, EdgeOne, host-html, Linkyhost, Wasmer, and a private-link option — with an honest table of which fits which job, public or private.
You built a one-page site someone paid you for, and you are about to put it on a free plan. The question is not whether the free plan can handle it — it is whether the host's own terms permit it. Two different walls, and only one of them shows up as a bill.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.