How Static Hosting Works (and When One HTML File Is Enough)

hdply · 2026-09-08

A website made of one HTML file has no server to manage, no database, and no build step. That sounds too simple to be real hosting, so this guide explains what a static site actually is, why a single file covers more cases than people expect, what a static host does on your behalf, and — just as important — the cases where static hosting is the wrong tool.

What a static site actually is

A static website is just files — HTML, CSS, JavaScript and images — handed to the browser exactly as written. There is no server-side code computing pages on each visit, no database to query, and nothing to keep patched. Most of the web works this way: portfolios, landing pages, documentation and event pages are all static, and even rich interactivity runs in the visitor's browser rather than on a server. If your page doesn't need user accounts or a database, static hosting is all it takes.

The word "static" describes how the page is delivered, not how it behaves. A static page can animate, filter a table, validate a form, fetch data from a public API or run a small game — all of that is JavaScript executing on the visitor's machine. What it cannot do is remember something between two different visitors without help from a third-party service.

Why one HTML file is often enough

Frameworks, build steps and Git workflows exist to manage large, evolving codebases. For a single page they add ceremony with no payoff. A self-contained index.html — with its styles and scripts inline — is the simplest thing that can possibly work: it loads instantly, survives traffic spikes that would flatten a small server, and is trivial to back up or move. When a project genuinely grows you can graduate to a build pipeline; until then, one file keeps you fast.

Keeping everything in one file also removes the most common publishing failure: a page that references styles.css or script.js sitting next to it, and then ships without them. If your HTML links to a local file, move that file's contents into a <style> or <script> block. Images can point at any public URL, or be embedded as a data: URI when they are small.

<!-- one file, nothing to upload alongside it -->
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Q3 proposal</title>
  <style> body { font: 16px/1.6 system-ui; max-width: 40rem; margin: 3rem auto; } </style>
</head>
<body>
  <h1>Q3 proposal</h1>
  <p>…</p>
  <script> /* optional interactivity */ </script>
</body>
</html>

What a static host handles for you

A host's job is to keep that file reachable at an address, over HTTPS, from a computer that is always on. hdply serves your file byte-for-byte from your own subdomain, with HTTPS included and no configuration. You upload or paste your HTML and it is live in seconds; edit it in the browser and the change deploys on save. Every deploy is kept in a version history, so rolling back a mistake is one click — the useful part of version control without a repository. There is no CLI, no YAML and no server to maintain.

One default worth knowing: new pages are served with a noindex header, so they stay out of Google unless you switch indexing on for that site. That is the right default for a proposal, a report or a mockup you are sending to a handful of people, and the wrong one for a portfolio you want found — flip it in the site settings when you are ready.

When static hosting is the wrong tool

Static hosting is a poor fit the moment the page has to remember something on the server side:

User accounts and logins. Authentication needs a server that can keep secrets. A password check in client-side JavaScript is visible to anyone who views the source.
Data that visitors create for each other. Comments, bookings, inventory, a leaderboard. A static page can send this to a third-party form or database service, but it cannot store it itself.
Pages that differ per visitor. A dashboard showing "your" numbers has to be assembled somewhere that knows who you are.
Many files that change together. A site with dozens of pages, shared navigation and a content team is better served by a static site generator and a Git-based host, where one template change updates every page.

For those, reach for a framework host (Vercel, Netlify), a backend-as-a-service, or a small server. For everything else — a page, a document, a demo, a design, an invitation — a single file on a static host is not a compromise. It is the simplest correct answer.