How to Put an HTML File Online (the Easy Way)

You have an HTML file on your computer. It opens fine in your browser, but the address bar says file:///Users/you/index.html — nobody else can see it. Emailing the file mostly doesn't work either. This guide covers every realistic way to turn that file into a real website at a real URL, what each one costs you in setup time, and how to choose.

What "putting a file online" actually requires

A website is files served by a computer that is always on. To publish an HTML file you need exactly three things:

• Storage that is always reachable — a hosting service, so the file exists somewhere other than your laptop.
• An address — a domain or subdomain people can type or click.
• HTTPS — browsers label plain HTTP pages "Not secure", and some features (geolocation, clipboard, service workers) simply refuse to run without it.

You do not need a server of your own, a database, a framework, or a build step. If your page doesn't run code on the server — and a portfolio, landing page, invitation or demo doesn't — all of that is overhead you'd be maintaining for nothing.

A detail that trips people up: the filename

Name your file index.html. When someone visits a bare address, the server looks for that exact name by default. A file called portfolio.html or Index.HTML gets you a 404 on most hosts, and the fix is renaming — not configuration.

Option 1: One-file hosting (fastest path)

Some hosts are built for exactly this job: upload one index.html, get a live URL. hdply works this way — sign up with an email, paste or upload the file, and you get an address like my-site.hdply.com with HTTPS. There's no build step; the file is served byte-for-byte as you wrote it, so what you saw locally is what visitors get.

The catch worth knowing up front: one site is one file. There's no folder to drop style.css or photo.jpg into. In practice that means putting your CSS in a <style> tag, your JavaScript in a <script> tag, and your images either on an external URL or embedded as data URIs. For a single page that's usually how you'd write it anyway; for a multi-page site with an assets folder, it's the wrong tool.

Choose this when: you have one page, you want it live now, and you don't want to learn a deployment workflow to get there.

Option 2: Git-based platforms

GitHub Pages, Netlify, Vercel and Cloudflare Pages deploy from a Git repository: push a commit, the site updates. This is genuinely the right answer for anything you'll keep working on, and all of them have real free tiers.

The cost is ceremony before the first deploy. You need an account, a repository, the file committed and pushed, and usually a settings pass to tell the platform which branch and folder to publish. GitHub Pages also has published limits worth knowing: a 1 GB cap on published site size, a soft 100 GB/month bandwidth limit, and a soft limit of 10 builds per hour (the build limit doesn't apply if you publish with your own GitHub Actions workflow).

Choose this when: your site already lives in Git, or it has multiple files, or you want deploy-on-push.

Option 3: Cloud storage buckets

AWS S3, Google Cloud Storage and Azure Blob Storage will serve static files, and at scale they're the cheapest option there is. They are also the most work: bucket creation, a public-read or origin-access policy, a CDN distribution in front for HTTPS on your own domain, and a TLS certificate to request and attach. Expect an afternoon the first time, and a small monthly bill rather than free.

Choose this when: you're already in that cloud, or you need control over caching, headers and regions.

Option 4: Traditional web hosting or a VPS

Shared hosting with cPanel and FTP still exists and still works — upload to public_html and you're done. A VPS (DigitalOcean, Hetzner, Lightsail) gives you a whole machine to install nginx on. Both are fine; both mean you now own an operating system that needs patching, a web server that needs configuring, and certificates that need renewing. For a static page, you are volunteering for maintenance that buys you nothing.

Comparing the four

Step by step: file to URL in about a minute

Taking the fastest path, using hdply as the example:

1. Make sure your page is self-contained — CSS in <style>, JS in <script>, images on a URL. See the check below.
2. Create a free account at app.hdply.com/signup — email plus a verification code.
3. Pick a subdomain, then upload index.html or paste the code into the editor.
4. Save. The URL works immediately.

Later edits happen in the same browser editor and go live on save. Each save is kept, so you can look at earlier versions and restore one if an edit went wrong.

Check that your page is self-contained before you upload

Open the file and look for anything pointing at your own disk:

<!-- These break once the file leaves your computer -->
<link rel="stylesheet" href="style.css">
<script src="app.js"></script>
<img src="photos/hero.jpg">

<!-- These work anywhere -->
<style> body { font-family: system-ui; } </style>
<script> console.log('hello'); </script>
<img src="https://images.example.com/hero.jpg" alt="Hero">

A quick way to test: copy your HTML file alone into an empty folder and open it. Anything that disappears was a relative reference to a file you didn't bring.

Common questions

Can my page use CSS and JavaScript? Yes, without limits — it's a normal web page. On a one-file host they need to be inline or on external URLs. JavaScript runs in the visitor's browser either way.

Can I use a font from Google Fonts or a library from a CDN? Yes. External URLs are fine anywhere; only local file references are the problem.

Do I need to buy a domain? Not to start. A free subdomain is a real, shareable HTTPS address. If you later want yourname.com, note that not every one-file host supports custom domains — hdply doesn't — so a domain of your own means moving to a Git platform, bucket or VPS. Your HTML moves unchanged.

Will Google index it? Only if the host lets it. Many one-file hosts publish sites as noindex by default so that throwaway pages don't end up in search results; on hdply it's a per-site setting you turn on. See the meta tags every page should have.

How do I know if anyone visited? A static page keeps no logs you can read, so you need either host-provided stats or an analytics snippet — covered in tracking visitors on a static page.

Related: Free HTML hosting compared · Deploy without a server