How to host a static website from a ZIP (no server, no build pipeline)

You built a website. It's finished, it works on your laptop, and now you just need it online— a URL you can send to a client, a teammate, or the world. And that's where it stalls, because every hosting guide turns a five-minute job into an afternoon: pick a host, configure a build, buy a domain, point nameservers, wait for DNS. If your site is already a folder of static files, none of that should be necessary. Here's the short version.

What "static" means (and why it makes this easy)

A static site is one whose files are finished before anyone visits: HTML pages, CSS stylesheets, JavaScript bundles, images, and fonts. Nothing is generated on a server per request. That covers a huge amount of the web — hand-coded sites, documentation, landing pages, portfolios, and the built output of every static framework (Vite, React, Vue, Astro, Hugo, Jekyll, 11ty). Because the files are already done, "hosting" just means "put these files somewhere and serve them." No build server, no runtime, no database.

The fastest path: zip it, upload it, done

1. Zip your site's files. Compress the folder that contains your index.html and everything it references. If you use a framework, zip the built output — the dist/, build/, or out/ folder — not your source.
2. Upload the ZIP. Drop it on the dropzone. The site is unpacked, your index.html is found (at the root or inside a common build folder), and every file is laid out under one site so relative links resolve.
3. Open the live URL. Click through the pages to confirm your CSS applies and your scripts run — they will, because each file is served with the correct content type.
4. Add your domain (optional). On Pro, connect your own domain with automatic SSL.

The part that usually breaks: relative links and MIME types

Two things trip people up when they try to "just open the files." The first is relative links: a real site is many files wired together — index.html links to about.html, which pulls a stylesheet from /css and images from /images. Open those from your desktop and the paths often break; served from a proper web root, they resolve exactly as intended. Keeping your folder structure intact is what makes the whole site navigable.

The second is content types. Browsers refuse to apply a stylesheet served as plain text, and refuse to run a script served as the wrong type — so a site can come out completely unstyled if the host guesses wrong. The fix is serving each file as what it actually is: CSS as text/css, JavaScript as text/javascript, fonts as font/woff2, and so on. Get that right and your site looks online exactly like it did locally.

Updating without breaking the link you shared

Sites change, and the worst outcome is a new URL every time you fix a typo — leaving dead links in everyone's inbox. The better model is: upload a new ZIP and the same URLserves the updated site. Every link you've already shared keeps working and simply shows the latest version. It's the feel of a one-click redeploy without a build server or a git push.

When static hosting is the wrong tool

Being honest about the boundary saves you time. Static hosting serves the files you built and nothing else. If your site needs a backend— a database, server-side rendering at request time, API routes, secrets read on the server — you need a platform that runs that server. Client-side JavaScript that calls an external API over HTTPS is fine; server code is not. If your only blocker was "I just need this built site live somewhere," static hosting removes exactly that blocker.

Do it now

Zip your site's folder (or your framework's dist/), drop it on the static-site hostingpage, and open the link. If you're deploying a framework build specifically, the deploy a Vite or React build guide has the folder-name and routing details. For a single self-contained page, plain HTML hosting is even simpler.