The first web page you write is one file of text, and you can open it in a browser without installing anything. The moment you add a stylesheet, an image and a second page, though, you also need to understand paths and a local server — and the difference between the two is where most beginner confusion comes from.
How do I write and open the first page?
Create a file called index.html in an empty folder, put this in it, and double-click it.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>My first page</title>
</head>
<body>
<h1>It works</h1>
<p>You are reading a file that lives on your own machine.</p>
<p><a href="about.html">About this page</a></p>
</body>
</html>
The address bar will show a file:// URL. That is the browser reading a file straight off your disk, with no server involved. It works perfectly for a single file, and it is how every beginner starts.
How do folders and paths work?
Real sites are folders of files, and a link is a path from the current page to another file. Two forms cover most cases.
about.html same folder as the current page
pages/about.html a subfolder called "pages"
../styles/site.css up one folder, then into "styles"
https://example.com/x a different site entirely (absolute URL)
Paths are relative to the page's folder, not to your project root, which is why a link that works on one page breaks on another. The ../ form walks up one level and is the one to watch: move the page deeper into a folder and the link needs another ../.
site/
index.html
about.html
pages/
contact.html <-- a link to the logo here needs ../../images/logo.png
images/
logo.png
styles/
site.css
Why should I use a local server?
Because file:// is not how the web works. Real pages are served over HTTP, and a few important behaviours only appear when you serve them: modules and fetch are blocked on file:// for security reasons, the browser treats every file as a separate opaque origin, and paths behave differently. Every real deployment serves files, so every real project should be developed the same way.
# from your project folder, start a tiny static server
python -m http.server 8000
# then open
# http://localhost:8000/
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
127.0.0.1 - - [10/Oct/2026:12:00:00] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [10/Oct/2026:12:00:01] "GET /styles/site.css HTTP/1.1" 200 -
Every request is logged, which is a gift when you are learning: you can see exactly which files the browser asked for, and a request that returns 404 points straight at the path you got wrong. The address is localhost because the server is running on your own machine, and nothing is exposed to your network.
How should a small project be organised?
Keep the HTML at the top level, and put assets in clearly named folders. A structure that stays out of the way looks like this.
my-site/
index.html
about.html
css/
style.css
js/
main.js
images/
logo.svg
Two rules keep it maintainable. Keep the stylesheet separate from the markup, so a change to the design does not mean editing every page. And use short, lowercase file names with hyphens, because spaces and capital letters cause trouble in URLs and on case-sensitive servers.
Why is the first page called index.html?
Because when a request comes in for a directory with no filename, the server looks for a file called index.html inside it. That is the convention on every web server in common use, and it is why https://example.com/ and https://example.com/index.html show the same page.
request: GET /articles/
server: looks for /articles/index.html
finds it, sends it, URL stays /articles/
Naming your entry page index.html is not a requirement, but it is the convention that makes the shortest possible URLs work. If you name it home.html instead, the root URL needs a redirect, and every absolute link you write has to include the filename.
How do you edit and see changes safely?
Save the file, switch to the browser, reload. Two habits make that loop painless. Edit the file in an editor that shows the file extension, so index.html.txt never happens — that suffix makes the file a text file and the browser will happily display its contents instead of rendering them. And keep the browser tab beside the editor rather than minimising it, because the round trip is what you are trying to make fast.
the loop you want
edit -> save -> reload -> look
what breaks it
a cached stylesheet that did not update
a typo in the file path
a stray smart quote in an attribute
a missing closing tag further up the file
If a change does not appear, the first thing to check is the console: a CSS parse error is reported there, and it names the file and the line. The second thing to check is the network tab, where a request that returns 404 tells you the browser asked for a file that is not where you think it is. Those two panels resolve almost every "my change did nothing" moment in under a minute.
What should you build next?
Add a second page and link to it, then add an image and a stylesheet, and get the folder structure right before the file count grows. Two small pages that link to each other, share a stylesheet and open correctly from a local server is a complete miniature of how a real site works — and it is small enough to hold in your head while you learn the rest of the tools.
Quick reference
- One file, double-clicked, works — the URL starts with
file://. - Relative paths are resolved from the page's own folder, so depth changes them.
- Serve projects over HTTP with a local server; modules and fetch need it.
- The server log shows which files were requested and which 404'd.
- Keep HTML at the top level, assets in named folders, names lowercase and hyphenated.
Try it yourself: build a two-page site with a shared stylesheet and an image, open it by double-clicking, then start a local server and compare the address bars. Break one image path on purpose, reload, and use the server log to find the file the browser actually asked for.