How Web Pages Work

Introduction

A web page starts as a request for a URL and ends as pixels, text, images, and interactive controls in the browser. This chapter gives you the mental model behind that journey: URLs, HTTP, HTML files, resource loading, DOM parsing, and the difference between static and dynamic pages.

Prerequisites

  • Basic understanding of what HTML is from What is HTML
  • A modern browser such as Chrome, Edge, or Firefox
  • No programming experience required

From URL to Page

When you type a URL like https://example.com/about into the address bar, the browser does more than “open a file.” It performs a short sequence:

  1. Parse the URL.
  2. Find the server for the domain name.
  3. Send an HTTP request.
  4. Receive an HTTP response.
  5. Parse the HTML.
  6. Load linked resources such as CSS, JavaScript, images, and fonts.
  7. Render the final page.

At a high level:

text
URL -> HTTP request -> HTML response -> DOM -> rendered page

HTML is the document the browser starts with. Everything else either styles it, changes it, or supports it.

URL Basics

A URL tells the browser where to go and what to ask for.

text
https://www.example.com/docs/html?chapter=2#rendering
PartExampleMeaning
SchemehttpsProtocol to use
Hostwww.example.comServer name
Path/docs/htmlResource path
Query?chapter=2Extra request parameters
Fragment#renderingJump target inside the page

The fragment (#rendering) is handled by the browser after the page loads. It is commonly used for table-of-contents links.

HTTP in One Minute

HTTP is the protocol browsers use to ask servers for resources. A very simple request looks like this conceptually:

text
GET /docs/html HTTP/1.1
Host: example.com

The server responds with a status code and a body:

text
HTTP/1.1 200 OK
Content-Type: text/html
 
<!doctype html>
<html>
  ...
</html>

Common status codes:

CodeMeaning
200OK, resource returned
301 / 302Redirect
404Not found
500Server error

You do not need to write HTTP by hand for this tutorial. But knowing it exists helps you understand why local files, deployed static sites, and backend-rendered pages can behave differently.

HTML Files and Linked Resources

An HTML file often references other files:

The browser first parses index.html, then makes additional requests for:

  • styles.css
  • logo.png
  • app.js

If a path is wrong, the HTML still loads, but the missing resource produces a 404 error in DevTools.

How the Browser Parses HTML

The browser reads HTML from top to bottom and builds a DOM tree.

html
<body>
  <h1>Products</h1>
  <p>Browse our latest tools.</p>
</body>

Becomes a tree like:

text
body
├── h1
│   └── "Products"
└── p
    └── "Browse our latest tools."

The DOM is not exactly the same thing as your source file. It is the browser’s in-memory representation of the document. JavaScript can later read or modify that tree.

Tip

Why This Matters

When DevTools shows the Elements panel, you are inspecting the DOM. Usually it matches your HTML source, but JavaScript can change it after the page loads.

CSSOM and Rendering

When the browser downloads CSS, it builds another structure called the CSSOM (CSS Object Model). Then it combines the DOM and CSSOM to calculate layout and paint pixels.

text
HTML -> DOM
CSS  -> CSSOM
DOM + CSSOM -> layout -> paint

This is why a page can briefly appear unstyled if CSS loads slowly, and why large blocking scripts can delay rendering.

You will learn CSS later. For HTML, the key idea is simple: clean structure gives the browser and CSS a solid foundation.

Static vs Dynamic Pages

Static Page

A static page is a real file stored somewhere:

text
index.html
about.html
contact.html

The server sends the same file for every visitor unless you update it. Documentation sites, landing pages, and personal pages often start this way.

Dynamic Page

A dynamic page is generated when requested. For example:

  • A Java server renders a Thymeleaf template.
  • A Node.js app renders HTML from data.
  • A React/Next.js app generates HTML during build or on the server.

The browser still receives HTML. The difference is who created it: a human-authored file, a build tool, or backend code.

Local Files vs Local Server

You can open index.html directly:

text
file:///Users/you/site/index.html

This works for simple pages. But real websites use HTTP:

text
http://localhost:5500/index.html

Some browser features behave differently under file://, especially module scripts, fetch requests, routing, and security rules. That is why the next chapters use Live Server or a small local server when needed.

What Happens When Something Breaks?

Common symptoms:

SymptomLikely cause
Page is blankHTML file empty, wrong file opened, script error
Image missingWrong src, wrong relative path, file not copied
CSS not appliedWrong href, CSS file missing, cache
Link goes nowhereWrong href or missing target file
Page works locally but not deployedCase-sensitive paths, missing assets, server config

DevTools is your best friend here. You will use the Elements and Network panels in later chapters.

FAQ

Does the browser read HTML line by line?

It parses HTML as a stream and builds a DOM tree. You can think of it as top-to-bottom reading, but the parser also handles missing tags, invalid nesting, and resource discovery.

Is the DOM the same as the HTML file?

No. The HTML file is source text. The DOM is the browser’s parsed tree. JavaScript can change the DOM after loading without editing the original file.

Why does my local page show file://?

Because you opened the file directly from disk. That is fine for simple HTML, but a local HTTP server is closer to how real websites work.

Do all websites send HTML?

Yes, at least an initial HTML document. Some apps then use JavaScript to fetch data and update the DOM, but the browser still starts from HTML.

What comes next?

HTML development environment — browser, editor, Live Server, and basic project setup.