HTML to website

How to turn an HTML file into a website

The check and preview are on this page; the publishing step is two commands in your terminal or in your coding agent. Nothing here uploads your file — the checker is a script running in your own browser.

1. Open the file. Drag your .html file onto the box, choose it with the file picker, or paste the markup. It is read locally with FileReader and rendered in a sandboxed frame, so you see exactly what a visitor would see.
2. Clear the blockers. Every finding carries a line number. Blockers are things that behave differently once the file is served over HTTPS from a domain: references to your own disk, http:// subresources, a missing viewport or title. The checks are things worth adding before anyone links to the page.
3. Publish it. Put the file in a folder as index.html, claim a free handle with clize claim, then run clize deploy on the folder. You get an HTTPS address in the same minute, and the folder can be redeployed as often as you like.

What breaks when an HTML file leaves your disk

A file opened from file:///Users/you/Desktop/page.html and the same file served from https://yourname.clize.app/ are not in the same world. The four differences below account for almost every "it looked fine locally" report, and the checker on this page finds all of them without sending your file anywhere.

Two more the checker reports because they are invisible until it is too late: a missing <title>, which becomes the text of every link anyone ever makes to the page, and a missing og:image, which is why some links get a preview card in chat and yours does not. If you only want to look at a file rather than ship it, the HTML viewer renders the same way with three preview widths and no publishing talk.

Two commands, and the file has a link

Publishing is not a form. Install once, then a free handle and a deploy are one command each — the same two commands your coding agent runs when you ask it to put the page online, because they are the same CLI.

$ npm i -g @clize/clize && clize login
      
      $ clize claim kilnhouse
      ✓ kilnhouse.clize.app is yours; the placeholder site is in place.
      
      $ clize deploy ./site --domain kilnhouse.clize.app
      {
        "host": "kilnhouse.clize.app",
        "url": "https://kilnhouse.clize.app",
        "files": 1,
        "notFound": "spa (auto)",
        "geo": { "sitemap": "…/sitemap.xml", "llms": "…/llms.txt", "robots": "…/robots.txt" }
      }

The handle is first come, first served and belongs to you until you release it. clize deploy takes a folder, so put your file in one and name it index.html — that is the whole "single file" ceremony. Bind the folder once with clize init --handle kilnhouse and later deploys need no --domain at all. Every command is listed in the command reference.

What free HTML hosting includes here, stated exactly

Free means the handle, the certificate and the deploys — not a trial. Here is the whole surface, so you can decide before you type anything:

• A real address. yourname.clize.app over HTTPS, certificate issued automatically. Point your own domain at it later without moving the files.
• Multi-file sites, not just one page. Whatever is in the folder goes up: pages, CSS, images, fonts. One file up to 90MB, one site up to 5GB.
• Real 404s when you want them. Ship a 404.html and unknown paths return a genuine 404; without one they fall back to index.html with a 200, which is what a single-page app wants. --not-found overrides either way.
• Clean URLs. /about/ serves /about/index.html directly — no redirect hop. Responses are cached publicly for five minutes.
• A machine-readable surface, generated for you. Every deploy answers /sitemap.xml, /llms.txt and /robots.txt from the file list; ship your own files with those names and yours win.
• An inbox on the same name, if you want one. clize claim yourname --email also opens support@yourname.clize.app for incoming mail.

What it is not: there is no visual editor, and there is no branded interstitial in front of your page. You write or generate the HTML — by hand, or by asking the agent you already use — and the deploy publishes exactly those bytes.

Hosting a single HTML file, step by step

The most common case is one file with everything inlined. Three lines:

$ mkdir site && cp ~/Desktop/page.html site/index.html
      $ clize claim kilnhouse
      $ clize deploy ./site --domain kilnhouse.clize.app

Renaming it index.html is what makes https://kilnhouse.clize.app/ itself show the page rather than a file listing. If the checker above listed companion files, copy those into the same folder first, keeping the same relative paths — img/hero.png in the markup has to be site/img/hero.png on disk.

Redeploying is the same command again; it replaces what changed and leaves the address alone. When the page outgrows a single file, the agent that wrote it can keep working in the same folder: that loop is what Sites by Clize is, and there is a worked example in building a site with Claude Code and putting it live. If the file came out of a chat rather than an editor, start at hosting a Claude artifact on your own domain instead — those files have one extra failure mode this page does not cover.

$ npm i -g @clize/clize && clize login
$ clize claim yourname
$ clize deploy ./site --domain yourname.clize.app