Clients, servers, browsers, URLs, requests, responses, and the open standards that turn billions of separate devices into one connected system
Before writing a single line of HTML, you need a clear picture of the system your code will live inside. Open any browser and visit any website, and an enormous amount of coordinated activity happens in a fraction of a second — computers find each other across the planet, exchange carefully formatted messages, and assemble files into the page you see on screen. Most users never think about any of this. Web developers cannot afford that luxury.
This chapter explains what happens when someone types a web address into a browser, what a server actually does, how files travel across the internet, and why that journey matters for every website you build. Understanding the web as a system will help you write better code, diagnose problems more quickly, and make decisions that real web developers think about every day.
You type a web address into your browser and press enter. Less than a second later, a complete page appears — text, images, styling, and interactive elements all in place. Between the moment you pressed enter and the moment the page appeared, your request traveled to a computer you have probably never seen, in a building you cannot locate, and a precise, standardized conversation took place between two machines that had never spoken to each other before. What exactly happened in that second? By the end of this chapter, you will be able to trace that journey step by step.
By the end of this chapter, you should be able to:
file:// and serving it through a local development server.file:// versus a local server; why the difference matters; local copies versus the live, published siteMost people use the words internet and web interchangeably. In everyday conversation that is usually fine, but for a web developer the distinction matters.
The internet is a global network of interconnected computers. It is the physical and logical infrastructure: fiber-optic cables running under oceans, wireless signals, routers directing traffic, and agreed-upon rules that allow billions of devices to communicate. The internet carries many different kinds of traffic — email, file transfers, video calls, messaging apps, and more.
The World Wide Web — usually just called the web — is one system that runs on top of the internet. It is a collection of interconnected documents and resources that you access through a browser. The web was invented by Tim Berners-Lee in 1989 as a way to share and link research documents. It grew from a handful of pages into billions of websites.
Think of it this way: the internet is the highway system. The web is one category of traffic that travels on those highways — specifically, the traffic that browsers read, display, and link together. When you write HTML, CSS, and JavaScript files, you are creating content for the web. Those files will travel across the internet to reach users, but the internet itself does not care what is inside them. The browser is the tool that gives those files their meaning.
Each of these uses the internet as its transport layer, but none of them is part of the web in the technical sense. They do not use the same protocols, document formats, or browser-based experience that web development produces. When you build a website, you are building specifically for the web — and that means HTML, CSS, JavaScript, and the protocols this chapter describes.
The web runs on a relationship between two kinds of computers: clients and servers.
A client is a device that requests resources. When you open a browser and visit a website, your computer or phone is acting as a client. It sends out a request saying, in effect, "please send me this page." The browser is the program on the client that makes those requests and displays the results.
A server is a computer that listens for requests and sends back responses. When a server receives your request for a web page, it finds the relevant files and sends them back across the internet to your browser.
Client (Your Browser) Server (Web Host)
| |
| -- Request: "Give me |
| index.html" -----------> |
| |
| <-- Response: Here are |
| the files (HTML, CSS, |
| JavaScript, images) --- |
| |
This back-and-forth is called the client-server model. Almost everything on the web follows this pattern.
Remember that everything you write in HTML, CSS, and JavaScript in this course runs in the browser — on the client side. Server-side code, written in languages like Python, PHP, or Node.js, is a separate topic for later courses.
A browser is a program that requests web pages, interprets the files it receives, and displays the result as a visual, interactive experience on your screen.
You are likely familiar with several browsers: Chrome, Firefox, Safari, Edge, and others. Each of these is a complex piece of software with many responsibilities:
From a developer's perspective, the browser is your most important tool. It is where your code runs, where your users experience your work, and where you will spend a great deal of time inspecting, debugging, and testing.
When a browser receives an HTML file, it does not display the raw text. It reads the tags, builds an internal model of the page structure, downloads any linked CSS files and images, applies the styles, runs any JavaScript, and then renders the final visual result. This process happens very quickly — often in a fraction of a second.
Different browsers can interpret the same HTML and CSS slightly differently. Modern browsers have become much more consistent than they were in earlier years, but differences still exist. Good web developers test their pages in multiple browsers to confirm they look and work correctly everywhere.
Every modern browser also includes a powerful set of inspection and debugging tools built directly into it — Chapter 4 is dedicated entirely to these developer tools, and you will use them constantly throughout this course.
A web server is a computer — or more precisely, software running on a computer — that listens for incoming requests over the internet and responds by sending files back to clients.
The most common web server software includes Apache, Nginx, and Microsoft IIS, though there are many others. When you host a website, you are either running web server software on a computer you control or paying a hosting company to run it on computers they control.
index.html).| Type | Description |
|---|---|
| Static web server | Simply delivers files exactly as they are stored. When a browser asks for index.html, a static server sends back that file without modification. This course focuses on static files you write and serve directly. |
| Dynamic web server | Can generate files on the fly. When you log into a website and see your name on the page, that page was probably generated dynamically — the server retrieved your information from a database and inserted it into the HTML before sending it to your browser. Server-side development of this kind is beyond the scope of this course. |
During development, you will often run a simple local web server on your own computer so that your browser can request files just as it would from a real server. This matters because some browser behaviors — particularly around JavaScript and file access — work differently when you open a file directly from your desktop compared to requesting it through a server. Chapter 3 discusses project setup, including local servers, in more detail.
A URL (Uniform Resource Locator) is the address of a specific resource on the web. When you type an address into your browser's address bar, you are typing a URL. When you click a link, that link contains a URL. When your HTML references an image or a stylesheet, those references are URLs too.
Understanding URL structure is essential for web development, both for linking pages correctly and for understanding how the web organizes resources.
https://www.example.com/about/team.html?sort=name#contact | | | | | scheme host path query fragment
http or https. The s in https means the connection is encrypted (see Section 2.7).www.example.com is a hostname. www is an optional subdomain; sites also use subdomains like blog.example.com or shop.example.com./about/team.html means "look in the about folder for a file called team.html." A path ending in just / typically requests the default file in that directory, usually index.html.?, containing key-value pairs separated by &. In ?sort=name, the key is sort and the value is name. You see query strings with search engines, filters, and forms that use the GET method.# that refers to a specific location within a page. Fragments are handled entirely by the browser and are never sent to the server.You will use URLs constantly when writing HTML — to link pages together, to reference images, to load stylesheets and scripts. Chapter 3 covers the difference between relative and absolute paths in detail, since this is a common source of beginner errors.
Every interaction between a browser and a web server follows the same fundamental pattern: the browser sends a request and the server sends back a response. This is called the request-response cycle.
| Code | Meaning |
|---|---|
| 200 OK | The request succeeded and the content is in the response body |
| 301 Moved Permanently | The resource has permanently moved to a new URL |
| 302 Found | The resource is temporarily at a different URL |
| 304 Not Modified | The browser's cached version is still current (no new download needed) |
| 400 Bad Request | The request was malformed or invalid |
| 403 Forbidden | The server understood the request but refuses to fulfill it |
| 404 Not Found | The requested resource does not exist on the server |
| 500 Internal Server Error | The server encountered an unexpected error |
The 404 error is familiar to almost every internet user. As a developer, you will cause 404 errors when you have broken links, mistyped file paths, or deleted files without updating the links pointing to them. Chapter 3 explains how to avoid these mistakes.
Loading a single web page usually involves many individual requests, not just one. When your browser receives the HTML file, it reads through it and discovers that the page also needs a CSS file, several image files, a JavaScript file, and perhaps some fonts. It sends separate requests for each of those resources. A typical web page may involve dozens or even hundreds of individual requests.
Every request takes time, and the time adds up. Good web developers think about how many resources a page requires and how large those resources are.
HTTP (HyperText Transfer Protocol) is the set of rules that governs how web browsers and servers communicate. It defines how requests are formatted, what responses look like, and how the conversation between client and server proceeds.
HTTP was designed in the early days of the web as a simple, readable protocol. An HTTP request is text — structured text, but human-readable. Over time, HTTP has evolved through several versions (HTTP/1.1, HTTP/2, HTTP/3), each improving speed and efficiency, but the fundamental request-response structure remains the same.
HTTPS (HTTP Secure) is HTTP with an added layer of encryption. When you use HTTPS, the data traveling between your browser and the server is encrypted so that anyone who intercepts it cannot read the contents.
Without HTTPS, your requests and responses travel in plain text. Anyone monitoring the network — on public Wi-Fi, at an internet service provider, or anywhere along the route — could read exactly what you are sending and receiving, including passwords, personal information, and private messages.
When you publish a website, you should always use HTTPS. Hosting providers typically offer free HTTPS certificates through services like Let's Encrypt, making this accessible to everyone.
When you develop a website on your own computer, you will typically use http://localhost or http://127.0.0.1 — special addresses that refer to your own machine. These do not require HTTPS certificates because you are not sending data across the public internet. Once you publish your site publicly, switching to HTTPS is standard practice.
When someone visits a website by typing a name like www.example.com, several layers of infrastructure work behind the scenes to connect that name to the right server.
Every device on the internet has a numerical address called an IP address (Internet Protocol address). A typical IPv4 address looks like 192.168.1.1 — four groups of numbers separated by dots. A newer format, IPv6, uses longer hexadecimal addresses. These numerical addresses are what computers actually use to route traffic.
Humans are not good at remembering strings of numbers. Domain names are human-readable names — like example.com or mgu.edu — that map to IP addresses.
The Domain Name System (DNS) translates human-readable domain names into the numerical IP addresses computers actually use. When you type www.example.com into your browser, your computer sends a query to a DNS server asking, "What is the IP address for this domain?" The DNS server responds with the IP address, and your browser can then connect to the right server. This lookup takes only milliseconds but is a necessary step every time you visit a new website. Your browser and operating system cache DNS results for a period of time so that repeated visits to the same site do not require repeated lookups.
Domain names are registered through companies called domain registrars. You pay an annual fee to reserve a name like yourproject.com. If you do not renew, the name becomes available to others.
Even if you own a domain name, you also need somewhere to store your website files. Web hosting is a service that keeps your files on a server connected to the internet around the clock, ready to respond to requests.
| Type of Hosting | Description |
|---|---|
| Shared hosting | Your files share server resources with many other websites. Affordable and easy to set up. Good for small, low-traffic sites. |
| Static site hosting | Services like GitHub Pages, Netlify, and Vercel are specifically designed for static HTML, CSS, and JavaScript sites. Many offer free plans. A good choice for the projects in this course. |
| Virtual private servers (VPS) | More control and more power, but requires more technical knowledge. |
| Cloud hosting | Large-scale, highly configurable hosting from providers like AWS, Google Cloud, and Azure. |
When you register a domain name and set up hosting, you configure the domain's DNS settings to point to your hosting provider's servers. This tells the internet: "When someone asks for yourdomain.com, send them to this server." For this course, you will primarily develop locally — Chapter 30 covers publishing options in detail.
Understanding the difference between opening a file locally on your computer and loading a page through a web server will save you from confusion throughout this course.
When you double-click an HTML file on your desktop, your browser opens it using the file:// protocol instead of http:// or https://. The address in your browser bar will look something like:
file:///Users/yourname/Desktop/my-project/index.html
Your browser can display the HTML, apply the CSS, and run some JavaScript this way. For early exercises and simple pages, this often works fine. However, opening files locally is not the same as serving them through a web server.
file://For any project beyond simple exercises, you should use a local web server instead of opening files directly. Many code editors offer this feature as an extension — Visual Studio Code's popular "Live Server" extension serves your project files through http://localhost with a single click. When you run a local server, your browser's address bar shows something like http://localhost:5500/index.html, giving you a much more accurate preview of how your site will behave when published.
It is important to hold both in mind: your local development copy (which only you can see) and the published website (which anyone with the URL can see). Changes you make to your local files do not automatically appear on the published site. To update a published website, you need to transfer the changed files to the hosting server — Chapter 30 covers deployment workflows. During development, however, you will almost always be working locally: edit, save, reload the browser, and check your work, dozens or hundreds of times per session.
Pull back and look at the whole picture. The web is not just a collection of pages — it is a system of interconnected technologies, standards, and practices.
The web works because everyone follows agreed-upon standards. HTML, CSS, JavaScript, HTTP, and URLs are all defined by specifications maintained by standards bodies — primarily the World Wide Web Consortium (W3C) and the WHATWG (Web Hypertext Application Technology Working Group). These specifications describe precisely how browsers should interpret HTML tags, apply CSS rules, execute JavaScript, and handle HTTP requests.
Because of these standards, you can write an HTML file and have it work in Chrome, Firefox, Safari, and Edge — on Windows, macOS, iOS, Android, and Linux — without writing separate code for each combination. This interoperability is one of the web's most powerful features.
Every step in that sequence depends on something from this chapter: protocols, servers, clients, URLs, requests, responses, domain names, and the browser's ability to interpret your files.
Unlike many software systems, the core technologies of the web are open and public. Anyone can read the HTML specification. Anyone can inspect the source code of any web page. Anyone can learn to build for the web without paying for proprietary tools or licenses. This openness is why the web grew so rapidly and why it remains such a powerful platform for sharing information and building applications.
Because web pages are public — potentially seen by anyone, anywhere, on any device — web developers have real responsibilities. You are building for real users with different devices, different browsers, different connection speeds, different abilities, and different contexts. Accessibility, performance, security, and clarity are not optional extras. They are part of what makes a website good — and these responsibilities will come up repeatedly throughout this course, starting with the very first HTML you write.
localhost does not require it.file:// differs from serving them through a local server in real, observable ways. A local development server gives you a more accurate preview of your published site, and your local files remain separate from the live, published website until you deploy.example.com, that maps to the IP address of a server.# that refers to a specific location within a page.? that passes additional parameters to the server.http or https.Study the diagram below, then answer the questions that follow.
[User types: https://www.learningsite.edu/lessons/html-basics.html]
|
v
[Your Browser]
|
| 1. DNS Lookup: "What is the IP for www.learningsite.edu?"
v
[DNS Server]
|
| 2. "The IP address is 203.0.113.42"
v
[Your Browser]
|
| 3. HTTP GET Request to 203.0.113.42
| "Please send: /lessons/html-basics.html"
v
[Web Server at learningsite.edu]
|
| 4. HTTP Response: 200 OK
| [html-basics.html file contents]
v
[Your Browser]
|
| 5. Browser reads HTML, finds links to:
| - /css/main.css
| - /js/main.js
| - /images/diagram.png
|
| 6. Sends separate requests for each linked resource
v
[Web Server responds with each file]
|
v
[Browser builds and displays the page]
/lessons/html-basics.html. What HTTP status code would it send back?https://www.learningsite.edu/lessons/html-basics.html — scheme, host, and path.For each URL below, identify the scheme, host, path, query string (if present), and fragment (if present). Then answer the follow-up question.
https://www.mgu.edu/programs/computer-sciencehttp://example.org/blog/post.html#comments — What will the browser do with the #comments part of this URL?https://search.example.com/results?q=web+development&page=2 — How many query parameters does this URL contain? What are their names and values?https://resources.learningsite.edu/downloads/starter-kit.zip — Based on the path, what type of file is being requested? What do you expect the server to send back?http://localhost:3000/index.html — What does localhost tell you about where this file is stored? What does :3000 indicate?Answer each question in one or more complete sentences.
404 for the image request. What does this tell you about the problem?http:// instead of https://. A user connects to this site from a coffee shop's public Wi-Fi. What risk does the user face? What risk does the website owner face?Decide whether each statement is true or false. If a statement is false, write a corrected version.
file:// and http://localhost are the same thing."file:// protocol opens files directly from your disk without going through any server. http://localhost serves files through a local web server. Some JavaScript features, security policies, and path behaviors differ between the two. Use a local server for serious development work.yoursite.com). Hosting is the service that stores and serves your files. You register a domain name with a registrar and separately set up hosting with a hosting provider, then connect the two through DNS settings.file:// and a local development server.Chapter 2 explained how files travel across the internet from server to client. But before files can travel, they must exist — organized and named correctly on both your development machine and the server. Chapter 3 digs into project organization: how to structure a web project folder, what file extensions mean, how relative and absolute paths work, how to link your HTML, CSS, JavaScript, and image files together correctly, and how to name files so they behave properly on servers. Broken file paths are one of the most common beginner problems in web development. Chapter 3 gives you the foundations to avoid them.